Chapter 4: Problem Framing & Opportunity Mapping

The most expensive mistake a product team can make is not building something poorly -- it is building the wrong thing well. Problem framing is the discipline of making sure you are solving the right problem before you invest in solving the problem right. This chapter covers multiple frameworks for mapping and structuring the opportunity space, from continuous discovery tools to time-boxed sprint techniques.

---

Why Problem Framing Matters More Than Solution Quality

Most product failures are not engineering failures. They are framing failures. The team built exactly what was specified, but what was specified did not address a real need in a meaningful way.

Teresa Torres frames this as the difference between well-structured problems and ill-structured (or "wicked") problems ^cdh. Well-structured problems have a clear definition, known constraints, and a deterministic path to a solution -- think solving an equation. Product problems are almost never well-structured. They are ill-structured: the problem definition is fuzzy, constraints shift, and there are many possible solutions with no objectively "correct" one. The danger is that teams treat ill-structured problems as if they were well-structured, jumping straight to a solution without adequately exploring the problem space.

Erika Hall puts it more bluntly: "The most common and most expensive usability problem is building the wrong thing" ^just-enough. She advocates starting every research effort with a clear problem statement that defines what "done" looks like -- not a feature description, but an outcome the team wants to achieve.

The implication is practical: spend more time framing and less time building, especially early on. Every hour invested in problem framing saves many hours of wasted development later.

---

The Opportunity Solution Tree

The Opportunity Solution Tree (OST) is the central visual artifact of continuous discovery ^cdh. It provides a structured way to connect business outcomes to customer opportunities to potential solutions to assumption tests.

See Opportunity Solution Tree

Structure

The OST has four levels:

1. Outcome (top): The measurable business or product outcome the team is driving toward. Example: "Increase weekly active users by 15%."
2. Opportunities (second level): Customer needs, pain points, and desires that, if addressed, would drive the outcome. These come from customer interviews and experience mapping.
3. Solutions (third level): Specific ideas for addressing an opportunity. Multiple solutions should hang beneath each opportunity.
4. Assumption tests (bottom): Small experiments designed to test the riskiest assumptions behind each solution.

Why It Works

The tree structure enforces several healthy habits. First, it prevents teams from jumping directly from an outcome to a solution without understanding the customer opportunity in between. Second, it encourages exploring multiple opportunities and multiple solutions rather than fixating on the first idea. Third, it makes the team's reasoning explicit and inspectable -- stakeholders can see why a particular solution is being pursued and what assumptions underpin it ^cdh.

Torres emphasizes that the OST is a living document. It evolves week over week as the team conducts interviews, discovers new opportunities, and runs assumption tests. It is not a one-time planning artifact.

Building Out Your OST

Start with the outcome your team has been assigned or has chosen. Then populate the opportunity space through experience mapping and customer interviews (covered below). As you learn, add opportunities to the tree, organize them into parent-child hierarchies, and begin ideating solutions for the most promising opportunities.

---

Experience Mapping: Making Your Assumptions Visible

Before you can discover what you do not know, you need to externalize what you think you know. Experience mapping is a technique for doing exactly that ^cdh.

See Experience Mapping

The Process

1. Set scope. Define the experience you are mapping. For a narrow optimization outcome ("increase checkout completion"), scope tightly. For an open-ended outcome ("help people find entertainment"), scope broadly.
2. Individual drafts. Each member of the product trio independently sketches their understanding of the customer's current experience. Use boxes, arrows, stick figures -- visual fidelity does not matter. What matters is making your mental model external and inspectable.
3. Merge into a team map. Compare the individual drafts. Where do they agree? Where do they diverge? The divergences are goldmines -- they expose where the team lacks shared understanding and where interviews should probe.
4. Add emotional context. Annotate the map with emotional highs and lows. Where is the customer frustrated? Delighted? Confused? These emotional signals point toward opportunities.

Torres stresses that experience maps are visual, not verbal ^cdh. Drawing forces a different kind of thinking than writing bullet points. It reveals gaps, sequencing assumptions, and causal beliefs that text alone would obscure.

The experience map serves as the foundation for populating the opportunity level of your OST. As you interview customers, you update and refine the map, and each refinement surfaces new opportunities.

---

Customer Journey Mapping: The Full Life Cycle Use Case

While Torres's experience map focuses on the team's evolving understanding, Bill Aulet's Full Life Cycle Use Case (FLCUC) takes a more structured, end-to-end view of how a customer interacts with your product from initial awareness through long-term advocacy ^de.

See Full Life Cycle Use Case

The 10 Stages

Aulet identifies stages that span the entire customer relationship:

