Discovery Is Three Jobs Wearing One Word

A few years ago I watched a B2B team run what everyone in the room would have called textbook discovery. We built a prototype, showed it to customers, learned something, adjusted, showed it again. The loop ran clean. The ritual was correct. And it still took us the better part of a quarter to notice that the thing we were refining so diligently was solving a problem the customer did not actually have.

Nobody had done anything wrong by the book. That was the unsettling part. We had followed the process and the process had quietly walked us into a wall.

I did not have language for what went wrong until recently, when Antti Latva-Koivisto named it better than anyone I have read. The word "discovery," he points out, hides three completely different jobs. Once you see them apart, you cannot unsee how often teams are only doing one of them and calling it all three.

One Word, Three Different Jobs

Discovering the problem is investigative work. What situation is the customer actually in, what are they trying to get done, where does it hurt. Inventing what the product should do about it is design. Figuring out whether the technology can even deliver that is engineering. Different skills, different sources of evidence, and, crucially, a logical order between them.

• Discovering the problem asks what is true about the customer
• Designing the solution asks what we should build in response
• Judging feasibility asks whether we can actually deliver it

You cannot design a good solution before you understand the problem. You cannot judge feasibility before you know what the solution is even supposed to do. The order is not a preference. It is a dependency. Skip the first and everything downstream is built on a guess.

What Mainstream Discovery Actually Does

Here is the structural reason this keeps happening. Mainstream discovery collapses all three jobs into a single loop. Build a prototype, show it, learn, adjust, repeat. The loop is genuinely good practice in many situations, which is exactly why it spread. It feels like motion. It produces artifacts. It gives a team something to react to.

But the loop has no idea which layer it is testing. A prototype mixes a problem assumption, a solution idea, and a feasibility bet into one object and shows the whole bundle to a customer at once. When they react well, you do not know which part earned the reaction. When they react badly, you really do not know.

When a prototype fails, the team learns that something is wrong. It almost never learns which of the three things.

So you guess. Was the problem wrong? The solution? The tech? You pick the layer that is easiest to change, usually the solution, tweak it, and run the loop again. And we call the guessing best practice, because the loop itself looks so disciplined while you are doing it.

The Cost Is Not Evenly Distributed

In consumer products the cost of one wrong loop is often small. You ship, you watch the numbers, the feedback is fast and cheap, you correct. The blur between the three layers gets absorbed by sheer iteration speed. You can afford to not know which layer broke because you get another swing next week.

In complex B2B, which is where I have spent most of my career, this is not true at all. A single wrong-direction cycle can burn months and a lot of money before anyone notices that it was layer one, the problem, that was off the whole time. The sales cycle is long, the customer sample is small, the feedback comes slowly and through too many filters. By the time the loop tells you something is wrong, you have already built, sold, and partly delivered against a misunderstanding.

What gets lost is not just the time. It is the team's ability to learn from its own failure. A loop that cannot tell you which layer broke teaches you nothing precise. You end the quarter with a vague sense that customers were not excited and no idea where in the chain the truth went missing. So the next quarter you guess again, a little more tired.

The Unlock Is Refusing to Blur

The fix is not a new framework. It is almost embarrassingly simple. It is refusing to blur the three. Name them, and let each one have its own question and its own evidence. Problem discovery gets answered by talking to customers about their situation, not by showing them a screen. Solution design gets judged on whether it actually addresses a problem you have already confirmed is real. Feasibility gets its own honest engineering answer instead of an optimistic shrug.

The moment the three sit apart, something useful happens. You can see which layer your team keeps skipping. In my experience it is almost always the first one. Problem discovery is the slowest, the least tangible, the hardest to show in a sprint review, so teams quietly skip it and let a prototype pretend to answer a question it was never built to answer.

When I designed the strategy and feedback loops for the product I am building now, I kept these three layers separate on purpose, before I had a clean name for why. Antti just gave the separation its name. Having the name matters more than I expected. It turns a vague instinct into something a team can actually hold each other to.

The Honest Question

So the useful question to ask in your next discovery review is not "are we doing discovery." Of course you are, the rituals are all there. The honest question is which of the three you are actually doing this week, and which two you are quietly hoping a prototype will answer for you.

Ask it out loud once and watch the room. The job everyone assumed was covered is usually the one nobody owns.