3 mistakes founders make in product discovery

CB Insights analysed 431 failed VC-backed companies and found that 43% shut down because of poor product-market fit. Most of those companies had working software and willing engineers. What they lacked was a problem painful enough for anyone to pay to fix, and product discovery is supposed to catch that before it costs six months of runway. Most founders run some version of it, come away from user interviews feeling confident, and still build the wrong thing.

The three mistakes below describe how that happens in teams that believe they are doing it right.

How do you know if a problem is worth building for?

Before writing a single line of spec, there is one question worth answering in full: what does your target user currently do to manage this problem, without your product?

The answer is usually the most useful thing you will learn in early discovery. When users have a workaround, the problem is real: a spreadsheet held together with formulas, a manual process they have been running for years, a tool borrowed from a completely different context because nothing else fits. Workarounds are evidence that the friction is genuine and that users are not waiting around for someone to solve it. When there is no workaround and they shrug and say they just live with it, the problem is probably a nice-to-have.

The question founders usually ask in discovery interviews is “would you use a product that does X?” and it almost always gets a yes, because saying yes in that context costs nothing. Jeanette Mellinger, Head of UX Research at BetterUp, describes the better alternative as collecting specific stories about past behaviour rather than opinions about hypothetical futures. That means asking “walk me through the last time you dealt with this. What did you actually do?” A user describing their workaround in granular detail is worth more than twenty users nodding at a pitch.

The thing that corrupts most discovery sessions is pitching the solution and treating positive reactions as validation. The founder describes what the product will do, the user says it sounds useful, and that gets counted as a signal. Someone saying “that sounds useful” is in a completely different position from someone who spends two hours every week on a manual process because the market has nothing better, and conflating the two is where most discovery breaks down.

A useful self-check before moving forward: could you describe the workaround in enough detail to build a worse version of it yourself? If you can, the problem is real enough to build for.

How should founders use feedback from user interviews?

Users are reliable narrators of their own pain but not product designers, and treating them as one is where most founders go wrong with feedback.

In a good discovery interview, the user’s job is to describe what is broken in their current situation and what they already do about it; figuring out what to build from that is yours. Collapsing both functions by asking users what they want the product to do, rather than what their problem feels like, produces a feature list that satisfies the people who asked for it without building something worth switching to.

The failure mode is consistent: a founder runs twenty interviews, groups the responses by theme, and ships the features that came up most often. Six months later retention is poor, because the users described what annoyed them about the tools they already use, not what a fundamentally different product would look like. Building the literal feature requests they named gets you to a slightly improved version of what already exists, which is a much harder sell than something that solves the underlying problem differently.

Ant Murphy, who coaches product teams on discovery practice, makes the distinction clearly: discovery is about testing your riskiest assumptions, not collecting feature requests. Uber’s riskiest assumption had nothing to do with the app: it was whether people would get into a stranger’s car, and if that failed, everything else was irrelevant. Founders who use interviews to gather a feature wishlist skip the step where they find out whether the core thing they believe is true.

After each interview, write down two things: what is broken in the user’s current situation, and what they are already doing to manage it. If feature requests are showing up in those notes, the interview questions were leading the witness, and it is worth going back to ask about behaviour rather than preference.

Building the feature list is not the work. The product work that leads somewhere is about finding the smallest change that removes the largest blocker, not shipping everything users mentioned. A feature list with a logo on it is a backlog, not a validated product.

When does product discovery end?

Discovery does not end at launch; the shape of it changes. Before you build, the goal is to find out whether the problem is real and whether the proposed solution addresses it. Once the product exists, the question shifts to whether what you built is solving the problem you identified, for the people you thought it would. What should end at launch is the idea that discovery is a pre-build phase you complete and move on from.

Teresa Torres defines continuous discovery as weekly touchpoints with customers, run by the team building the product, in pursuit of a desired outcome. The frequency is the point: a quarterly research study or a big sprint before the next major release leaves too much time for the product to drift from the problem without anyone noticing, whereas small and consistent contact tends to catch that drift before it costs a full development cycle.