1. Need recognition -- The customer becomes aware they have a problem.
2. Finding your offering -- How do they discover your product exists?
3. Analyzing your offering -- How do they evaluate whether it is right for them?
4. Acquiring your product -- The purchase or sign-up process.
5. Installing / onboarding -- Getting set up and ready to use.
6. Learning to use -- First-use experience and ramp-up.
7. Using regularly -- The core ongoing experience.
8. Getting value -- The moment the customer achieves the outcome they sought.
9. Getting support -- What happens when something goes wrong.
10. Recommending / advocating -- The customer tells others.

When to Use It

The FLCUC is particularly valuable when you are designing a new product or entering a new market, because it forces you to think beyond the core usage experience. Many products fail not because the core is weak but because onboarding is confusing, support is absent, or the path from awareness to purchase is unclear. The FLCUC ensures you map all ten stages and identify which ones represent the biggest risks or opportunities ^de.

Aulet emphasizes that this map should be visual -- diagrams, flowcharts, or sequence drawings rather than paragraphs of text. It should be derived directly from conversations with your persona (see Chapter 5), not from the team's assumptions alone.

---

Sprint Mapping: A Simple Customer Map for Time-Boxed Work

Jake Knapp's sprint map is deliberately simpler than a full experience map or journey map ^sprint. It is designed to be drawn on a whiteboard on Monday morning and used as a navigational tool for the rest of the sprint week.

See Sprint Map

Structure

A sprint map has three elements:

1. Actors on the left: the key people involved (customer, sales rep, support agent, etc.).
2. Steps flowing left to right: 5 to 15 steps that represent the customer's journey through the problem space. Keep it simple -- if you have more than 15 steps, you are overcomplicating it.
3. Endpoint on the right: the moment of success. What does "winning" look like for the customer?

The map is drawn with input from the full sprint team and refined through "Ask the Experts" sessions on Monday afternoon, where team members and subject-matter experts share what they know about how customers currently experience the problem ^sprint.

The Critical Difference from Experience Maps

Torres's experience map is designed to evolve continuously over weeks and months. Knapp's sprint map is designed to be good enough by Monday afternoon and then serve as a fixed backdrop for Tuesday's sketching, Wednesday's decision-making, and Thursday's prototyping. It trades depth for speed and shared alignment.

---

How Might We Notes: Converting Problems into Opportunities

One of the most practical techniques for bridging observation and action is the "How Might We" (HMW) note ^sprint.

See How Might We Notes

The Technique

During Monday's expert interviews and problem discussions, each team member captures problems, obstacles, and insights as questions beginning with "How might we...?" For example:

• Hearing "Customers get frustrated waiting for delivery updates" becomes: "How might we keep customers informed during delivery?"
• Hearing "New users don't understand the pricing page" becomes: "How might we make pricing immediately clear?"

Each HMW goes on a separate sticky note. At the end of the day, the team clusters the notes, votes on the most compelling ones, and places the winning HMW notes on the sprint map at the relevant step ^sprint.

Why It Works

HMW notes perform a subtle but important cognitive shift: they reframe problems as opportunities without jumping to solutions. The phrasing "How might we..." is broad enough to invite multiple solutions but specific enough to be actionable. It prevents the team from getting stuck in problem-description mode and moves them toward creative problem-solving.

Torres's OST operates on a similar principle: opportunities are framed as customer needs, pain points, or desires -- essentially the answers to "How might we..." questions, captured in a more structured and persistent format ^cdh.

---

Structuring the Opportunity Space

Having a long list of opportunities or HMW notes is a start, but it is not enough. The opportunity space needs structure to be useful for decision-making.

Parent-Child Hierarchies

Torres advocates organizing opportunities into a hierarchy where broad opportunities contain more specific child opportunities ^cdh. For example:

• Parent: "Customers struggle to find relevant content"
  • Child: "Search results don't match what they meant"
  • Child: "Browse categories are too broad"
  • Child: "Recommendations feel irrelevant"

This hierarchy matters because it gives teams the ability to zoom in and out. You might start by exploring the parent opportunity broadly, then drill down to a specific child opportunity that is both impactful and addressable.

Distinct Moments in Time

A key principle for structuring opportunities: each opportunity at the same level should represent a distinct moment in the customer's experience ^cdh. If two opportunities overlap in time or context, one is probably a child of the other. This keeps the tree clean and prevents double-counting of the same underlying issue.

Leaf-Node Opportunities

The most actionable opportunities are at the leaves of the tree -- the most specific, concrete needs. Torres calls these "leaf-node opportunities" and argues that teams should target these for solution ideation rather than the broad parent opportunities ^cdh. A solution aimed at "Customers struggle to find relevant content" is too vague to test. A solution aimed at "Search results don't match what they meant" is concrete enough to prototype and validate.

