Problem Framing and Opportunity Definition

Introduction

Product management begins before a feature is specified. It begins when a team decides what deserves attention, for whom, and why. In practice, many weak products are not caused by poor engineering or inadequate execution; they arise because the team solved an inaccurately framed problem. A request such as “add a dashboard,” “use artificial intelligence,” or “reduce support tickets” may describe a proposed solution, a symptom, or an organisational target rather than the underlying customer need.

Problem framing is the disciplined process of interpreting evidence, identifying the human and organisational need behind observed behaviour, and expressing that need in a form that enables exploration. Opportunity definition then connects the problem to a desirable future state and to the organisation’s strategic capabilities. Together, these activities help product teams avoid premature solution commitment and focus scarce resources on outcomes that create customer and business value.

This chapter develops practical methods for constructing point-of-view statements, problem statements, How-Might-We questions, root-cause analyses, and opportunity trees. It also explains how to reframe problems and prioritise needs using customer value, strategic relevance, evidence quality, and feasibility.

Learning Objectives

By the end of this chapter, the reader should be able to:

• distinguish symptoms, problems, needs, opportunities, and solutions;
• construct evidence-based point-of-view and problem statements;
• formulate productive How-Might-We questions;
• analyse root causes without confusing correlation with causation;
• build and interpret opportunity trees;
• reframe a problem from multiple stakeholder perspectives;
• prioritise opportunities by customer value and strategic relevance; and
• recognise ethical, organisational, and methodological limitations in problem framing.

1. From Observations to Product Opportunities

A product team normally encounters information in an unstructured form: interview quotations, complaints, usage data, sales requests, operational incidents, market research, and strategic objectives. These observations are not yet opportunities. They must be interpreted carefully.

An observation is something seen, heard, measured, or recorded. For example, “38% of new users abandon onboarding after the identity-verification step” is an observation. A symptom is an undesirable visible consequence, such as “new users do not complete registration.” A problem is the unmet need or obstacle experienced by a specific person in a particular context. An opportunity is a plausible area in which improved value could be created. A solution is a proposed intervention.

The distinctions matter because teams often jump directly from observation to solution:

Observation: Users abandon identity verification.

Proposed solution: Remove identity verification.

This conclusion may be unsafe. Verification may be required for regulatory compliance, fraud prevention, or trust. The deeper problem may be that users do not understand why verification is required, cannot provide the requested document, or experience a slow and unreliable process. The opportunity might therefore concern explanation, accessibility, processing speed, or alternative verification—not simply removal.

A useful chain is:

Evidence → interpretation → problem frame → opportunity → hypotheses → solution experiments

Each transition introduces assumptions. Professional product management makes those assumptions visible and tests them rather than presenting them as facts.

Important Terminology

2. Point-of-View Statements

A point-of-view (POV) statement gives a human-centred interpretation of research. It is more specific than a broad mission and less solution-bound than a feature request. A common structure is:

[User or stakeholder] needs [meaningful need] because [insight or underlying reason].

For example:

First-time small-business sellers need to understand whether an order is genuinely profitable because revenue figures alone do not reveal packaging, delivery, and platform costs.

This statement identifies a population, a need, and an insight. It does not prescribe a dashboard, calculator, or report. Consequently, several solutions remain possible.

A strong POV statement has five qualities:

1. Specificity: It identifies a recognisable user in a real context.
2. Human relevance: It describes a need or desired outcome, not an internal process.
3. Evidence grounding: The insight follows from research or credible data.
4. Solution neutrality: It does not dictate a particular product feature.
5. Generative power: It opens useful directions for ideation.

A weak statement might say, “Users need a simpler app.” “Simpler” is vague and may conceal different needs, such as faster completion, lower cognitive load, clearer language, or fewer decisions. A better formulation is:

Occasional tax filers need confidence that they have completed the filing correctly because unfamiliar terminology and unclear error messages make them fear costly mistakes.

The POV is not a final truth. It is an interpretive artefact that should be revised when new evidence challenges it.