This does not require a research team or a formal process. One short user conversation per week is a reasonable starting point, alongside reviewing session recordings when something in the metrics looks off and treating support tickets as signals about what is not working rather than a queue to close. The goal is to keep the original problem definition in contact with what users are experiencing, because the two tend to diverge over time and no one announces when it happens.

Once a product exists, there is real pressure to switch fully into execution mode, because shipping a feature looks like progress and staying in contact with users can feel like the opposite. The assumption is that validation happened before launch and now the team just builds. That is exactly when the original problem definition starts to drift from what users are experiencing, while everyone is focused on the roadmap.

The mistake compounds when a product scales to new markets. The discovery that worked for the first audience does not transfer automatically, and teams that assume it does tend to spend quarters shipping features that make no sense to users in the new context.

One useful diagnostic: how long does it take from a customer signal to a shipped change? When the answer is measured in months, discovery is not connected to the roadmap in any meaningful way.

Why discovery fails even when founders think they’re doing it right

The 2026 Product Discovery Trends report from Perspective AI, which reviewed practices across roughly 300 teams, found that research is now “essential to all levels of business strategy” at 22% of organisations, up from 8% the year before. The number of teams running discovery has risen alongside the bar for doing it well, because running some discovery and running useful discovery are not the same thing.

The difference between founders who get it right and those who spend six months building the wrong product usually has nothing to do with how many interviews they ran. The question is whether they were testing their assumptions or collecting permission to build what they already planned. Confirmation bias runs through all three mistakes above. Once a founder believes in the solution, discovery tends to get shaped around confirming it: wrong questions get asked, feedback gets filtered toward what supports the plan, and the process stops the moment it feels like enough.

More interviews with the same questions produce the same noise. Changing the outcome requires better questions, attention to what users do rather than what they report, and treating discovery as a standing habit rather than a pre-build phase that ends at launch.

FAQ

1. What is product discovery?

   Product discovery is the process of confirming that a problem is real, that the people who have it are already doing something to manage it, and that the solution you are proposing is worth building before you commit engineering time to it.

2. How long should product discovery take?

   It depends on how much is unknown about the problem and the user. For a well-understood market, four to six weeks of focused interviews and testing is often enough, though stopping too early is the more common error. Discovery should also continue after launch in a lighter, continuous form, treated as a standing habit rather than a scheduled event.

3. What questions should founders ask in product discovery interviews?

   Focus on past behaviour rather than hypothetical preference. "Walk me through the last time you dealt with this" gives you more reliable information than "would you use a product that does X?" because it asks about something that happened, not something the user imagines they might do.

4. What is the difference between user research and product discovery?

   User research looks at how people interact with something that already exists; product discovery happens earlier and asks whether the thing you plan to build should exist at all. They overlap in method, but discovery is forward-looking and happens before the build decision is made.

5. Why do founders get product discovery wrong?

   Usually because of confirmation bias. Once a founder believes in the solution, they tend to shape the process around confirming it: leading questions get asked, feedback gets filtered toward what supports the plan, and the process stops the moment it feels like enough evidence, which is rarely when it is.

---

WAYF does not start building until the problem is clear. That discipline comes from watching what happens when a team skips this step. A vague problem definition produces a vague product, and vague products do not retain users. If you are mid-discovery and not sure whether you have validated the right thing, that is worth talking through before you write a spec.

Book a call

---

Sources

• Why Startups Fail - CB Insights
• The Early User Research Playbook for Founders - First Round Review
• A UX Research Crash Course for Founders - First Round Review
• Getting Started with Continuous Discovery - Teresa Torres / Product Talk
• 4 Common Product Discovery Mistakes - Ant Murphy
• 2026 Product Discovery Trends: What 300 Teams Changed - Perspective AI