---

Problem Statements: Defining "Done"

Erika Hall advocates writing explicit problem statements before beginning any research or design work ^just-enough. A good problem statement has three properties:

1. It uses outcome-oriented verbs -- "increase," "reduce," "enable" -- rather than output-oriented verbs like "build," "design," or "create." The statement describes the change you want to see in the world, not the artifact you plan to produce.
2. It defines what "done" looks like -- How will you know the problem is solved? What measurable change will you observe?
3. It is bounded -- It specifies who you are solving for, what context they are in, and what constraints apply.

Example of a weak problem statement: "Design a new onboarding flow." Example of a strong problem statement: "Reduce the time it takes new users to complete their first project from 45 minutes to under 10 minutes."

The strong version tells you who (new users), what outcome (complete first project), what metric (time), and what target (under 10 minutes). It is testable and it defines success independently of any particular solution.

---

Three Perspectives for Problem Refinement

Lombardo and Bilgen propose examining every problem through three lenses before committing to a direction ^prr:

1. Usage perspective -- How do real people currently experience this problem? What workarounds have they invented? What is the actual behavior (not the intended behavior)?
2. Business perspective -- Why does this problem matter to the business? What is the cost of not solving it? What is the revenue or retention upside of solving it?
3. Expertise perspective -- What do domain experts, data analysts, or technical specialists know about this problem that the team might not? Are there known patterns, constraints, or prior art?

These three perspectives serve as a checklist against one-dimensional framing. A problem defined only through the usage lens might not be commercially viable. A problem defined only through the business lens might not reflect real customer pain. And a problem defined without the expertise lens might lead to solutions that ignore known constraints or reinvent existing approaches ^prr.

---

Narrowing from Broad Problem to Specific Target

All of the frameworks above share a common pattern: start broad, then narrow ruthlessly. The question is how to narrow.

Monday Target Selection (Sprint)

In a sprint, the team spends Monday morning mapping the broad problem and Monday afternoon hearing from experts. At the end of Monday, the Decider picks one specific target on the map -- a specific actor at a specific step -- that the sprint will focus on for the rest of the week ^sprint. This is a deliberate, time-boxed narrowing decision. The team accepts that they cannot address the entire map in one week and commits to the highest-leverage slice.

Knapp recommends framing the target selection around the sprint questions generated earlier in the day: "Which part of the map, if we got it right, would have the biggest impact on our long-term goal?" ^sprint.

Leaf-Node Opportunities (Continuous Discovery)

In continuous discovery, narrowing is more gradual. The team explores the opportunity space over multiple weeks of interviews, adds structure through the OST, and eventually selects a target opportunity -- typically a leaf-node opportunity that is both important to customers and aligned with the business outcome ^cdh. Torres recommends evaluating opportunities using "compare and contrast" rather than scoring and ranking, because the factors that matter vary by opportunity and resist standardization.

---

Synthesis: Continuous Discovery vs. Time-Boxed Sprints

Torres's OST and Knapp's sprint map are not competing frameworks -- they are complementary tools designed for different rhythms of work.

A team practicing continuous discovery might use the OST as their persistent map of the opportunity space and then run a sprint (or a lightweight version of one) when they need to rapidly prototype and test a specific solution for a leaf-node opportunity. The sprint map becomes a zoomed-in view of one branch of the OST.

Similarly, Aulet's Full Life Cycle Use Case complements both by ensuring you do not neglect the stages before and after the core product experience ^de. The FLCUC is most valuable when designing a new product end-to-end, while the OST and sprint map are most valuable when iterating on an existing product or exploring a specific problem area.

Hall's problem statement discipline ^just-enough and Lombardo and Bilgen's three-perspective refinement ^prr apply universally -- regardless of which mapping framework you use, you should be able to articulate the problem in outcome-oriented terms and have examined it from the usage, business, and expertise perspectives before committing resources.

---

Key Takeaways

1. Frame before you solve. Invest in understanding the problem space before generating solutions. The cost of solving the wrong problem always exceeds the cost of framing the right one.
2. Make your thinking visual. Experience maps, sprint maps, journey maps, and opportunity trees all force externalization of assumptions. What is visible can be inspected and improved; what stays in your head cannot.
3. Structure the opportunity space. A flat list of customer needs is hard to prioritize. Organize opportunities into parent-child hierarchies with distinct moments, and target the leaf nodes for solution work.
4. Define success before starting. Write problem statements with outcome-oriented verbs and measurable targets. If you cannot define what "done" looks like, you are not ready to start building.
5. Match the tool to the rhythm. Use the OST for ongoing discovery, sprint maps for time-boxed bursts, and the Full Life Cycle Use Case for end-to-end product design. They complement each other.