Building May Be Cheap Now. Being Wrong Still Isn't.

What does the wrong thing look like? You've seen it. It's more common than ever: Things that look credible, work fine, but solve a problem nobody had. Or don't solve a problem in the right way. Or enter a space and ignore a glaring problem in that space. Or rely on a UI and visual design that doesn't serve the user. Wrong is everywhere now.

In a recent newsletter from Robbie Allen, an AI consultant and strategist, Allen writes that though “AI has collapsed the cost of building software,” it has done nothing to shift what he calls ownership costs. Build costs are “what it takes to turn a requirement into working software.” Ownership costs are “what it takes for someone on the business side to know what should exist, decide what it should do… and keep steering it for the next three years.” Bringing an idea to life can happen faster than ever, but that also means it's easier than ever to build the wrong thing.

So how do you know what to build? Allen's answer lies in ensuring headcount in ownership roles: roles like validation, QA, strategy, and IT leadership. Staffing these roles can fix ownership issues as a product is built, released, and supported. But it's what comes before all that that can set a solid foundation and head off problems at the ideation stage: discovery research. Allen's prescription staffs the deciding and the steering, but not the knowing, and knowing what should exist is the first item in his own definition.

When building was expensive, building was the constraint, and discovery looked like a tax on the constraint. Now that building is cheap, the constraint is knowing what to build. Every hour of discovery buys more than it used to, because it's no longer competing against a six-month engineering queue. Discovery research is the backbone that helps guide strategy, decision-making, QA, and ongoing product ownership.

In a 2026 webinar with GrowthBook, Ronny Kohavi offers an example from Bing illustrating the cost of designing the wrong thing. In his telling, roughly 100 engineers built a third pane for the product’s search window. The experiments for the feature failed to show value. It shipped to all users anyway on the reasoning that it was a strategic business move. A year later, after further experiments also failed to show value, it was rolled back at significant cost to the organization. A hundred engineers, a year of sunk time, and a full-scale rollback. The code was disposable, but the organizational bet wasn't. 

Kohavi’s central claim, from the book written with colleagues Diane Tang and Ya Xu, Trustworthy Online Controlled Experiments (Cambridge University Press, 2020), is that people are bad at predicting which ideas will prove valuable. His answer is developing a culture and process of highly scoped, well-defined, meticulously designed experiments with rigorous testing. But discovery research solves the problem even earlier in the process. It's the step that asks whether the thing should exist at all. "Does anyone want a third pane?" is a discovery question, and it isn't one experiments are built to answer. 

If things are easier to build than ever before, and easier to throw away than ever before, why not embrace rapid experimentation in place of research? Why not build three or four or five and see what sticks? As the Bing example illustrates, a prototype is disposable. A shipped thing is not. A shipped product or feature has consumed a roadmap slot, stakeholder credibility, a support burden, users' attention and willingness to try the next thing, and data you now have to migrate or delete. 

A reasonable objection to this argument is that maybe the problem isn't a shortage of discovery, but one of attachment. Maybe teams just need to get better at killing what isn't working and moving on. It’s true that roadmap slots can be reclaimed, and stakeholder credibility recovers. But your users' attention isn't yours to write off, and neither is their willingness to try the next thing you ship. The costs you can get better at absorbing are the ones you carry. The ones you can't are the ones your users carry for you.

The good news is that discovery itself has gotten easier. AI has helped make discovery research more efficient and scalable in terms of logistics like recruiting, scheduling, transcription, desk research, and competitive analysis. But deep synthesis, analysis, and learning about a space and its users is still necessary to narrow in on what a customer base might find valuable, whether you’re solving the right problem, and whether you’re building it in a way that will actually serve a user’s need. In Allen’s language, investing in discovery research dramatically reduces the ownership risk. The ratio between discovery cost and build cost didn’t shift as much as people assume with the advent of AI. What has shifted is the cost of being wrong. Now anyone can ship the wrong thing faster and at scale.

None of this means every idea needs a research phase. The more useful question isn't how much discovery you need; it's what you or your team are actually uncertain about. The rule? Do discovery research when you're uncertain about the problem. Do prototyping and user testing when you're uncertain about the solution.

Say a team knows their users abandon checkout, and they want to know whether a progress indicator or a guest checkout option is the fix. Should they commission a discovery study? No. They have a well-defined problem and a small, testable set of solutions. Build both, test both, and they’ll learn more in two weeks than a discovery plan would tell them. Research here would simply be ceremony.

Now take a client who came to us asking to add an AI assistant to their site to improve users' ability to find specific content. It’s a worthy goal, but an expensive solution for a problem we felt had been underexamined. Nobody had dug into what kind of findability issues their users were actually struggling with, or whether an assistant was the right solution for those issues. Working with our clients, we designed a short research engagement to ensure we were solving the right problem. Turns out an AI assistant would have made little to no difference. Rather than failing to find content, users were struggling to assess the content they found, having to dive several clicks deep before realizing something wasn’t relevant to their search. The solution to evaluating relevance looks very different: improving search filters, exposing metadata, and surfacing information users need to evaluate content earlier in their journey. Experimenting in this case wouldn’t have provided the right guidance if the premise itself had gone unexamined. 

The failure here lies in mistaking one kind of uncertainty for the other. Teams tend to mistake them in a predictable direction, because solution uncertainty is the kind you can build your way out of. But when you’re misunderstanding the problem to begin with? The answer still lies in discovery research.

In this reframing, research is a form of speed rather than diligence. Embracing research through this kind of Lean lens can help you move on quickly from bad ideas to new, more refined ones. Historically, teams have seen research as the thing that slows them down before they commit. What if we understood research as the thing that lets a team abandon fast? Using discovery research to stress-test ideas in the ideation phase helps sharpen a fruitful direction or identify a dead end. Research, then move on from wrong ideas quickly; get to the next idea with something learned. 

If execution is no longer what separates you, what you know about your users is the only thing a competitor can't copy in a weekend.