Problem Discovery

What is a "Problem" in Discovery?

A problem is a gap between a user's current state and their desired state — something that causes friction, wastes time/money, or prevents a goal from being reached. Discovery starts by deeply understanding this gap before jumping to solutions.

Surface Problems vs. Root Problems

Teams often solve symptoms instead of root causes. Use techniques like the 5 Whys to dig past the first complaint:

"Users abandon checkout" → Why? → "Shipping cost surprises them" → Why? → "Shipping cost isn't shown until the last step" — now you have an actionable root problem.

Signals That Reveal Problems

• Support tickets and complaints.
• Drop-off points in analytics funnels.
• Workarounds and manual hacks users have built.
• Direct quotes from interviews expressing frustration.

The JTBD Framework

Jobs to Be Done says people don't buy products — they "hire" them to make progress on a specific job in their life. The classic example: people don't want a drill, they want a hole in the wall (and ultimately, a shelf hung, or a feeling of accomplishment).

Functional, Emotional, and Social Jobs

• Functional — the practical task ("track my expenses").
• Emotional — how they want to feel ("feel in control of my money").
• Social — how they want to be perceived ("seen as financially responsible").

JTBD Statement Format

"When [situation], I want to [motivation], so I can [expected outcome]."

Why JTBD Helps Discovery

It shifts focus from your product's features to the user's underlying goal — which is far more stable over time than any specific solution, and opens the door to competing solutions outside your category (e.g. a JTBD of "look good for an event" could be solved by a haircut, not just a clothing app).

What is a Problem Statement?

A clear, concise articulation of the problem you intend to solve, grounded in evidence — used to align the team before solutioning begins.

A Useful Template

"[User segment] struggles with [problem], when [context], which causes [impact]. We believe this matters because [evidence]."

Qualities of a Strong Problem Statement

• Specific — names a segment and a concrete situation, not "users are confused."
• Evidence-backed — cites interview quotes, data, or support volume.
• Solution-free — describes the problem, not your favorite fix, to avoid anchoring the team early.
• Sized appropriately — not so broad it's unsolvable, not so narrow it's trivial.

Common Mistakes

• Writing the solution disguised as a problem ("Users need a dashboard" is a solution, not a problem).
• Skipping evidence and relying on stakeholder opinion alone.

From Problems to Opportunities

An opportunity is a problem, need, or desire that — if addressed — would create meaningful value for users and the business. Not every problem is worth pursuing; opportunity identification is about finding the highest-leverage ones.

Sources of Opportunities

• Patterns across multiple interviews (same pain point, different words).
• Quantitative signals — high-volume drop-off points, repeated support themes.
• Market/competitive gaps.
• Direct customer requests, reframed as underlying needs.

Organizing Opportunities

Continuous discovery teams often capture opportunities in an opportunity space (visualized via an Opportunity Solution Tree, covered in Module 7) mapped to a desired outcome, so leadership and the team can see how today's work ladders up to business goals.

Evaluating Before Committing

Ask: how many users have this problem? How painful is it? How does it align with our strategy? These questions feed directly into prioritization (Module 7).