Discover
The first and most important stage. Everything downstream depends on getting this right.
At this stage you are not solving anything. You are asking questions until you understand what's actually happening, who it's happening to, and why it matters. The output is a problem statement — not a solution, not a hypothesis about a solution, not a feature idea dressed up as a problem statement. A problem statement.
Most bad products were built by teams that skipped this or rushed through it. They moved to Define with a symptom they mistook for a problem. They built the wrong thing with great execution.
How to Define a Problem
A problem statement has five parts. If any are missing, you're not done.
Who has it. Not "users." A specific person in a specific situation. A clinic coordinator trying to rebook a patient. A finance manager closing out the month. A field technician logging a job from a mobile device. The more specific you are, the better the solution will be.
What they're trying to do. The underlying goal, not the thing they're asking for. People request features. What they actually have is a job they're trying to get done. Find the job. "I want a reschedule button" is a feature request. "I need to move a patient to a different slot without losing their information or creating a gap in the schedule" is the job.
What's getting in the way. The specific friction between where they are and where they need to be. Not a category ("the UX is bad") — the actual moment it breaks down.
What they do today. If the problem existed before we built anything, people found a workaround. If it's a new problem we introduced, they abandoned or complained. Either way, understanding the current behavior tells you a lot about what success looks like.
What happens if we don't solve it. Business impact. Retention risk. Support volume. Time cost. If you can't articulate the cost of inaction, you don't know whether this problem deserves to be solved.
A well-defined problem makes the rest of the process faster. It gives Define a real target to aim at. It lets everyone on the team ask "does this solution actually solve the problem?" without it being a debate.
Symptoms vs. Root Causes
The most common mistake in discovery: you land on a symptom, mistake it for the problem, and define it.
A symptom is observable. It's the thing you can see, measure, or complain about. A root cause is what's generating the symptom. They are not the same. Solving a symptom patches the surface. Solving the root changes how the system works.
The test: if you fix what you're about to fix, could the same result arrive through a different path? If yes, you're fixing a symptom.
Two questions that help you locate where you are. First: has some version of this happened before? If a problem keeps recurring despite being "solved," you've been solving the symptom. Second: does your answer describe this event, or does it describe how the system works? "The vendor missed the deadline" describes the event. "We don't build in buffer for external dependencies" describes the system. You want to be operating at the system level.
Ask why until the answer changes category. "Support tickets are up" → why? → "Users can't find the settings page" → why? → "We moved it in the last release without updating the nav" → why did that happen? → "There's no checklist for nav changes before release." The last answer is a system. That's where you want to be.
A few other signals. Root causes are usually smaller and more uncomfortable than symptoms. The fix feels almost too simple — let air out of the tires instead of raising the bridge. And the discomfort is directional: root causes point at decisions you made, defaults you've been protecting, habits you didn't want to examine. That discomfort isn't a reason to stop. It's confirmation you're close.
One edge case: sometimes the right place to act is the symptom, because you need to stop the bleeding now. That's fine. Just don't confuse triage with resolution. Fixing the symptom buys you time. It doesn't replace finding what generated it.
Read: Symptoms Aren't Problems, Find the Root
First Principles Thinking
Most of the time we don't start from scratch. We start from what already exists: the feature someone requested, the solution a competitor ships, what our current system supports, what the team is used to building. This is efficient when the existing frame is right. It's a trap when it isn't.
First principles thinking means stripping the problem down to what you actually know to be true, then reasoning up from there — rather than reasoning from analogy with what you've seen done before.
In practice, this means asking: what is the actual underlying need? Not "what did they ask for" or "what would fix the thing they complained about." What is the person fundamentally trying to accomplish, and what would need to be true for them to accomplish it? Then ask: what's the simplest system that would make that possible? What assumptions are we carrying from our current implementation that aren't actually requirements?
This is most useful when you're stuck in local optima. When every solution you're considering feels incremental, like adjusting the existing thing rather than rethinking it, first principles is the way out. You ask: if we were starting this product from zero today, with everything we now know about our users, what would we build? The answer is often different from what you're incrementally improving.
A common mistake: treating constraints as fixed when they're actually inherited. "We can't do X because our data model doesn't support it" might be true. Or it might mean "we've never questioned the data model." First principles asks you to separate real constraints from assumed ones.
This doesn't mean ignoring existing work or rebuilding everything from scratch. It means holding assumptions loosely enough to question them when a problem demands it.
The Output
Before leaving Discover, you need a written problem statement that covers:
- Who has the problem (specific, not general)
- What they're trying to accomplish
- What's blocking them
- The cost of not solving it
- No proposed solution
This goes in the Request module. It's not a spec. It's not a brief. It's a clear statement of what's broken and why it matters. PM owns it. Everyone should be able to read it and understand the problem without asking follow-up questions.
If you can't write this without including a solution, you haven't finished discovery yet.
Next: Define