3. Writing Effective Problem Statements

A problem statement should define the gap between the current condition and a desired condition without embedding a solution. One useful format is:

[User] is unable to [desired outcome] in [context] because [important obstacle], resulting in [consequence].

Example:

Remote patients are unable to prepare confidently for virtual consultations because they do not know which measurements or documents the clinician will need, resulting in incomplete appointments and repeated bookings.

Another format uses a “How might we” precursor:

We need to improve the ability of remote patients to prepare for virtual consultations, especially where uncertainty causes incomplete appointments.

Problem statement tests

Before accepting a statement, the team should ask:

• Who experiences the problem directly?
• What evidence demonstrates that it matters?
• Is the statement about a need rather than a proposed solution?
• Does it describe a meaningful consequence?
• Is its scope narrow enough to investigate but broad enough to permit alternatives?
• Does it distinguish the primary user from purchasers, administrators, and affected third parties?
• Could a reasonable team disagree about the best solution?

Problem statements can operate at different levels. A strategic problem may be “independent retailers struggle to retain customers.” A behavioural problem may be “customers do not return within 30 days.” An interaction problem may be “customers cannot easily find replenishment items.” These are related but require different research and interventions. A team should avoid mixing levels without stating the relationship among them.

4. How-Might-We Questions

A How-Might-We (HMW) question converts a problem frame into an invitation to explore. The phrase expresses possibility rather than certainty:

How might we [enable a user] to [achieve a valuable outcome] despite [relevant constraint]?

For the virtual-consultation example:

How might we help remote patients know what to prepare before a virtual consultation without increasing preparation anxiety or clinician workload?

HMW questions are useful because they create a boundary for ideation. If too broad, they generate unmanageable possibilities:

How might we improve healthcare?

If too narrow, they merely restate a solution:

How might we add a preparation checklist to the booking page?

A productive HMW question is neither a slogan nor a disguised requirement. It should preserve the problem’s purpose while leaving design choices open.

Creating a set of HMW questions

One problem can produce several HMW questions by varying the design lens:

• Reduce effort: How might we reduce the work required to prepare?
• Increase confidence: How might we help users know that they are ready?
• Improve timing: How might we provide guidance before the appointment rather than at its start?
• Support alternatives: How might we help users who lack the required device or document?
• Improve system coordination: How might we share preparation information with clinicians without creating duplicate data entry?
• Address trust: How might we explain why information is requested and how it will be used?

The team can then select, combine, or sequence these questions according to evidence and strategy.

5. Root-Cause Analysis

Root-cause analysis seeks explanations beneath an observed problem. It is particularly valuable when a visible symptom has multiple contributing factors. However, “root cause” should not be interpreted as a single hidden defect in every situation. Complex product problems are often produced by interacting technical, behavioural, organisational, and environmental causes.

The five-whys technique

The five-whys method repeatedly asks why an observed condition occurred. It is a conversational inquiry rather than a fixed requirement to ask exactly five times.

Observed condition: Customers frequently contact support to reset passwords.

1. Why? They cannot complete the password-reset process.
2. Why? The reset email often arrives after the link has expired.
3. Why? Email delivery is delayed for some providers.
4. Why? The system sends messages through a congested shared service.
5. Why? Capacity and delivery performance were not included in the service-level design.

This analysis suggests several possible interventions: improve delivery infrastructure, extend token validity within security limits, provide an alternative recovery path, and monitor delivery latency. The first statement—“customers forget passwords”—would have led to a different and possibly ineffective solution.

The technique has limitations. It can encourage a linear explanation where causes are systemic and interconnected. It can also reflect the facilitator’s assumptions. Teams should validate each causal claim using logs, interviews, experiments, process evidence, or domain expertise.

Fishbone analysis

A fishbone, or cause-and-effect, analysis groups possible causes under categories such as people, process, technology, policy, environment, and measurement. For example, low delivery reliability may involve poor network coverage, unclear status messages, defective hardware, staff procedures, or an inappropriate success metric. The value of the tool is not the diagram itself but the disciplined consideration of multiple causal domains.

