PMs: Before you vibe code, read this.
Vibe coding can be an amazing accelerant, but there's no shortcut for doing the hard work of product thinking.
Early product prototypes (like this one from Twitter) used to look like this:
Now, thanks to AI tools like Loveable and v0, anyone can make a vibe coded prototype with fully fledged working flows, copy, design, and basic functionality, like this Timeless Memories example.
Late last week, the big news in the Product world was an X post from Madhu Gurumurthy, a Product Executive leading Gemini at Google, stating that his teams are moving from a writing-first to a building-first culture.
And I’ve witnessed this shift to vibe coded prototypes first-hand.
👂 Here’s what I’ve been hearing from my network:
A product director built a vibe-coded prototype to rally support for an abstract product idea. It was something he had in his mind for months, which words couldn’t quite capture.
A Senior Product Leader and his team produced several vibe-coded prototypes that became the basis for a new feature that was launched in record-time.
A few months ago, I ran a vibe coding workshop with 20 product folks, all new to vibe coding. The magic wasn’t in the prototype, it was in the diversity of ideas that vibe coding unleashed.
If you’re a Product Builder, depending on your relationship with traditional Product Requirements Documents (PRDs), this can be either liberating or terrifying news.
There will be some sensational takes like this post from the Growth team at Lovable (totally unbiased of course 😅) that will say you don’t need a PRD anymore, ever.
As with most AI headlines these days, the truth is slightly less dramatic.
Vibe coding is an amazing tool for communicating with clarity, building alignment, and doing it with speed.
But as a Product Builder, you still need to do the work.
In this edition, I’ll propose 4 ways to boost your productivity with vibe coding + a PM’s vibe coding workflow.
🧠 1) Writing is thinking. The AI cannot think for you.
Vibe coders will tell you that “building is thinking”, which I believe can also be true.
Before jumping into the solution space, a Product Builder must be clear on:
✅ What problem you’re solving
✅ Why it matters
✅ Why it’s a win-win for customers & the business
There is no replacement for doing the hard work of clear thinking.
Clear thinking doesn’t need to involve a 23-page PRD, but there must be some artefact to capture your pre-solution thinking.
💡 Try this instead:
Use a one-pager to clarify your thinking and the “why”. You can download my free 1-pager template here.
Answer Stripe’s 12 product questions before you vibe code. Notice how the prototype is question 11. Not question 1.
2) Love the problem, not the solution.
Jumping straight to prototypes can anchor you and your team prematurely. You may have not spent enough time exploring the problem space before diving into solutions.
🚨 If you jump into solution exploration, you risk:
Misdiagnosing the root problem
Not considering the full range of potential solutions
The IKEA effect: you fall in love with something you’ve spent time building
💡 Try this instead:
Spend more time in the problem space: pull data, support tickets, customer feedback and past interviews, talk to some different departments and get their take.
Before vibe-coding a solution, explore at least 3 potential solutions and pressure-test your solutions against the problem.
You could also vibe code 3 potential solutions and test them with customers.
After vibe coding, ask leaders and team members to critique how well the prototype solves the problem.
In order for them to critique how well you solved the problem, you need to have crystallized the problem space with at least a 1-pager (see tip #1).
3) Feature-bloat is real
As features become faster to develop, a Product Builders’ job is to curate features wisely.
🚨 Warning to all Product Builders: Uber just launched Simple Mode because of this exact problem: feature bloat. If you need to create a “simple mode,” it means your product is now too complex and you’ve lost sight of the core product goals.
Not all vibe-coded feature ideas should make it to production, many (if not most) should be tossed or refined further.
🚨If you say “yes” to everything you prototype, you risk:
Bloating the product with features no one will use
Making the product difficult to navigate
Bogging you & your team down shipping seemingly “low-hanging fruit”
💡Try this instead:
Every vibe coded prototype should be validated by a group of customers or internal beta testers.
Only features that are tied to a validated user or business problem make it into the development backlog.
And on the topic of feature-bloat, always think: what would Steve Jobs do?
4) Bring the entire team along, or risk losing them
Vibe coding solo might feel productive, but it can unintentionally alienate the very teammates you need to build a great product.
This follow up question on Madhu Gurumurthy’s X thread summarizes the risk perfectly: your teammates could feel like they’re a “clean-up crew”.
Reddit agrees. One PM shared:
“I would stay in my swim lane as PM and help and collaborate as best as possible to help engineering transform the idea into a real artefact.” -r/ProductManagement
🚨When you prototype in a vacuum, you risk:
Alienating your entire team: design feels cut out of UX decisions, engineering feels like you’re handing over something half-baked.
Creating a “ta-da!” moment instead of shared ownership
Locking in the wrong solution too early, without your team’s input
💡Try this instead:
Invite engineering, data, and design to vibe code with you and test assumptions together
Be honest about your strengths as a PM, and create space for others to elevate the solution
Treat the prototype as a starting point for discussion, not a finished decision
Great PMs don’t just build prototypes. They build momentum with their team.
✅ Know when to vibe code
If you’ve validated the problem and explored a few potential paths, this is where vibe coding becomes your accelerant. You can:
Create momentum for new ideas inside your org
Communicate & align, when the product vision is otherwise difficult to convey
Test hypotheses with real users more quickly
📦 Will PRDs go away?
Do I think this is the death of the PRD? Not entirely.
Instead, there’s a shift in a Product Builder’s workflow.
↩️ A New Workflow for Product Builders
You still need to do the work. But “the work” is changing. Here’s how I’d incorporate vibe coding into a product discovery workflow:
Start with clarity. Capture your thinking with a one-pager.
Validate the problem. Don’t vibe code until you’ve dug into the data.
Vibe code: Build a prototype to communicate & align on a vision.
Involve the team early: Iterate with design & engineering.
Test with users: Use the prototype to test & validate your assumptions.
Write the spec: Write the PRD while design/engineering refine & validate the production-grade product further.
You still need to produce a PRD or spec (just later in the workflow) because:
Enterprise-grade software environments require even simple changes to be well-documented with key flows, edge cases, error handling and permissions
Products with no user interface will likely always need a spec
A single, centralized document serves as a single source of truth & empower teams on decision-making
Post-launch, teams need to know what’s been built.
Heck, even AI tools will need to know what was implemented and why!
Final thoughts:
1️⃣ Vibe coding, just like wireframes/sketches/mocks, is simply a communication tool. It’s not a shortcut to ship half-baked ideas.
2️⃣ Spend time on the problem space, lead with clarity, and use the vibe coded prototype to convey, refine, and test your ideas.
3️⃣ Speed is a moat, but only if you’re solving the right problem.
💬 How are you using vibe coding in your org?