Discovery: Finding the Real Problem, Not Inventing a Solution
Understanding why teams often solve the wrong problems, and how the Discovery process, based on WHAT-HOW-WHY, helps ground the pain in observable reality.
Discovery: Finding the Real Problem, Not Inventing a Solution
In product development, there's a fundamental temptation—to jump into creating a solution as quickly as possible. Mockups, plans, tasks in a tracker—all give the team a pleasant sense of control and movement. But too often, this movement is to nowhere. Teams spend months creating elegant solutions for problems that don't exist.
The Discovery process is meant to combat this temptation. Its main goal is not to invent a solution, but to catch a real breakdown and formulate it in such a way that the entire team works on the same, truly important problem.
The Main Question of Discovery
What problem are we actually solving—and for whom is it critical?
If you can't answer this question clearly, any solution will be just a hypothesis built on sand.
The Fundamental Principle
A problem exists only when it hinders both the user and the business simultaneously.
Just 'inconvenient' is not yet a problem. But 'inconvenient, and because of it, we lose 20% of users at the activation stage'—that is a problem worthy of attention.
Problem Space vs. Solution Space: The Golden Rule of Discovery
The entire Discovery process can be divided into two major parts:
- Problem Space: What exactly is breaking, for whom, where, why, and how much does it cost?
- Solution Space: What intervention options are possible (buttons, features, redesign)?
The golden rule: until the Problem Space is defined, discussing the Solution Space is like choosing wallpaper while the house is on fire. Pretty, but useless.
The Discovery Model: WHAT — HOW — WHY
To structure the Problem Space, use three simple lenses:
1. WHAT — What is Breaking? (The Observable Symptom)
This is not 'users don't like it,' but a specific, measurable signal.
- Examples:
- A drop in conversion at step X from 40% to 25%.
- A 15% increase in churn in segment Y.
- A spike in support tickets with the tag 'can't find the report.'
- Users are massively exporting data to Excel (a workaround).
WHAT should be described without interpretation—just the facts.
2. HOW — How is it Happening? (The Mechanism, Scenario, Context)
Here we dive into the user's reality to understand the cause of the breakdown.
- What we're looking for:
- Trigger: Why did the user even start this scenario?
- Constraints: What context are they in (short on time, on a mobile device, company policy)?
- Friction: What exactly is getting in the way? (Not 'bad UX,' but 'I have to fill out 8 fields, and I'm driving').
- Workarounds: What do they do instead of the 'correct' action?
This is where the real cause of the problem is born.
3. WHY — Why Does it Matter to the Business? (The Stake and the Price)
A problem becomes a product problem only when it has a price for the business as well.
- What we're looking for: How does the user's problem translate into losses for the company?
- Example: 'It's inconvenient for users' → 'they don't complete onboarding (
HOW)' → 'activation drops (WHAT)' → 'LTV decreases and marketing costs rise (WHY)'.
WHY is the answer to the question 'why should we even be dealing with this?'.
Conclusion
Discovery is not 'collecting opinions.' It is a discipline that produces clarity. It forces the team to first deeply understand what is breaking, how it is happening, and why it is important, and only then move on to finding a solution.
If after the Discovery phase you can't formulate a Problem Statement without the words 'button,' 'feature,' or 'redesign'—you haven't been in the Problem Space. You were just looking for an alibi for a solution you had already come up with.