Causal caution

A correlation does not establish causation. If users who watch fewer onboarding videos have lower retention, the videos may not be the cause. These users may have weaker intent, less time, or different acquisition channels. Product teams should use language such as “may contribute to” until causal evidence exists. A controlled experiment, natural experiment, longitudinal observation, or credible quasi-experimental method may be required to test causality.

6. Opportunity Trees

An opportunity tree links a desired outcome to opportunities and possible solutions. It prevents the team from treating a feature list as a strategy. A typical structure is:

Outcome → Opportunities → Solution ideas → Experiments

Suppose a product outcome is:

Increase the proportion of first-time sellers who achieve a profitable first sale.

Possible opportunities include:

• help sellers understand total costs;
• help sellers select viable products;
• reduce uncertainty about fulfilment;
• provide timely feedback after listing; and
• help sellers recover from an unprofitable first attempt.

Under “understand total costs,” solution ideas might include a margin estimator, contextual cost explanations, or an automated profitability warning. These are alternatives, not commitments.

An opportunity tree should be evidence-led. Each opportunity can be annotated with:

• affected segment;
• frequency and severity;
• evidence source;
• confidence level;
• strategic relevance;
• dependencies and constraints; and
• possible outcome measures.

The tree is not necessarily a hierarchy of causes. It is a decision structure showing how different opportunities could contribute to an outcome. A team should avoid treating every branch as equally important.

Outcome versus output

An outcome describes a change in customer or business condition: fewer failed payments, faster completion, greater confidence, or higher retention. An output is a product artefact: a notification, workflow, algorithm, or screen. Opportunity trees begin with outcomes because outputs are means rather than ends.

7. Reframing Problems

Reframing means deliberately examining a problem from alternative perspectives and at alternative levels of abstraction. It is not cosmetic rewriting. A new frame may reveal excluded users, hidden constraints, or a more valuable outcome.

Consider the frame:

Commuters need more parking spaces near the city centre.

Possible reframes include:

• commuters need predictable access to the city centre;
• commuters need to transport people or goods conveniently;
• the city needs to reduce the demand for private-car parking;
• employers need to coordinate travel more efficiently; and
• visitors need confidence that they can reach a destination on time.

These frames lead to different opportunities: real-time transit coordination, shared mobility, delivery lockers, flexible work arrangements, or better parking information. The original frame assumed that additional parking was the correct response.

Useful reframing lenses include:

1. User lens: Who is affected but currently invisible?
2. Outcome lens: What progress is the person actually trying to make?
3. Time lens: Is the problem about preparation, the moment of use, or recovery?
4. System lens: Which partners, policies, or incentives shape the experience?
5. Equity lens: Who bears greater risk or effort?
6. Prevention lens: Can the problem be avoided rather than repaired?
7. Opposite lens: What would make the problem significantly worse?

Reframing must remain accountable to evidence. A novel frame is not automatically a better frame.

8. Prioritising Opportunities

A product team cannot pursue every plausible need. Prioritisation should combine customer value with strategic relevance while acknowledging uncertainty and feasibility.

Customer value

Customer value may include improved effectiveness, reduced time, lower cost, increased confidence, reduced risk, accessibility, or emotional reassurance. Value is contextual: a small time saving may be highly valuable during an emergency but negligible in a leisurely activity.

Strategic relevance

Strategic relevance concerns the organisation’s direction and ability to create a defensible advantage. An opportunity may support a target market, strengthen a core capability, reduce regulatory exposure, improve retention, or create learning that enables future products. Strategic relevance should not be used to justify ignoring serious customer harm.

A transparent scoring model

A simple prioritisation model can structure discussion:

