Discover
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.
Most bad products were built by teams that rushed this stage. They moved to Define with a symptom they mistook for a problem, and built the wrong thing with great execution.
How to Define a Problem
What's expected: A complete problem statement before any solution is considered. Not a feature request, not a pain point vaguely described. A specific, written statement that answers: who has this problem, what are they trying to do, what's getting in the way, what they do today, and what happens if we don't solve it.
What good looks like: Someone reads it cold and understands the problem without asking a follow-up question. There is no solution embedded in it. The person is specific ("clinic coordinators rebooking after a cancellation"), not generic ("users"). The cost of inaction is quantified or at minimum clearly stated.
Bad: "Users are having trouble with the scheduling flow."
Good: "Clinic coordinators need to move a patient to a different slot after a cancellation. Today they do this by cancelling the appointment, losing the patient's intake data, and manually re-entering it in the new slot. This takes 8–12 minutes per rebooking and creates 3–5 support tickets a day. If we don't solve it, coordinators will keep working around the system instead of in it."
How to get there: Work through five questions in order. Don't move to the next until the current one is answered specifically.
- Who has this problem? Name the role, the context, the situation.
- What are they trying to accomplish? Find the underlying job, not the surface request.
- What's blocking them? The specific friction, not a category.
- What do they do today? The workaround tells you a lot about what success looks like.
- What happens if we don't solve it? Business impact, retention risk, time cost.
Tools:
- Abstraction laddering — move up and down levels of abstraction to make sure you're framing the problem at the right level. "The button is hard to find" is too narrow. "Users can't navigate the scheduling module" might be the right level. "Our product doesn't fit the coordinator's workflow" might be even more useful.
- Issue trees — break the problem space into branches to make sure you're not missing a dimension. Useful when the problem feels large or multi-part.
Root Cause vs. Symptoms
What's expected: You've gone past the first plausible answer. The problem statement describes what's generating the problem, not just the observable event.
What good looks like: Your answer changes category — from describing the event to describing how the system works. "Support tickets are up" is an event. "We moved the settings page without updating nav" is a contributing factor. "There's no pre-release checklist for navigation changes" is a system. Good looks like the system level.
The fix also feels smaller and more uncomfortable than you expected. Simple, quiet, permanent — letting air out of the tires instead of raising the bridge.
How to get there:
Ask why until the answer stops describing this situation and starts describing a default. Each "why" should change the category of the answer, not just add detail to the same category.
Check for recurrence: has some version of this happened before? If yes and you "fixed it" last time, you fixed a symptom. The root is still there.
Check the fix: if you fixed what you're about to fix, could the same result arrive through a different path? If yes, you're still at the symptom level.
Note the discomfort: root causes tend to point at decisions you made, defaults you've been protecting. The discomfort is directional information, not a reason to stop.
Tools:
- Five Whys — ask "why" five times in sequence. Each answer becomes the input to the next question. Simple and effective for most problems.
- Ishikawa diagram — maps possible causes across categories (people, process, tools, environment). Useful when you're not sure which dimension the root cause lives in.
- Iceberg model — distinguishes between the visible event, the patterns beneath it, the underlying structures, and the mental models driving those structures. Useful for problems that keep recurring.
Read: Symptoms Aren't Problems, Find the Root
First Principles Thinking
What's expected: You've questioned the inherited assumptions in the problem framing. You know what you actually know to be true versus what you're carrying from convention, past implementation, or what a competitor does.
What good looks like: You can state the fundamental user need in one sentence, stripped of any reference to current solutions. You've identified at least one assumption that seemed like a constraint but isn't. The solution space feels more open than it did when you started.
How to get there:
Start by listing what you think you know about the problem. Then go through that list and mark each item: is this something I know to be true, or is this an assumption I'm carrying? For every assumption, ask: what would I think if I didn't know this?
Then ask: if we were starting this product from zero today, with everything we know about our users, what would we build? The gap between that answer and what you're incrementally building is the size of the assumption debt.
Look at constraints separately. "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." Separate real constraints from inherited ones before treating them as fixed.
Tools:
- First principles — decompose the problem to its fundamental truths, then reason up from there rather than by analogy.
- Abstraction laddering — move up to find the deeper need, move down to find concrete solutions. Useful for breaking out of local optima.
- Inversion — instead of asking "how do we solve this?", ask "what would make this problem worse?" or "what would have to be true for this problem to not exist?" Often reveals assumptions you didn't know you were making.
Validating Against Data
Before the problem statement is considered complete, it gets validated against real data.
What's expected: The problem statement is submitted through Glide, which runs it against agents with access to Metabase and other data sources. The agents check whether the data supports the problem — usage patterns, support ticket volume, frequency, affected user segments. If the data contradicts or doesn't support the statement, you revise it.
What good looks like: The problem statement is backed by data, not just observation or intuition. "Coordinators spend 8–12 minutes per rebooking" becomes a verified claim, not an estimate. The data either confirms the problem is real and significant, or it reframes it.
How to get there: Submit the problem statement in Glide. Review what the agents surface. If the data supports it, move forward. If it doesn't — or tells a different story — go back to the problem statement and revise. This is not a blocker to avoid; it's the step that prevents you from defining and building the wrong thing.
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, backed by data
- No proposed solution
This goes in the Request module. 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