Product discovery in practice: frameworks tested in real cases

The most expensive part of building a product is not the engineering. It's building the wrong thing competently. Entire teams spend months delivering, with impeccable technical quality, a solution that no one asked for for a problem that didn't exist.

Product discovery exists to avoid exactly this. It is the set of practices that answers, before construction, a brutal question: is it worth building this? For whom? Why?

Discovery frameworks help structure this investigation. But their theory is easy to praise and difficult to apply. That's why this text is based on real cases, situations in which discovery decided the fate of the product, for better or for worse.

The case of the feature that no one used

Start with the most common mistake. A company decides to build a feature because "customers asked for it." The team executes, launches, celebrates, and adoption is almost zero.

What happened? Customers did ask, but they asked for a solution, they didn't describe a problem. When you literally build what the customer asks for, without investigating the problem behind it, you often deliver something they misimagined.

Discovery would have changed the game here. A round of interviews focused on understanding the context, not the feature, but the pain, would reveal that the real problem was another, with a much simpler solution. The lesson: The customer request is a symptom, not the diagnosis.

The case of digital government that no one could use

In the public sector, the pattern repeats itself with more serious consequences. Imagine a city hall that digitizes a service, say, scheduling an appointment or issuing a document, investing in robust technology.

The system goes live, is announced as a modernization, and the in-person queue remains the same. Why? Because no one validated whether real citizens could use it. The target audience included people with low digital familiarity, unstable connection, and doubts that the flow did not anticipate.

Discovery, here, is not a startup luxury. This is what avoids spending public money on systems that do not fulfill their social function. A few conversations with real citizens, before building, would have revealed barriers that no internal meeting would have anticipated. The cost of discovery is negligible compared to the cost of a service that excludes those who should serve it.

Frameworks that work when taken seriously

Real cases show that some discovery frameworks hold up better than others under pressure.

Continuous Discovery (continuous interviews). Instead of one-off research before the project, weekly conversations with users over time. The typical success story is the team that discovers a critical objection early, because they were in constant contact with those using the product.
Opportunity Solution Tree. Connects business results, discovered opportunities and candidate solutions in a visible tree. It works because it forces the team to justify why a solution solves a real opportunity, not a intuition.
Prototype testing before code. The classic case is validating an idea with a navigable prototype and discovering, in an afternoon, that the flow didn't make sense, saving weeks of development.

The common point of these successful frameworks is direct and frequent contact with reality. Discovery that only happens in a meeting room, with hypotheses about the user instead of conversations with the user, usually fails in the real case.

The case of discovery that became an excuse

There is also the opposite side, and it is honest to recognize it. Discovery can become paralysis. I've seen teams use "we're still in discovery" as a shield to never decide.

Research that never converges is not care, it is fear. In a real case of a startup, months of research delayed a launch that the market was already asking for, and a less careful but more determined competitor took the space.

Discovery has to have a deadline and purpose. The goal was never to understand everything, it was to reduce uncertainty enough to decide responsibly. When the team confuses discovery with the search for absolute certainty, it exchanges the risk of making mistakes for the equally real risk of never acting.

The case of discovery that changed the strategy, not just the feature

It is worth a case that shows discovery operating at another level, not to decide a functionality, but to correct the course of an entire bet.

Imagine a company convinced that its audience wanted a more complete product, full of features. The leadership's intuition was clear: competition was too simple, and differentiation would come through depth. The entire roadmap pointed in that direction.

A serious round of discovery, ongoing conversations, observation of actual usage, revealed the opposite. Users didn't want more features; They wanted what little that already existed to work in a simpler and more reliable way. The complexity that the company intended to build was exactly what kept people away.

The value of discovery, in this case, was not in saving a few weeks of development. It was to prevent the company from investing months building its own strategy in the wrong direction. Discovery, taken seriously, sometimes doesn't adjust what you build, it questions whether you should be building it.

This is the most difficult and most valuable use. It requires leadership to be willing to hear that their conviction may be wrong. Teams that do discovery just to confirm what they have already decided are not investigating; They are seeking applause. And applause doesn't protect anyone from a bad bet.

When discovery is really worth the investment

The decision about how much discovery to do is, in essence, a risk analysis. The greater the uncertainty and the greater the cost of making mistakes, the more discovery is justified.

Build a small, reversible and cheap feature? Sometimes it's worth taking a risk and learning in real use, extensive discovery would be a waste. Build an expensive bet, difficult to reverse, that defines the company's strategy or affects thousands of citizens? Then discovery is not a cost, it is safe.

Mature leaders calibrate this on a case-by-case basis. Treating discovery as mandatory in everything is as naive as treating it as optional in everything. The right question is always proportional: how much do I lose if I'm wrong, and how much does it cost to find out first?

Closing

Real cases teach the same lesson in different ways. Those who investigate the problem before building waste less, get more things right and sleep better. Those who skip this stage pay later, in rework, in money, sometimes to the exclusion of those who most needed to be served.

Discovery does not guarantee success. It ensures that when you make a mistake, you make a mistake cheaply and early, with a chance to correct it. In product, this is almost everything.

If your organization tends to build first and discover later, it might be worth reversing the order before making the next big bet. There are other articles here about discovery and design frameworks that go deeper into the topic.