Here, V is estimated customer value, S is strategic relevance, E is evidence confidence, and C is relative cost or effort. Scores may be assigned on a common ordinal scale, for example 1 to 5. The formula is not a law of decision-making; it is a heuristic. It assumes that the dimensions can be represented comparably and that multiplying them usefully penalises low confidence or low relevance. It should not replace judgement, especially where legal, safety, or ethical issues create non-negotiable requirements.

Illustrative example:

The first opportunity ranks highest because it combines strong customer value, strategic relevance, evidence, and manageable effort. The analytics opportunity may still deserve discovery work because its low evidence confidence makes it a learning priority rather than an immediate delivery priority.

The arithmetic is illustrative, not predictive. Scores should be accompanied by assumptions, ranges, and qualitative explanation. Teams should also examine opportunity cost: selecting one opportunity means delaying another.

Prioritisation criteria

A mature review considers:

• magnitude and frequency of the need;
• affected users and vulnerable groups;
• willingness or ability to adopt a response;
• strategic fit and differentiation;
• evidence confidence;
• implementation complexity and dependencies;
• risk, reversibility, and regulatory exposure; and
• learning potential.

A low-cost opportunity with weak value should not automatically outrank a high-value opportunity requiring investment. Nor should a strategically fashionable opportunity outrank a serious safety or accessibility issue.

9. Applied Case: Improving a Digital Banking Onboarding Journey

Background

The following is an illustrative case. A digital bank observes that many applicants begin account opening but fail to become active customers. Marketing proposes a shorter form and a promotional reward.

Problem

Analytics show that abandonment is concentrated around identity verification. Interviews reveal three user groups: applicants who cannot provide an acceptable document, applicants who do not understand why information is requested, and applicants who receive a technical error while using mobile cameras. The initial solution request—“remove verification steps”—would conflict with anti-money-laundering obligations.

Analysis

The team constructs the following POV:

Applicants opening their first digital bank account need to feel confident that verification is understandable and achievable because uncertainty about requirements, privacy, and technical failure makes them abandon the process.

The problem statement becomes:

Prospective customers are unable to complete identity verification confidently and reliably on their first attempt because requirements and recovery paths are unclear, resulting in abandonment and repeated support contacts.

Root-cause analysis identifies several contributing causes:

• document requirements differ by applicant type but are not explained early;
• the camera capture process fails under poor lighting;
• error messages describe system states rather than user actions;
• users cannot easily resume after interruption; and
• privacy explanations are written in legal language.

The opportunity tree begins with the outcome “increase compliant, completed account openings” and branches into explanation, capture reliability, recovery, trust, and support. Possible experiments include a pre-verification requirements preview, improved capture guidance, resumable verification, plain-language privacy explanations, and a controlled alternative support route.

Approach and solution

The team prioritises a requirements preview and resumable verification because evidence confidence and customer value are high, while regulatory risk is low. It does not remove verification. Instead, it tests whether clearer expectations and recovery reduce abandonment. The team defines success in outcome terms: completed compliant applications, first-attempt completion rate, support contacts per application, and the rate of false or fraudulent submissions.

Outcome

In an initial experiment, the team observes improved completion and fewer “what document do I need?” contacts. It also discovers that camera failure remains significant for older devices, generating a second opportunity around technical accessibility. The team therefore treats the first intervention as a learning step rather than a final solution.

Learning points

1. A business request may encode a valid concern but an unsafe solution.
2. Compliance is a design constraint, not an excuse to stop improving the experience.
3. Multiple root causes can coexist.
4. Opportunity trees preserve alternatives and connect ideas to outcomes.
5. Measurement should include customer, business, risk, and equity effects.

10. Challenges, Ethics, and Governance

Problem framing involves power. The people who define the problem influence which users are heard, which harms are counted, and which interventions appear reasonable. Teams should therefore document who supplied the evidence and who may be missing from it.

Common risks include:

• Proxy framing: using organisational metrics, such as call reduction, as a substitute for customer welfare;
• exclusion: ignoring users with disabilities, limited connectivity, low literacy, or minority language needs;
• surveillance: collecting excessive behavioural data to diagnose a problem;
• automation bias: assuming an AI system’s prediction identifies a user’s true need;
• dark patterns: framing a business objective as a customer problem to justify manipulation; and
• privacy harm: linking research evidence to identifiable individuals without appropriate consent and governance.

