Discover

This is where the thinking happens. Discover and Define are where the team’s brainpower is concentrated. Build and Launch are execution: discipline, follow-through, and momentum. Get Discover and Define right, and the rest follows. Rush them, and no amount of effort in Build recovers it.

The underlying structure here is the double diamond: Discover is the first diverge: open up the problem space, explore broadly, resist narrowing too early. Define is the first converge: land on the right problem with precision. Build is the second diverge: explore how to solve it. Launch is the second converge: ship the right thing to the right people. PM owns all four phases.

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.

Where Problems Come From

What’s expected: PM is actively surfacing problems, not just receiving them. Problems come in through multiple channels and you need to be reading all of them.

What good looks like: PM has a regular habit of reviewing data signals, support patterns, and team observations. Problems are identified before they become loud enough that users complain. You bring a steady stream of well-framed candidates to leadership, not just the ones people shout about.

How to get there:

• Usage data — where are users dropping off, slowing down, or not returning? Low adoption of a feature, high exit rates at a step, low repeat usage. The data shows friction that users never voice.
• Support tickets — recurring themes in tickets are almost always product problems in disguise. One ticket is noise. The same complaint five times is a signal.
• Team observations — engineers notice things PMs don’t. Ops teams hear from customers directly. Create a lightweight habit of asking “what’s frustrating you or our users right now?”
• Direct user feedback — conversations, interviews, reviews. Qualitative signal that data alone can’t give you.

Not every signal is a problem worth solving. Part of discovery is filtering: distinguishing real friction from noise, and problems worth prioritizing from problems that can wait.

Not Every Problem Needs a Tech Solution

Before a problem goes to Define, ask: does this actually require us to build something?

What good looks like: You’ve genuinely considered whether the problem can be solved without code. If it can, you’ve said so and proposed the simpler fix. If it can’t, you’ve ruled out the simpler options and can explain why.

Some of the most common non-tech solutions:

• Training or documentation — users don’t know a feature exists or how to use it. The problem looks like missing functionality. It’s actually missing awareness.
• Process change — a workflow issue between teams or roles. The product works, but how people use it doesn’t. No feature fixes a coordination problem.
• Communication — something is confusing because it was never explained, not because it was designed wrong. A well-written email or tooltip solves it.
• Configuration — the product already supports what the user needs. It just hasn’t been set up correctly for their context.

Build is expensive. Always ask if a simpler fix exists first.

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 (“shoppers who reach the payment step but don’t complete the order”), not generic (“users”). The cost of inaction is quantified or at minimum clearly stated.

Bad: “Users are dropping off during checkout.”

Good: “Shoppers who reach the payment step abandon at a 60% rate. When they leave and come back, their cart is empty. They have to start over. This affects around 200 sessions a day and is our highest drop-off point in the funnel. If we don’t fix it, we keep losing high-intent buyers at the last step.”

How to get there: Work through five questions in order. Don’t move to the next until the current one is answered specifically.

1. Who has this problem? Name the role, the context, the situation.
2. What are they trying to accomplish? Find the underlying job, not the surface request.
3. What’s blocking them? The specific friction, not a category.
4. What do they do today? The workaround tells you a lot about what success looks like.
5. 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 pay button is confusing” is too narrow. “Shoppers lose their cart when they leave” might be the right level. “Our checkout flow doesn’t account for how people actually shop, across sessions, devices, and interruptions” might reveal an even bigger opportunity.
• 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, like 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: A Problem Is Not a Fix Request, 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: Every claim in the problem statement is checked against real data before the statement is considered complete. Usage patterns, support ticket volume, affected 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. “60% of shoppers who reach payment abandon” becomes a verified claim, not an estimate. The data either confirms the problem is real and significant, or it reframes it. Maybe the drop-off is actually at a different step than you assumed.

How to get there: Pull the relevant Metabase queries. Look at support ticket themes. Check usage drop-off data. If the data supports the problem statement, move forward. If it tells a different story, go back and revise. This is not a blocker to avoid; it’s the step that prevents you from defining and building the wrong thing.

Sharpening With Leadership

Before the problem statement goes to the Define session, PM brings it to leadership first.

Leadership probes the problem. PM presents the problem as they’ve framed it. Leadership asks questions, probing the framing, challenging assumptions, looking for what’s missing or imprecise. Is this the real problem or a symptom? Is the scope too wide? Too narrow? What does the data actually say? The goal is to sharpen the problem statement until it’s tight: the right problem, at the right level, with the right scope.

This step matters because the Define session is expensive. It pulls PE and PD into a focused block of time. Arriving with a sharp problem statement means that time goes toward solving, not reframing. A fuzzy problem brought to Define produces a fuzzy solution.

After the Define session, leadership reviews the definition doc before it moves to Build. The engineer has given the green light on implementability. Leadership reviews for direction, scope, and whether the solution actually solves the sharpened problem.

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 problem statement is the initiative’s Problem statement field on the story map. Quarterly planning seeded it as a rough metric goal and narrative bet; Discover is where it becomes precise. Define adds the solution.

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