Vibe coding, as a faster way to tell people what to build is penny-wise, but pound-foolish. Too many people are latching onto a “show don’t tell” metaphor for making it easier and faster to tell their teams what to build. The same forces which make this possible are making this foolish at the same time. We are in uncharted waters, sailing into the storm of an uncertain future. The last thing you want to do is lash the wheel into a fixed position. Trying to go faster in a fixed direction feels like solving the wrong problem. Instead, try to improve your ability to adjust your course in response to the future you encounter.

More Directing When We Need Redirecting Instead

What we see too often in organizations is order-giving and order-taking. Where someone is directing the team on what to build. The common pattern is a serialized, siloed process. First a business case is developed or an idea forms in someone’s head. Requirements are defined, a design is selected, and finally the product is built, tested, and shipped. Product development ‘pipelines’ reinforce this metaphor of certainty. Whether you imagine this as a waterfall, a stage-gate, or a Kanban with definitions of ready and done, the sequence is the same. The work moves through a series of domains sequentially. A stakeholder describes their idea and directs a product manager to elaborate requirements. The product manager directs designers to imagine a solution which meets those requirements. The designers direct the engineers to build the product or feature through a specification. This output is tested for compliance with the spec and launched into the unknown.

The team executes along this path with blinders on, avoiding external signals which might slow them down. Speed is everything. Success is defined as finishing. On time. At quality. Within budget. Do everything we planned to do, as we planned to do it.

As leaders pop up a level and evaluate this process, looking for improvements, it is easy to focus on the concrete. When striving to be better, the easy definitions fall into place. Ship features faster. Ship more features. Ship at higher quality levels. Ship at lower cost. Do a little of each. Do a lot of all of them. More cheaper better faster. The unfortunate, but understandable bias in too many organizations has been to get better at doing things this way, instead of striving to get better by doing things a different way. There’s buzz today (summer 2025) around major organizations abandoning the PRD for the vibe coded “show don’t tell” artifact to give direction.

This form of direction is concrete, visceral, and less time consuming. It also comes with a payload of lost opportunity and triggers cognitive biases while simultaneously disempowering the team, making it harder to discover the storm ahead and redirect the course.

If you’re using AI to make it faster and cheaper to do evaluative research and discovery, I am thrilled. This article is not a rebuke of that. I’m responding to what I’m seeing which is very much not that.

Product Failure: A Systems Failure

As a product manager, I know that we’re building products in conditions of limited information. We have a lot of ways to be wrong. Incomplete information, misinterpretation of the information we do have, and of course making bad decisions based on how we process the information we do have. To make things more difficult, it takes time to build things, so we’re building for a speculated future. We need to use the available information and our intuition to predict what reality will be like in the future. Even more ways to be wrong. Lovely.

I first started building my personal model for why products fail in 2012. At that time, I was focusing on some failures of execution – building a flawed business case, taking the wrong approach to positioning and selling, etc. But I also hit on a couple key failures of decision-making – picking the wrong market or solving the wrong problems.

What I appreciate today is that a lot of product failure happens because of the systems product managers operate within, the processes which define how companies develop products. While execution failures are still sources of product failure, I’ve focused my attention on a cascade of decisions which can cause product failure regardless of how good your execution may be. An attention to that model helps me help companies improve their processes.

I mention it here, because I think the context is needed to express my concern about how vibe coding is emerging in the zeitgeist and how I expect it to do harm.

Building the Wrong Product Right

The model I developed represents a cascade of decisions, each of which, if made poorly, puts you on a path to failure from which the following decisions cannot recover.

• If you choose the wrong market in which to compete, your selection of the right customer group in that market is irrelevant.
• If you choose the wrong customer group, even in the right market, then it doesn’t matter which of those customer problems you choose to solve.
• Solving the wrong problems for the right customers makes the exercise of setting the bar for how good your solution will be (defining “good enough”) pointless.
• If you set the bar too low from your customer’s point of view, it does not matter how elegant your design is.
• With the wrong design, the level of quality, efficiency, and speed of your execution is unimportant.

If you don’t make all of these decisions well, you end up building the wrong product.

(Larger image)

In an excellent article from June 2025, my friend Rich Mironov wrote about the explosion of interest in AI-coding in his article Bottlenecks, AI, and Where Product Adds Value. This is timely stuff. Rich has an optimistic take – by changing the bottleneck associated with the capacity to execute, product managers will naturally gravitate ‘upstream’ to put better emphasis on these weighty decisions. I have a worry that little will change about how we approach these pivotal decisions, while cost-fixated execs are enamored with replacing their payroll expenses with smaller token-expenses.

Remember, it’s the people who sell those tokens encouraging the shift.

The Case for Uncertainty

Underlying the decision cascade in the above diagram are two categories I identify, “Market Uncertainty” and “Implementation Uncertainty”. These are concepts I embraced (co-opted?) from Rita McGrath’s work, shared in The Entrepreneurial Mindset.

To truly oversimplify McGrath’s model, the greater the market uncertainty, the less likely we are to be right in our decisions about what we need to do. Similarly, the greater the implementation uncertainty, the more likely we are to make mistakes about how to do it.

The dominant question you should have in your product development operations is not “did we finish?” but rather “did it work?”

