To state my point up front, product managers have many higher-value (and higher-leverage) ways to spend their time than validating or demonstrating UX concepts by vibe coding prototypes. It’s a helpful new tool in the PM toolbox, but it’s not one to use all that often. 🙊
If you wind back the clock a couple of years and sat down with any of your PMs, I’d be genuinely shocked if any experienced product manager responded with “I should create more prototypes.”
Before jumping on the vibe-coding bandwagon, it’s worth taking a step back and considering what truly matters in product management.
I’ve noticed a trend lately that’s okay short-term but problematic if we don’t come up for air. A push and incentive for PMs to be spending large chunks of their time vibe coding prototypes. While there’s never been anything wrong with a PM who can code, this newfound ability for any PM to be able to code is creating a time sink that, in my opinion, fundamentally misunderstands where a product manager’s time is best invested.
This isn’t to say prototypes aren’t valuable – they absolutely can be. It’s just that we should treat vibe-coded prototypes as a fantastic alternative to wireframing, but spend about as much time on them. Hint: not all that much!
The opportunity cost of vibe-coding prototypes is massive
When I think about the core responsibilities of a product manager, prototyping makes the list, but it’s pretty far down. And yet we’ve all seen and heard about PMs who have started spending half their week in Cursor, Lovable, Replit, or Bolt.
Let’s be honest about what product managers should actually be focusing on since nobody else is likely to do it:
- Customer discovery – Product Managers should spend half their time on Discovery and much of that engaging directly with users and proxy users.
- Error analysis & evals – Solving for the non-determinism of AI products by deeply understanding what works and addressing what doesn’t
- Stakeholder management – Aligning teams and leadership around product direction
- Market research – Understanding the competitive landscape and industry trends
- Data analysis – Making sense of user behavior and business metrics
- Opportunity identification – Spotting gaps in the market and potential threats
- Goal setting – Establishing clear objectives and success metrics
- Idea evaluation – Evaluating & ranking initiatives based on strategic fit, impact, desirability, viability, and feasibility (etc.)
- Assumption validation – Testing hypotheses before over-committing resources
- Delivery facilitation – Helping the team keep things moving & execute effectively
- Strategy development – Developing &/or contributing to the bigger picture
Prototyping helps with only one of these activities, and frankly, it’s not even the most efficient way to accomplish that goal.
When is vibe-coded prototyping a good investment?
There absolutely is a right time to pull this tool from your toolbox.
If you’re trying to convey how an experience will feel, this is a great way to bring it to life and can even be less effort than making a full clickable prototype in Figma.
If you’re trying to figure out how the pieces will fit together in an experience, this can help if you resist overinvesting.
If aspects of the experience & functionality are really hard to express in writing, this can help cut down how long your PRD takes to create and make it less work to understand.
If you’re trying to get buy-in or a big concept, this can massively help your stakeholders really understand what you’re pitching. PMs have to have good imaginations, but most stakeholders’ roles don’t!
More than anything, the thing to take away is that you shouldn’t over-invest in vibe coding. Not that you shouldn’t invest at all!
The hidden costs of AI-generated prototyping
Like any form of development, vibe-coding comes with hidden costs that managers often underestimate. When your PM spends hours or days coding a prototype, they’re not spending those hours on customer interviews, influencing, evals, or strategic planning.
Unlike traditional prototyping, where there’s no illusion that you’ll literally ship the prototype, it’s very easy to get caught up and over-invest because it feels like you’re creating something durable. Not to mention, much of prototyping
A PM who spends too much time on prototyping inevitably has less bandwidth for the fundamental activities that actually drive product success. And I can almost guarantee that if prototyping has made it into their top 5 activities… they’re already under-investing in most of the critical responsibilities I listed above.
The truth is, most PMs are already stretched thin trying to cover their core responsibilities. Adding full-fledged prototyping expectations doesn’t make them more effective—it just dilutes their focus.
Finding the right balance
Every product organization is different, and there may be specific contexts where focusing your team on vibe-coded prototypes is the best marginal investment of their time. But before making it an expectation, consider:
- What core PM activities might suffer as a result?
- What are you actually trying to validate? If it’s the logic rather than experience, you probably want to prototype the LLM pipeline & evals, instead! (a dedicated post on that topic coming soon)
- How do you want to balance the roles of Product Management & Product Design when it comes to validating the user experience?
Vibe-prototyping™ can certainly be helpful for the PM to think through and refine what they believe is the right solution. What’s important to keep in mind is how much time it takes, oftentimes a whiteboard or a Figma file is a more efficient path to the same result.
And speaking of Figma, I actually think vibe-coded prototypes will be a much more frequently used tool in the Product Designers’ toolbox. And if your PMs are pairing up with their product designers as a substitute for good old fashioned white-boarding sessions, I think that’s much higher ROI.
I should also add that overcooking an AI-generated prototype at least once is a valuable rite of passage and a great way to build empathy for their engineering counterparts and experience product development from a very different angle and through a whole different lens. It’s a great learning experience.
The most effective product managers I’ve worked with aren’t necessarily the ones who can code—they’re the ones who excel at understanding customer needs, communicating clearly across teams, making tough prioritization decisions, and driving outcomes. Now that we have the tools for literally anyone to code better than even the technical product managers of yesteryear, that prioritization of tasks hasn’t changed.
If your PMs are already nailing all the core product responsibilities I listed earlier, then sure, maybe spending more time on prototyping should be their next frontier. But I suspect most organizations would benefit more from PMs who go deeper on their product management-specific skills.