Discovery is not asking customers what they want

One of the most dangerous shortcuts in discovery is thinking that it is enough to ask customers what they want. It sounds reasonable: if we are building something for them, why not start from their requests?

The problem is that customer requests are often solutions disguised as needs. They come filtered through the tools people already know, the workarounds they have invented, and the frustration they feel in the moment. If we take them literally, discovery becomes order taking.

A product team should not ignore those requests. It should treat them as clues. Behind “I need an export” there may be a reporting problem, a trust issue with the data, a manual review done every Friday, or a manager asking for updates outside the system. The request is the starting point, not the answer.

Discovery reduces uncertainty

Teresa Torres defines continuous discovery as weekly touchpoints with customers by the team building the product, through small research activities in pursuit of a desired outcome. That definition is useful because it moves discovery from “doing interviews” to “making decisions with recent evidence”.

The useful word is rhythm. Discovery should not be a ceremonial phase before delivery, or a large research project every six months. It should be how the team reduces uncertainty while it builds.

That uncertainty has different forms. There is value risk: does this solve a problem that matters? There is usability risk: will people understand how to use it? There is technical risk: can we build it well with the time and stack we have? There is business risk: does it make sense for the economic model, support, compliance, and go-to-market?

SVPG often uses these four lenses in its Product Operating Model: valuable, usable, feasible, viable. They are simple, but they help avoid a common trap: validating only the part that is easiest to validate.

Customers know the problem better than we do

Customers know their context better than we do. They know where they lose time, what irritates them, what they work around every week, and which spreadsheets they keep open because the product does not help enough. We should listen carefully to that.

But they do not always know the best solution. A customer sees the problem from where they are today; the product team should also see alternatives, technical constraints, patterns across customers, and the future cost of each choice.

When a customer asks for a feature, the first question is not “should we build it?”. A better question comes first: what job are they trying to do, and why does the current product not support it?

That distinction changes the conversation. Instead of defending or promising features, the team can examine real behavior: when it happens, who is involved, what happens before, what happens after, and what breaks if the problem remains unsolved. Discovery becomes less opinion-based because it starts to sit on actual evidence.

Weak discovery becomes a swollen roadmap

When discovery is weak, the roadmap fills with plausible work. Every request has a convincing story, every stakeholder has a reason, every important customer seems to bring a legitimate urgency. The problem is that a roadmap full of plausible things is not a strategy.

The build trap often starts there. Not because the team is lazy or incapable, but because it is doing good work on poorly chosen problems. Delivery continues, releases ship, velocity looks healthy. Months later the product is more complex, but not much more useful. That is why discovery has to stay connected to how the team measures outcomes, not only to how much it ships.

Good discovery does not remove that risk. It makes the risk visible earlier. It forces the team to state assumptions, choose which uncertainty to reduce, and accept that not every request deserves the same investment.

That is why rituals alone are not enough. You can have interviews, surveys, opportunity solution trees, insight repositories, and well-run workshops. If no one connects that work to actual priority decisions, discovery becomes theater.

What changes for a founder or startup

In a small team, discovery has to stay light. You do not need a research department, and every decision should not get slowed down by a large process. But the opposite mistake is just as risky: deciding only from internal urgency, loud customers, or founder intuition.

A sustainable practice can be simple: speak every week with someone living the problem, collect real examples, separate the request from the need, and choose one assumption to test before building. It is not glamorous, but it changes the quality of the roadmap.

In many contexts, the role of a Fractional PM is to help the team build that rhythm without turning it into bureaucracy. Not replacing the founder, not imposing frameworks, but creating a more reliable way to decide what is worth building.

Discovery is not there to know everything. It is there to avoid building for weeks on a certainty that nobody checked.