Estimation errors increase because different approaches end up not working. We go back to the drawing board. In the agile world, the notion of a “spike” emerged as a way to account for the capacity applied to learning different approaches to building what the team was trying to build. Often, spikes are architectural in nature, but I’ve also seen them used to reflect explorations of usability. The conversation is easy to understand – the original estimate is for the work required to try the first idea. Those estimates get sidelined when the team discovers they need to try a different approach.

The greater the implementation uncertainty, the more likely our first solution idea is to be wrong.

Requirements errors is such a horrible phrase, but it is the one which has ossified over the years in the order-giver / order-taker world. “That is a requirement error, we built what you told us to build.” Design decisions, in my opinion, are in the domain of “how to do it” not “what to do.” I appreciate that every person on the team may use different labels to describe these decisions (if you want to jump 20 years back on memory lane you can see how I was talking about it in 2006). Regardless of the labels, this where choosing the right markets, customers, and problems lives.

The greater the market uncertainty, the more likely we are to be building the wrong product.

Instead of making my pitch for why uncertainty is higher today than ever before, I’ll just ask you to think about what you see. Is technology evolving faster now in a way your competitors could exploit, or your engineers are embracing – making the impossible possible and the impractical practical? Are these rapid changes causing customer expectations to similarly rapidly change? Are the mechanisms of value creation for your customers changing? Are the problems they face today and will face tomorrow changing? If you’re seeing this, you aren’t in an environment of low uncertainty.

Product Manager as Orchestrator

I’ve seen people share their belief that the product manager is the orchestrator who just needs their team to build what they imagine. This is the product manager I want to compete against. Their individual mistakes will be solidified, unassailable, difficult to discover and correct. Their teams will build the wrong products, even if they build them well.

The vibe coding push explores the possibility for a product manager to act independently to both choose a problem and then choose and prototype a solution approach, asking the rest of the team to “polish” their idea. This approach can be appealing, particularly when you manage product development as a cost-center and not a profit-center.

I think the dictator product manager is a real problem for a couple reasons, centered primarily how we think and how we design. To explain quickly, I need to shift away from an unfortunate thinking frame most product folks have – the double diamond. The double diamond mistakenly describes product creation as a sequence of first selecting a problem to solve, and then selecting a solution to the problem. The research tells us it doesn’t work that way, and my experiences working with teams and in technology for 35 years agrees.

Hat tip to my friend Will Haas Evans at Fugue Strategy Advisors for helping me clarify this insight. It is through our efforts to solve a problem by which we truly understand it. It is in the attempt to design and build the right interaction to help a customer solve their problem that we discover we’re solving the wrong problem. Vibe coding a “show don’t tell” solution dramatically reduces or eliminates that exploration. My problem isn’t that “showing” is faster than “telling.” My problem is that by changing the structure of the communication this way it prevents exploration and displaces collaboration.

A true understanding of the problem to be solved only emerges through exploration of solution ideas and approaches. It is in the elaboration of understanding the solution through which we refine our definition of the problem. This is messy. It needs to be messy.

What percentage of products succeed? Maybe 20% of the low-hanging fruit pursuits of risk averse large companies. Less than 1% of innovation initiatives from startups.

The “should product managers create prototypes on their own?” question feels odd in the double-diamond frame. The product manager eliminates the solution space. This is obviously problematic when acknowledging the emergence pattern of reifying the problem through pursuit of a solution. One of the pieces of research worth exploring if this is your jam is How Designers Work – Making Sense of Authentic Cognitive Activities published by Henrik Gedenryd in 1998. The emergence phase is where we form the insights which improve our answers to the questions on the left.

Having an AI build a prototype for you, regardless of how much re-prompting you do to refine your solution ideas, breaks all of this. So broadly “don’t do that” is my TL;DR

The rush to prototyping is doubling-down on the wrong mindset. For two reasons. First, design fixation will lock everyone into the particular solution approach of (and implied problem definition of) the prototype. David Jansson and Steven M Smith published their research while at the Institute for Innovation and Design in Engineering at Texas A&M. The teams will cycle around making the best version of this first idea – it becomes almost impossible to explore other ideas. If you are operating in a domain with any implementation uncertainty, this is a problem. You essentially eliminate the entire emergence phase of ideation. You’re likely forcing the team into building the wrong solution even if you focused on the right problem for the right customers. And now the process can no longer help you improve those decisions if you got it wrong. Which you probably did based on industry product-success statistics.

Second, you relegate all of your teammates into an order-giver / order-taker pattern, asking them to polish your brilliant idea, to make your perfect prototype “production ready”. This is more than just rude, it simultaneously devalues and dismisses all of the contributions they could be making.

The smartest person in the room is never smarter than the combination of the people in the room.

Enabling Emergence

There are a lot of issues with a lot of organizations, preventing or undermining the emergence phase of cross-functional product development. I help clients identify and address those issues. When I see a product manager proudly vibe-coding their way past collaboration and emergence, I see a problem. The operational patterns which help us better to learn are getting sidelined instead of embraced.

More than ever, we are placing product bets into an uncertain future. Don’t undermine your ability to navigate uncertainty by lashing the wheel and preventing yourself from course-correcting.