AI tools can support clustering of interview notes, summarisation, and generation of alternative HMW questions. However, AI-generated interpretations may reproduce stereotypes, omit context, or present uncertain inferences as facts. Sensitive research data should be handled according to privacy, security, consent, retention, and access policies. Human researchers remain responsible for validating interpretations and preserving participants’ meaning.

A responsible process records evidence, assumptions, excluded alternatives, affected stakeholders, and unresolved uncertainty. High-impact domains such as finance, healthcare, employment, and education require additional review for fairness, explainability, safety, and regulatory compliance.

11. Best Practices for Product Teams

Effective problem framing is iterative. The following practices improve quality:

1. Separate facts, interpretations, and assumptions in research synthesis.
2. Use direct customer language before translating it into abstractions.
3. State the affected segment and context explicitly.
4. Avoid naming a feature in the problem statement.
5. Generate several frames before selecting one.
6. Trace each major opportunity to evidence.
7. Use outcome measures rather than feature completion as the primary test.
8. Include feasibility, legal, ethical, and accessibility constraints early.
9. Represent uncertainty rather than hiding it in precise-looking scores.
10. Revisit the frame when experiments produce surprising results.

The objective is not to produce elegant wording. It is to improve the quality of decisions made under uncertainty.

Chapter Summary

Problem framing translates unstructured evidence into a clear, testable account of an unmet need. A point-of-view statement identifies a user, need, and insight; a problem statement describes the obstacle and its consequence without prescribing a solution; and a How-Might-We question opens a bounded space for exploration. Root-cause methods such as five whys and fishbone analysis help teams investigate underlying contributors, but causal claims require validation. Opportunity trees connect desired outcomes to opportunities, solution ideas, and experiments. Reframing exposes alternative users, outcomes, system conditions, and equity considerations. Prioritisation should balance customer value, strategic relevance, evidence confidence, effort, risk, and learning potential. Ethical and governance practices are essential because problem definitions determine whose needs receive attention and how data and technology are used.

Key Terms

Point-of-view statement: An evidence-informed statement linking a user, need, and insight.

Problem statement: A concise description of an important unmet need or obstacle.

Opportunity: A possibility for creating customer and organisational value.

Symptom: A visible consequence of an underlying condition.

User need: A condition or outcome necessary for a person to make progress.

Desired outcome: The improvement a user or organisation seeks.

How-Might-We question: A generative question that frames a problem for exploration.

Root cause: A contributing condition beneath an observed symptom.

Five whys: An iterative questioning technique for exploring causal explanations.

Fishbone analysis: A structured method for grouping possible causes.

Opportunity tree: A hierarchy linking an outcome to opportunities, ideas, and experiments.

Reframing: Examining a problem through alternative perspectives or levels of abstraction.

Evidence confidence: The degree to which available evidence supports an interpretation.

Customer value: The benefit a user receives relative to the costs, risks, or effort involved.

Strategic relevance: The degree to which an opportunity supports organisational direction and advantage.

Outcome: A measurable change in user or business condition.

Output: A product artefact or activity produced by a team.

Constraint: A condition that limits possible responses.

Hypothesis: A testable proposition about behaviour, value, or causation.

Dark pattern: A design practice that manipulates users against their interests.

Review Questions

Short Answer Questions

1. Distinguish an observation, a symptom, a problem, an opportunity, and a solution.
2. What three elements are normally included in a point-of-view statement?
3. Why should a How-Might-We question avoid embedding a specific feature?
4. State one limitation of the five-whys technique.
5. Explain the difference between an outcome and an output.

Long Answer Questions

