Common PM Pitfalls in the Age of Vibe Coding
From deflecting technical decisions to over-indexing on AI tools, here are three Product Manager mistakes to avoid.
I saw a post on Reddit that got me thinking about common PM mistakes in 2026. As the tools evolve, the mistakes PMs can make evolve too.
Here’s 3 mistakes I’m seeing PMs make right now, and what to do instead:
Mistake #1: Deflecting technical decisions
It’s very common for non-technical PMs to freeze when engineering asks for your input on a technical question.
You feel embarrassed. You start to second-guess yourself. You start to think “am I supposed to know this? Will I look like an idiot if I ask more questions?”
I recently felt this myself when my team asked me to define SLAs on throughput, uptime, and response times for a new product.
I panicked and immediately asked Gemini: “Is this something I should be defining?”
The answer? Yes, but not in isolation. As a PM, you help define the product direction, even when it’s wrapped in technical jargon.
But "defining" doesn’t mean "having all the answers".
Here’s what to do instead:
Start with: “I don’t know yet. Can you explain how this decision would impact user experience?”
Use the opportunity to learn from your Engineering team about the tradeoffs. They don’t expect you to know the technical limitations, but they do need direction on how a technical decision will impact the customer.
Other helpful questions I’ve used in the past are:
“What happens if we don’t do anything?”
“What are the potential options - can we go through the pros/cons of each?”
“Here are the customer and business priorities. Based on those, what do you think we should do?”
“How reversible is this decision if we need to make a change later?”
Don’t feel like you have to give an answer right away, either. After asking some questions, take notes and use AI to learn more about the topic and help you think through trade-offs. Your engineering team will also appreciate that you’ve taken the time to educate yourself.
Schedule another meeting to discuss the issue once you’ve had more time to collect information. Don’t expect to have all the answers, instead, facilitate a collaborative discussion with your engineering team where you represent the customer/business lens.
Mistake #2: Over-indexing on tools (and frameworks)
A new essay by Shreyas Doshi noted:
“It is fair to assume that what specific AI tool(s) you use will be fairly irrelevant.
…
Tools have never been a significant source of alpha in product success and that is not changing with AI tools.” -Shreyas Doshi
Before AI, there were PMs who were obsessed with finding the best prioritization framework, the best courses, and the best books.
You know the type: if only they could find the perfect framework for prioritization, they would be better PMs!
The 2026 version of this is PMs who obsess over their AI tool stack. AKA PMs who are spending more time tweaking their Claude workflows than talking to users.
It’s the professional version of buying fancy highlighters and bullet journals instead of actually studying. The tools are accelerators, not the engine.
Here’s what to do instead:
A great example of how being a PM still takes hard work is Tal Raviv’s essay on vibe coding a landing page for Familiar
In the essay, Tal shared how he interviewed 52 customers, extracted the pain points and use cases for the product, and then used AI to summarize pain points & value propositions, then vibe coded the landing page.
Crucially: he started with the customer and building product sense for his business/product, not the AI tool he was going to use.
As PMs, we’re facing a lot of pressure to vibe code and build fancy automations in Claude Code, but I urge us all to:
stay focused on customer & business outcomes through regular face-to-face contact with customers & business teams
stay rooted in the problems you’re trying to solve
use tools as an accelerator, not a starting point
Mistake #3: Resisting the "Vibe Coding" Shift
On the flip side of Mistake #2 are the PMs who refuse to adapt to the AI wave.
A recent Reddit thread “The PM Interview Has Changed” revealed some bitterness towards the changing expectations from the PM role to vibe code in interviews:
Here were some of the responses:
“IDK, but if it comes to that I'll need to pivot my career somewhere else. Vibe coding and coding in general is not my cup of tea.“
“Yeah... I'm out. Can't do this anymore.”
“It will go back to normal once bubble pops
Remind me in 1 year!!!”
Spoiler alert: It won’t go away. Vibe coding and AI-assisted building are here to stay.
In 2026, a top-tier PM is expected to prototype their own ideas.
Here’s what to do instead:
Start small. Use Lovable, Replit, or Google AI Studio to build a simple feature enhancement. Check this article for an example:
Once you’ve mastered the beginner tools, build a “side-vibe” project. In your free time, try building a full product from scratch using Cursor or Claude Code.
If you don’t know how to start incorporating vibe coding into your workflow, check out my previous deep dive:
Final Thoughts
The tools change, but the mission doesn’t: solve real problems for real people.
Whether you’re setting an SLA, answering a question on rate limits, or vibe coding a MVP, stay rooted in the why.
Next week, I’ll tackle Part 2 of the biggest PM mistakes of 2026. Stay tuned.