Product discovery frameworks with examples: from problem to decision

Product discovery suffers from a curious problem: almost everyone agrees that it is important and almost no one does it right. The theory is repeated everywhere, understand the problem before building it, but when it comes to applying it, the team doesn't know where to start.

The difference between knowing discovery and practicing it lies in the frameworks: structures that transform the good intention of "understanding the user" into a concrete set of steps. Without them, discovery becomes vague talk; with them, it becomes a method.

This text explains the main frameworks with examples. It's not a list of definitions, it's a demonstration of how everyone takes a confusing problem and turns it into a decision.

Before frameworks: what discovery tries to avoid

It's worth starting with the problem that all of this solves. Imagine your team has an idea: add chat to the product. Looks useful. The team is excited and wants to build.

Without discovery, the next step would be to estimate and develop. With discovery, the next step is a question: what problem does this chat solve, and how do we know it actually exists? It is this question, multiplied and structured, that frameworks help answer.

The central thesis of this text is that discovery is not used to generate ideas, it is used to kill the bad ones early and cheaply, before they become code. Good frameworks are, first and foremost, machines for eliminating bad bets.

Opportunity Solution Tree: connecting objective, problem and idea

The Opportunity Solution Tree is one of the most useful structures for organizing discovery. At the top, you put your desired business outcome. Below, the real opportunities, problems or needs of users. Below the opportunities, the candidate solutions.

Concrete example. The business outcome is “increase retention in the first month”. Opportunities discovered in interviews are: “user doesn’t understand the value right away” and “user gets stuck on initial setup”. Only then do the solutions emerge: a guided onboarding, an initial template, a short video.

The power of the example lies in the discipline that the tree imposes. You can't justify a solution without linking it to a real opportunity. That chat idea? If it doesn't connect to any discovered opportunities, it falls. The tree exposes what was just will.

Discovery Interviews: The Right Question Example

Interviewing users seems simple, but most people do it wrong. The classic mistake is to ask about the future and opinions: "Would you use a chat feature?" The answer is almost always a nice and unhelpful “yes”.

The discovery interview framework turns this on its head. Instead of asking about the hypothetical future, you ask about the concrete past: "Tell me the last time you needed help using the product. What did you do?"

Example of the difference. When you ask about the past, you discover that the person didn't look for any chat, they sent an email and waited, or gave up. This reveals that the real problem may be something else: the lack of quick responses, not the absence of a chat. The right question completely changes the conclusion.

Prototype testing: validate before building

Another practical framework is prototype testing. Before writing code, you create a navigable version of the idea and put it in front of real users to observe where they get stuck.

Example. The team prototypes the guided onboarding from the previous tree. When testing with five people, he realizes that three of them completely ignore the most important step. No requirements sheet would reveal this. Direct observation, yes.

The gain is obvious when you experience it: fixing a prototype takes minutes; Fixing software in production takes weeks and undermines user confidence. Testing early is the cheapest way to make mistakes.

How frameworks fit into a flow

These frameworks do not compete, they form a natural sequence of investigation.

Start with the business objective. Without clarity on the desired result, discovery becomes a journey without a destination.
Discover real opportunities with interviews focused on the past and concrete behavior.
Organize everything in an Opportunity Solution Tree to connect idea to problem.
Validate the chosen solution with a prototype before committing to engineering.

This flow transforms the vague question “what do we build?” in a chain of justified decisions. Each step eliminates weak hypotheses, so what makes it to development has already survived some scrutiny.

Example of discovery in a restriction context

The previous examples assume a relatively comfortable scenario: easy access to users, freedom to prototype, time to iterate. Reality doesn't always cooperate, and it's worth an example of discovery under restriction, because that's where the technique is most tested.

Think of a team that needs to validate a service for a hard-to-reach audience, say, citizens with low digital familiarity who depend on a public service. You can't summon them to a testing room; many would not respond to a formal invitation, and the artificial environment would distort behavior.

Discovery, here, adapts. Instead of the scheduled interview, observation at the in-person service point, where these people are already present. Instead of a sophisticated digital prototype, a paper sketch that anyone can have an opinion on. Instead of quantitative research, talk to employees who serve the public every day and know each barrier.

The principle of frameworks remains the same, understanding the real problem before building, but the execution respects the context. This is the most important example of all: discovery is not a fixed set of techniques, it is a commitment to reality that adapts to the restrictions of each case. To apply the method in a way that ignores the limitations of the audience is to betray the very purpose of the method.

Critical reflection: an example is not a recipe

This is where the necessary care comes in. Examples help to understand, but they become a trap when treated as a universal recipe. Copying another company's discovery flow without adapting it to your context is repeating gestures without understanding the reason.

Discovery is context-sensitive. The number of interviews, the depth of the prototype, the speed of the cycle, everything depends on the risk, budget and maturity of the team. An example of a technology startup may not serve a public body with legal and access restrictions, and vice versa.

Maturity lies in understanding the principle behind each framework, not in memorizing the step by step. Anyone who understands why the interview focuses on the past can adapt the technique; whoever only copies the script breaks in the first case outside the example.

Closing

Discovery frameworks transform the good intention of understanding the user into a replicable method. The examples show the path: from the business objective to the real opportunity, from the opportunity to the solution, from the solution to the validated prototype.

In the end, they all serve the same purpose, eliminating bad bets before they cost you. Discovery done well is not what generates the most ideas, it is what discards the wrong ones early.

If your team still builds based on opinion and guesswork, trying one of these frameworks in the next decision could change the result. There are other articles here about discovery with real cases and product design that continue the conversation.