In partnership with
👋 Hey Friends!
The question I get more than almost any other from aspiring PMs who don't come from engineering:
"Am I too non-technical to get hired?"
I heard it last week from a mentee. I've heard it from almost every person I work with who came from CS, ops, support, or any role that wasn't writing code.
And I've been thinking about it differently since Naval dropped this quote into every PM Slack channel this week: "Vibe coding is the new product management."
Here's what that actually means for you.
AI Agents Are Reading Your Docs. Are You Ready?
Last month, 48% of visitors to documentation sites across Mintlify were AI agents, not humans.
Claude Code, Cursor, and other coding agents are becoming the actual customers reading your docs. And they read everything.
This changes what good documentation means. Humans skim and forgive gaps. Agents methodically check every endpoint, read every guide, and compare you against alternatives with zero fatigue.
Your docs aren't just helping users anymore. They're your product's first interview with the machines deciding whether to recommend you.
That means: clear schema markup so agents can parse your content, real benchmarks instead of marketing fluff, open endpoints agents can actually test, and honest comparisons that emphasize strengths without hype.
Mintlify powers documentation for over 20,000 companies, reaching 100M+ people every year. We just raised a $45M Series B led by @a16z and @SalesforceVC to build the knowledge layer for the agent era.
The old bar
For the last decade, "technical PM" has been a hiring filter. Companies put it in job descriptions. Hiring managers used it to screen. The ability to:
Read and write basic code
Write a SQL query from scratch
Understand system architecture well enough to have a real conversation with engineers
Speak fluently about APIs, databases, and infrastructure tradeoffs
...was treated as the price of admission for a lot of PM roles.
📌 Quick note: I'm not saying technical skills are useless. I'm saying they were used as a proxy for something else, and that proxy just broke.
The implicit message to anyone who came from a non-technical background: you're starting behind. Learn to code, or explain the gap in every interview.
I heard that message. I've watched a lot of people I mentor hear it too. And I've watched brilliant people doubt themselves out of roles they were genuinely ready for.
What just changed
Vibe coding is the ability to build working software using plain language prompts instead of code. You describe what you want, an AI builds it. No engineering ticket. No sprint. Something testable, in an afternoon.
Here's what that unlocks for PMs:
Prototype faster. Test an idea before writing a single spec
Show, don't tell. Walk into a stakeholder meeting with something clickable, not a slide deck
Reduce dependency. Stop waiting for a spare engineering cycle to validate a UX hypothesis
Get sharper instincts. When you've touched a prototype yourself, your assumptions stop being abstract
💡 The bar just moved. The ability to "build things" used to require technical skill. Now it requires a clear description of what you want.
What the new gate actually is
If everyone can build things now, what separates good PMs from great ones?
Judgment. Knowing which thing is worth building in the first place.
You can vibe code your way to a prototype in an afternoon. You cannot vibe code your way to understanding what your user actually needs. Here's what judgment looks like in practice:
Knowing when to kill a direction. You've built the prototype. Users clicked through it. Something felt off in how they hesitated. You call it before it goes any further.
Asking the uncomfortable question in the user interview. Not the one on your guide. The follow-up the data didn't anticipate.
Sitting with ambiguity long enough to understand it instead of resolving it too fast because the discomfort is inconvenient.
Knowing when to stop and verify. Vibe coding generates a lot of confident-looking output. The PM who knows when to pause is the one building something real.
📌 This is not a skill you can install. It develops through proximity to the problem, and through caring enough to stay curious when the easy answer presents itself.
What this means if you're breaking in
For non-traditional PMs, this is genuinely good news.
The credential gap is narrowing. The thing that was held against you, not having a technical background, matters less when the tooling has democratized. The judgment gap, the one that comes from lived experience and genuine curiosity about the problem, is not something you can install overnight.
The person who spent three years in customer success has sat through hundreds of conversations about what's broken. The person who came from ops has a mental model of how processes fail that a CS grad doesn't get from a case study. That context is not a consolation prize for not knowing how to code.
It's the actual thing.
Gauntlet AI: A fellowship for experienced software engineers
AI changed what senior engineering means. Gauntlet is built for engineers who want to lead that change — not watch it. The most effective way to become AI-first. No tuition. No tutorials. Just the work. Apply now.
Must be a US citizen to qualify.
🎯 Try this this week
If you've been avoiding PM applications because of the technical question, here's a reframe worth testing:
Go use a vibe coding tool (Bolt, Lovable, and Replit all have free tiers) and spend 30 minutes building the simplest version of a product idea you actually care about.
You're not trying to build something good. You're trying to feel where your judgment kicks in. Where you make a call about what matters. Where you get specific about who you're building for and why.
That instinct, not the prototype, is the thing you're developing.
Stop asking: "am I technical enough?"
Start asking: "do I understand this problem well enough to know what's worth building?"
The PMs who thrive in the next few years won't be the ones who learned to prompt the fastest. They'll be the ones who knew what to ask for.
- Stef
Reply and tell me: what's the one product you'd build if technical skills weren't a barrier?
P.S. If the technical question keeps coming up in your interviews and you want to work through how to reframe it, this is exactly the kind of thing I cover in mentoring sessions
📬 Other Newsletters You Might Like
→The Product Move - a Skool community + newsletter very similar to mine all about breaking into product
→ Innovate Disrupt or Die – Strategic insights on innovation and disruption
→ Marketing Alec – AI-powered marketing strategies
→ Practical Marketing – No-BS marketing tactics that work
→ Two Dads in Tech – Honest conversations about tech careers and life
→ Cooking Agile – Agile practices made practical
→ Seedradar AI – Startup and AI trends to watch
→ The Centaur – Stay irreplaceable in the age of AI