1. Explain how evidence should be transformed into a problem statement and then into a set of How-Might-We questions.
2. Discuss the construction and use of an opportunity tree, including the relationship between outcomes, opportunities, solutions, and experiments.
3. Compare customer value and strategic relevance as criteria for prioritising product opportunities.
4. Explain how reframing can expose hidden stakeholders, constraints, or alternative outcomes. Use an example.
5. Evaluate the ethical and governance risks involved in problem framing using customer data and artificial intelligence.

Analytical / Application Questions

1. A food-delivery service observes that customers frequently contact support after placing orders. Construct a POV statement, a problem statement, three HMW questions, and a preliminary root-cause structure.
2. Use the illustrative priority formula Priority\ score = (V × S × E) ÷ C to compare two opportunities with values (V, S, E, C) of (4, 5, 3, 2) and (5, 3, 4, 4). Explain why the numerical ranking should not be treated as an automatic decision.
3. A university portal has low completion rates for financial-aid applications. Reframe the problem from the perspectives of students, administrators, policymakers, and students with disabilities. Identify one opportunity for each perspective and explain which evidence would be needed before prioritisation.

Multiple Choice Questions with Answers

Question 1

Which statement best represents a point-of-view statement?

A. Add a progress bar to the registration form.

B. Users need a simpler app.

C. First-time sellers need to understand total costs because revenue figures do not reveal whether an order is profitable.

D. Increase monthly active users by 20 percent.

Correct Answer: C. First-time sellers need to understand total costs because revenue figures do not reveal whether an order is profitable.

Question 2

What is the primary purpose of a How-Might-We question?

A. To specify the final technical design

B. To invite exploration within a meaningful problem boundary

C. To prove the root cause of a problem

D. To replace user research

Correct Answer: B. To invite exploration within a meaningful problem boundary

Question 3

Which item is an outcome rather than an output?

A. A new notification screen

B. A redesigned database table

C. A completed onboarding workflow

D. A higher proportion of users completing onboarding

Correct Answer: D. A higher proportion of users completing onboarding

Question 4

What is a key limitation of the five-whys technique?

A. It cannot be used with qualitative evidence

B. It always requires exactly five questions

C. It can oversimplify complex, interacting causes

D. It identifies solutions without examining causes

Correct Answer: C. It can oversimplify complex, interacting causes

Question 5

In an opportunity tree, what normally appears at the highest level?

A. A desired product or business outcome

B. A detailed user-interface component

C. A completed experiment

D. A technical implementation task

Correct Answer: A. A desired product or business outcome

Question 6

Which problem statement is most solution-neutral?

A. Users need a mobile checklist.

B. Users need an AI assistant in the booking flow.

C. Remote patients struggle to prepare for consultations because requirements are unclear.

D. The team should redesign the appointment page.

Correct Answer: C. Remote patients struggle to prepare for consultations because requirements are unclear.

Question 7

Using the chapter’s illustrative formula, what is the priority score for V = 4, S = 5, E = 3, and C = 2?

A. 10

B. 20

C. 30

D. 60

Correct Answer: C. 30

Question 8

Which factor is most directly associated with strategic relevance?

A. Whether an opportunity supports organisational direction and capabilities

B. Whether a feature uses the newest interface style

C. Whether the product team personally prefers the idea

D. Whether the opportunity has the shortest name

Correct Answer: A. Whether an opportunity supports organisational direction and capabilities

Question 9

Why is removing identity verification not necessarily an appropriate response to onboarding abandonment in digital banking?

A. Verification may be required for legal and risk-management reasons

B. Users never abandon verification processes

C. Identity verification has no relationship to banking

D. Shorter onboarding always reduces trust

Correct Answer: A. Verification may be required for legal and risk-management reasons

Question 10

Which practice best supports responsible problem framing?

A. Treating AI-generated summaries as validated evidence

B. Recording evidence, assumptions, excluded users, and unresolved uncertainty

C. Using organisational metrics as the sole definition of customer value

D. Selecting the opportunity with the highest score without qualitative review

Correct Answer: B. Recording evidence, assumptions, excluded users, and unresolved uncertainty