Problem Framing and Opportunity Identification

Introduction

Entrepreneurial innovation rarely begins with a fully formed product idea. It begins with an observed difficulty, unmet need, inefficient process, exclusion, risk, or emerging possibility. The central challenge is to determine which problems are genuinely valuable to address and how they should be defined before resources are committed to a solution.

Problem framing is the disciplined process of interpreting research, identifying the underlying need, and expressing the challenge in a form that guides creative action without prematurely prescribing a solution. Opportunity identification is the process of recognizing situations in which a problem can be addressed in a way that creates value for users and can be sustained by an organization or venture.

Poorly framed problems produce attractive but irrelevant solutions. For example, “How can we build a mobile application for public transport?” assumes that an app is the answer. A stronger framing asks, “How might we help infrequent public-transport users feel confident navigating unfamiliar routes?” The second statement is open to multiple solutions and is grounded in a user need.

For entrepreneurs, problem framing connects design thinking with opportunity evaluation. It combines qualitative research, systems thinking, causal analysis, strategic judgment, and experimentation. The objective is not merely to generate more ideas. It is to identify a problem that matters, understand why it exists, define whom it affects, and establish evidence that solving it may create meaningful value.

Learning Objectives

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

1. Distinguish observations, insights, needs, problems, solutions, and opportunities.
2. Synthesize research into actionable insights.
3. Construct point-of-view statements and design challenges.
4. Use root-cause analysis and systems maps to examine complex problems.
5. Identify assumptions and assess problem–solution fit.
6. Prioritize problems using desirability, feasibility, viability, and ethical criteria.
7. Explain how technology, including artificial intelligence, can support—but not replace—human judgment in opportunity identification.

From Research Evidence to an Opportunity

Research produces raw evidence rather than automatic conclusions. Evidence may include interview quotations, observations, diary entries, usage data, complaints, policy documents, market statistics, or records of workarounds. The entrepreneurial task is to move carefully through several levels of interpretation.

A useful insight is more than an interesting fact. It explains a pattern and suggests a direction for action. “Users dislike delays” is a weak observation because it is obvious and does not reveal what should be changed. “Users tolerate delays when they receive credible explanations and alternatives, but abandon the service when information is late or contradictory” is a stronger insight because it identifies a mechanism and a possible design direction.

Triangulation and synthesis

Researchers should avoid treating one dramatic quotation as proof of a general problem. Triangulation compares different sources or methods. For example, interviews may indicate that customers want faster service, observations may show that they repeatedly re-enter information, and transaction data may reveal that abandonment occurs at a particular step. Together, these sources provide stronger grounds for interpretation.

A practical synthesis process is:

1. Collect and organize evidence. Separate direct evidence from interpretation.
2. Code recurring themes. Mark repeated behaviours, emotions, constraints, workarounds, and desired outcomes.
3. Cluster related evidence. Group findings around moments, actors, or causes.
4. Look for tensions. Tensions occur when stated preferences conflict with actual behaviour or when different stakeholders have incompatible goals.
5. Write insight statements. Explain what is happening, why it matters, and what it may imply.
6. Test the interpretation. Return to participants, compare cases, or seek additional evidence.

A synthesis matrix can make reasoning visible:

Defining the Problem at the Right Level

A problem can be framed too broadly, too narrowly, or as a disguised solution. “Fix healthcare” is too broad to guide action. “Add a reminder button to the clinic app” is too narrow and assumes a particular solution. “Help patients remember and prepare for appointments despite changing schedules” is more useful because it identifies a user, a need, and a context while leaving room for alternatives.

A well-framed problem usually contains five elements:

• Actor: who experiences the difficulty?
• Context: when and where does it occur?
• Unmet need: what is the person trying to accomplish?
• Barrier: what prevents successful progress?
• Significance: why does the problem matter?

The distinction between the problem space and the solution space is essential. The problem space concerns users, circumstances, causes, effects, and desired outcomes. The solution space concerns products, services, technologies, business models, and implementation choices. Moving into the solution space too early creates design fixation: the team evaluates every finding in terms of whether it supports its preferred idea.

Point-of-view statements

A point-of-view (POV) statement expresses a specific, research-grounded interpretation of a user’s need. A common structure is:

[User] needs to [need] because [insight or underlying reason].

For example:

First-year university students living away from home need a low-pressure way to build dependable social connections because they often interpret temporary isolation as evidence that they do not belong.

This statement is stronger than “Students need a social networking app.” It identifies the user, the desired outcome, and an insight about the emotional mechanism. A good POV is:

• specific enough to guide research and ideation;
• broad enough to permit several solutions;
• grounded in evidence;
• expressed in human rather than technical terms; and
• free from unsupported assumptions about what users will buy.

A POV is not a final truth. It is a provisional synthesis that should be challenged as new evidence emerges.

Design challenge statements

A design challenge translates a POV into an open invitation for exploration. The “How might we…?” format is useful when it is neither too constrained nor too vague.

Weak: “How might we build an artificial-intelligence scheduling app?”

Too broad: “How might we improve student life?”

Stronger: “How might we help students create dependable social connections during their first semester without forcing them into high-pressure networking situations?”

The phrase “How might we” signals possibility, not certainty. Teams may generate several challenge statements with different emphases—for example, prevention, recovery, access, trust, affordability, or empowerment—and then select the most strategically useful one.

Root-Cause Analysis

Visible symptoms are not always the most valuable problems to solve. Root-cause analysis examines the conditions that generate an observed outcome. It should not be understood as a search for one final cause in every situation. Social, organizational, and market problems commonly have multiple interacting causes.

The “five whys” method

The five-whys method repeatedly asks why an event occurred. It is a conversational technique rather than a rule that exactly five questions must always be asked.

Illustrative example:

• Problem: Small retailers frequently run out of a popular product.
• Why? Staff reorder only after shelves are empty.
• Why? Inventory records are updated inconsistently.
• Why? Staff consider recording stock a low-priority task during busy periods.
• Why? The process requires several manual steps and offers no immediate benefit.
• Why? The system was designed around accounting needs rather than frontline workflow.

The analysis suggests that simply sending more reorder alerts may not solve the underlying issue. A better opportunity may involve reducing recording effort, integrating point-of-sale data, or redesigning incentives and routines.

The method has limitations. Different people may produce different chains, causes may branch rather than form a line, and the final answer may reflect the analyst’s assumptions. Therefore, teams should use evidence at each step and consider alternative causal pathways.

Cause-and-effect diagrams

A cause-and-effect diagram organizes possible contributors under categories such as people, process, technology, environment, policy, and incentives. It helps teams avoid blaming users for failures produced by a system. For instance, missed medical appointments may reflect transport difficulty, confusing instructions, work obligations, reminder timing, cost, or fear—not simply “carelessness.”

Root-cause analysis should distinguish:

• Proximate causes: immediately precede the event;
• Contributing causes: increase the likelihood or severity of the event; and
• Structural causes: arise from rules, resource distribution, power relationships, or institutional design.

This distinction is particularly important for entrepreneurship addressing social or public problems. A venture may be able to influence a proximate cause while lacking authority over a structural cause. That does not make the opportunity invalid, but it changes the partnership, business model, and expected outcome.

Systems Mapping and Stakeholder Analysis

Many entrepreneurial problems are embedded in systems rather than isolated transactions. A systems map represents actors, resources, information, incentives, dependencies, and feedback relationships. It may include users, non-users, employees, suppliers, regulators, communities, funders, platforms, and natural environments.

A simple systems-mapping process is:

1. Define the focal outcome and system boundary.
2. Identify actors directly and indirectly affected.
3. Map flows of money, information, materials, authority, and risk.
4. Mark dependencies, bottlenecks, reinforcing loops, and balancing forces.
5. Identify points where a small intervention could change behaviour or outcomes.
6. Examine unintended consequences and actors who may bear costs.

For example, a food-delivery platform may connect customers, restaurants, couriers, payment providers, regulators, and neighbourhoods. Faster delivery may increase customer satisfaction but also intensify courier pressure, traffic, packaging waste, and restaurant dependency on platform fees. An opportunity assessment that considers only the customer ignores value redistribution and system-level risks.

Systems mapping also reveals the difference between a user and a customer. A student may use a learning platform, a university may purchase it, an instructor may configure it, and an employer may value its outcomes. Each stakeholder can have different measures of value and different power over adoption.

Assumptions and Evidence

Every problem frame contains assumptions. Some are explicit—for example, “commuters will pay for reliable alerts.” Others are hidden—for example, “users have smartphones,” “the organization can access the necessary data,” or “reducing waiting time is more important than preserving privacy.” Making assumptions visible prevents teams from confusing confidence with evidence.

An assumption inventory can be structured as follows:

Common assumption types include:

• Desirability: Do people experience the problem and want an alternative?
• Feasibility: Can the proposed intervention be built and operated?
• Viability: Can value creation support costs and a sustainable model?
• Adoption: Will users change behaviour and obtain access?
• Ethical legitimacy: Is the intervention fair, safe, and respectful?
• Scalability: Can the approach work beyond the initial context?

A useful prioritization principle is to test assumptions that are both highly uncertain and highly consequential. Teams should not spend weeks refining a business model before confirming that the problem is real, nor should they build a technically impressive prototype before confirming that users care.

Problem–Solution Fit

Problem–solution fit exists when a clearly defined group has a meaningful problem and the proposed intervention addresses the problem in a way users recognize as valuable. It is not the same as product–market fit. Problem–solution fit concerns whether the problem and proposed response are compelling; product–market fit additionally concerns repeatable demand, distribution, retention, economics, and scale in a market.

A fit assessment should ask:

1. Who experiences the problem most intensely?
2. In what circumstances does it arise?
3. What do people currently do instead?
4. What are the costs of the current workaround?
5. What outcome would count as improvement?
6. Who decides, pays, implements, or bears risk?
7. What evidence would change our mind?

Existing workarounds are especially informative. If users spend time, money, effort, or emotional energy solving a problem, the workaround may indicate urgency. However, the absence of a workaround does not prove that no problem exists; people may lack resources, information, or alternatives.

Evidence should be distinguished by strength. A participant saying “I would use that” is useful for exploration but is weaker than observed behaviour, a commitment to a pilot, pre-order behaviour, repeated use of a prototype, or payment. No single evidence type is universally decisive, because evidence quality depends on context and research design.

Prioritizing Opportunity Areas

Organizations usually identify more possible problems than they can pursue. Prioritization should combine strategic judgment with explicit criteria. Common criteria include:

• severity and frequency of the problem;
• number and accessibility of affected people;
• willingness and ability to pay or support adoption;
• fit with organizational capabilities and mission;
• technical and operational feasibility;
• competitive distinctiveness;
• timing and environmental change;
• positive and negative externalities; and
• ethical acceptability.

A simple weighted scoring model can support discussion, but it does not create objective truth. If criterion scores are from 1 to 5, a weighted score may be calculated as:

Here, S is the total score, wᵢ is the weight assigned to criterion i, and rᵢ is the rating from 1 to 5. The weights are dimensionless and should sum to 1. The model assumes that the criteria can reasonably be compared on a common rating scale and that the selected criteria represent the decision purpose.

Suppose a team evaluates two opportunity areas using desirability, feasibility, viability, and impact. The weights are 0.30, 0.20, 0.25, and 0.25. Opportunity A receives ratings 5, 3, 4, and 5; Opportunity B receives 4, 5, 3, and 3.

For A:

S_A = (0.30×5) + (0.20×3) + (0.25×4) + (0.25×5) = 4.35

For B:

S_B = (0.30×4) + (0.20×5) + (0.25×3) + (0.25×3) = 3.75

A ranks higher under these assumptions. The result should prompt investigation, not automatic selection. A low feasibility score might identify a design constraint that can be addressed through partnership; a high impact score might conceal risks to a vulnerable group.

Teams can complement scoring with a two-by-two matrix such as urgency versus ability to act. They should also record confidence in each rating. A high score based on weak evidence is a research priority rather than a launch decision.

An Illustrative Case: FreshRoute Cooperative

The following is a fictional illustrative case designed to demonstrate the methods in this chapter.

Background

A student entrepreneurship team notices that small independent grocers in a city frequently discard fresh produce. The team initially proposes an artificial-intelligence application that predicts demand and automatically orders stock.

Problem investigation

Interviews with grocers reveal that waste is not caused only by inaccurate demand forecasts. Owners also face uncertain supplier delivery times, limited storage, fluctuating wholesale prices, staff shortages, and pressure to keep displays full. Observations show that staff record stock irregularly because the existing system is slow during peak periods. A local food charity reports that it receives surplus food with too little notice to redistribute it.

Synthesis

The team identifies three patterns:

1. Grocers need to reduce waste without increasing stockouts.
2. Manual inventory work is avoided when it interrupts customer service.
3. Surplus has value only when another organization can receive it quickly and safely.

The initial framing—“build an AI ordering application”—is replaced by the following POV:

Independent grocers need a low-effort way to respond to uncertain fresh-produce demand because waste, stockouts, and staff time are connected by fragmented information and inflexible supply arrangements.

A design challenge follows:

How might we help independent grocers adjust fresh-produce purchasing and redirect surplus without adding operational burden?

Systems analysis

The system map includes grocers, wholesalers, staff, customers, food charities, municipal health authorities, transport providers, and households experiencing food insecurity. The team recognizes that a service that merely redirects surplus could unintentionally normalize over-ordering. It therefore includes waste prevention as a primary outcome and redistribution as a secondary safeguard.

Assumptions and experiments

The team identifies critical assumptions:

• Grocers will share sufficiently accurate sales information.
• Charities can accept short-notice deliveries while meeting food-safety requirements.
• The financial value of reduced waste exceeds the service fee.
• Staff can use the process during busy periods.
• Data sharing will not expose commercially sensitive information.

Instead of building the full platform, the team conducts a two-week concierge pilot. Staff send a simple daily inventory message; a team member consolidates likely surplus and coordinates with two charities. The pilot measures kilograms of produce discarded, stockout incidents, staff time, accepted donations, and participant feedback.

Outcome and interpretation

The pilot reduces coordination time for charities but reveals that same-day collection is unreliable in one district. Grocers value a simple waste-risk report more than automatic ordering because purchasing decisions depend on supplier conversations and local knowledge. The team therefore revises the concept toward a lightweight decision-support and coordination service, with optional integration later.

Learning points

The case illustrates that:

• the first idea may be a solution hypothesis rather than a problem definition;
• root causes often cross organizational boundaries;
• a systems perspective identifies affected parties and unintended effects;
• low-cost experiments can test workflow assumptions before software development; and
• problem–solution fit is iterative rather than a one-time declaration.

Technology, Data, and Artificial Intelligence

Digital tools can assist opportunity identification by clustering interview transcripts, detecting repeated terms, mapping customer journeys, analyzing support tickets, or identifying changes in search and usage patterns. Artificial intelligence can help researchers summarize large datasets or generate alternative framings. However, automated patterns are not equivalent to insight. Models may reproduce sampling bias, confuse correlation with causation, omit minority experiences, or generate plausible but unsupported interpretations.

Good practice includes documenting data sources, protecting confidential information, checking outputs against original evidence, involving domain experts, and retaining human responsibility for consequential decisions. Teams should not upload identifiable interview data to an external system without appropriate consent, security review, and legal authority. Automated opportunity detection can also intensify surveillance or target vulnerable populations in manipulative ways.

The relevant question is not whether AI can produce a list of opportunities, but whether it helps a team make better-supported, more inclusive, and more accountable judgments.

Ethical and Governance Considerations

Problem framing is an ethical act because it determines whose experience is visible, whose needs count, and how resources will be allocated. Teams should ask:

• Who benefits and who may be burdened?
• Which groups are missing from the research?
• Does the proposed solution shift risk to workers, communities, or the environment?
• Are participants able to give informed consent?
• Are privacy, accessibility, safety, and dignity protected?
• Does the framing blame individuals for structural conditions?

Inclusive research should account for differences in language, disability, income, gender, age, location, and digital access. Entrepreneurs should avoid treating a large market as automatically more important than a small population facing severe harm. Regulatory requirements may apply to data protection, health, finance, employment, consumer protection, accessibility, product safety, or environmental claims. Legal compliance is a minimum condition, not a substitute for ethical judgment.

Challenges and Limitations

Problem framing involves unavoidable uncertainty. Users may not accurately remember behaviour, interviews can be influenced by social desirability, and researchers may see what they expect to see. Opportunity scoring can create false precision, especially when ratings are based on small samples. Systems maps can become so broad that they cease to guide action. Root-cause methods can oversimplify nonlinear problems. Rapid experimentation may privilege users who are easy to reach and exclude those with limited time or access.

To manage these limitations, teams should maintain an evidence log, record alternative interpretations, revisit frames after each research cycle, seek disconfirming evidence, involve diverse stakeholders, and separate facts from hypotheses. A strong entrepreneurial process is not one that eliminates uncertainty; it is one that makes uncertainty visible and reduces the most consequential risks efficiently.

Best-Practice Workflow

A practical workflow for problem framing and opportunity identification is:

1. Begin with a meaningful context rather than a predetermined technology.
2. Investigate actual behaviour, workarounds, emotions, constraints, and outcomes.
3. Triangulate evidence across people, methods, and records.
4. Synthesize patterns into insight statements.
5. Write several POV statements and challenge their assumptions.
6. Use root-cause analysis to distinguish symptoms from mechanisms.
7. Map the wider system, including non-users and affected third parties.
8. Identify desirability, feasibility, viability, adoption, and ethical assumptions.
9. Prioritize high-consequence uncertainties for inexpensive testing.
10. Assess problem–solution fit using behaviour and commitments, not enthusiasm alone.
11. Reframe when evidence contradicts the original interpretation.
12. Preserve a clear record of evidence, decisions, limitations, and responsibilities.

Chapter Summary

Problem framing converts research evidence into a clear, meaningful, and actionable understanding of a difficulty. Opportunity identification builds on that understanding by examining whether value can be created for users, organizations, and wider stakeholders. The process moves from observations to patterns, insights, needs, problems, and opportunity hypotheses.

Point-of-view statements focus attention on a specific user, need, and underlying insight. “How might we” design challenges open the solution space while maintaining direction. Root-cause analysis helps distinguish symptoms from contributing and structural causes, while systems maps reveal relationships, dependencies, feedback, and unintended consequences. Assumption analysis makes uncertainty explicit across desirability, feasibility, viability, adoption, scalability, and ethics.

Problem–solution fit requires evidence that a meaningful problem exists and that a proposed response addresses it. Weighted scoring can structure prioritization, but scores depend on assumptions and should not replace judgment. Low-cost experiments, including concierge pilots, are valuable because they test critical assumptions before substantial investment. Technology and AI can support synthesis and pattern detection, but human judgment, privacy protection, inclusion, and accountability remain essential.

Key Terms

Problem framing: Defining and interpreting a difficulty in a way that guides inquiry and design.

Opportunity identification: Recognizing a context in which addressing a problem may create value.

Observation: Directly recorded behaviour, statement, event, or measurement.

Insight: An evidence-based interpretation that explains a meaningful pattern.

Need: A condition or outcome required by a person or system.

Problem space: The domain of users, contexts, causes, effects, and needs under investigation.

Solution space: The domain of possible products, services, technologies, and interventions.

Point-of-view statement: A concise statement linking a specific user, need, and underlying insight.

Design challenge: An open-ended question that directs ideation without prescribing a solution.

Root cause: A deeper condition that contributes to an observed outcome.

Proximate cause: A cause immediately preceding an event or outcome.

Systems map: A representation of actors, relationships, flows, dependencies, and feedback.

Stakeholder: A person or organization affected by, influencing, or involved in an opportunity.

Assumption: A proposition accepted provisionally but requiring evidence.

Desirability: The extent to which people want or value an intervention.

Feasibility: The extent to which an intervention can be built and operated.

Viability: The extent to which value creation can be sustained economically or organizationally.

Problem–solution fit: Evidence that a meaningful problem exists and that a proposed response addresses it.

Triangulation: Comparing multiple evidence sources or methods to strengthen interpretation.

Externality: A benefit or cost imposed on parties not fully represented in a transaction.

Review Questions

Short Answer Questions

1. What is the difference between an observation and an insight?
2. Why should teams avoid framing a problem as a predetermined technology?
3. What are the main components of a point-of-view statement?
4. What is the purpose of a systems map?
5. Name four categories of assumptions that should be tested.

Long Answer Questions

1. Explain how a research team can move from raw evidence to a defensible opportunity area. Illustrate your answer with an example.
2. Compare root-cause analysis and systems mapping. What does each reveal, and what are its limitations?
3. Explain problem–solution fit and distinguish it from product–market fit.
4. Discuss how weighted scoring can support opportunity prioritization and why it should not be treated as objective truth.
5. Evaluate the ethical responsibilities involved in framing problems affecting vulnerable communities.

Analytical / Application Questions

1. A university proposes an app because students frequently miss academic-advising appointments. Frame the problem without assuming an app is the solution, identify three possible root causes, and propose two assumptions to test.
2. A team observes that home-based food producers struggle to obtain customers. Construct a POV statement, a design challenge, and a simple systems map in words identifying at least five stakeholders.
3. Using desirability, feasibility, viability, and ethical impact as criteria, design a prioritization approach for two competing opportunity areas. Explain what evidence would increase or decrease your confidence in the ranking.

Multiple Choice Questions with Answers

Question 1

Which statement best represents an insight?

A. Customers dislike waiting.

B. Customers use a mobile phone.

C. Customers tolerate delays when they receive credible explanations and alternatives, but abandon the service when information is contradictory.

D. The company should build a faster mobile application.

Correct Answer: C. Customers tolerate delays when they receive credible explanations and alternatives, but abandon the service when information is contradictory.

Question 2

What is the main purpose of a point-of-view statement?

A. To specify the final technical architecture

B. To connect a particular user, need, and underlying insight

C. To calculate expected revenue

D. To list every stakeholder in a market

Correct Answer: B. To connect a particular user, need, and underlying insight

Question 3

Which question is most appropriate for identifying a root cause?

A. What colour should the product be?

B. Which competitor has the largest market share?

C. Why does the observed problem occur under these conditions?

D. How can the team launch immediately?

Correct Answer: C. Why does the observed problem occur under these conditions?

Question 4

Which statement best describes a systems map?

A. A list of product features

B. A representation of actors, relationships, flows, and dependencies

C. A legal contract with suppliers

D. A forecast of monthly sales only

Correct Answer: B. A representation of actors, relationships, flows, and dependencies

Question 5

In the weighted scoring model, what condition should the criterion weights satisfy?

A. They must all equal 5.

B. They must be negative.

C. They must sum to 1.

D. They must be measured in currency.

Correct Answer: C. They must sum to 1.

Question 6

If ratings are 4, 5, 3, and 3, with weights 0.30, 0.20, 0.25, and 0.25 respectively, what is the weighted score?

A. 3.25

B. 3.75

C. 4.00

D. 4.25

Correct Answer: B. 3.75

Question 7

Which is the strongest evidence of behavioural demand for a proposed solution?

A. A participant says the idea sounds interesting.

B. A participant agrees that the problem is important.

C. Users repeatedly use a prototype in the relevant context.

D. The design team believes the concept is innovative.

Correct Answer: C. Users repeatedly use a prototype in the relevant context.

Question 8

What is a major limitation of the five-whys method?

A. It cannot be used in organizations.

B. It always requires exactly five questions.

C. It may oversimplify problems with branching or interacting causes.

D. It focuses only on customer preferences.

Correct Answer: C. It may oversimplify problems with branching or interacting causes.

Question 9

Which assumption concerns feasibility?

A. Users experience the problem frequently.

B. The organization can legally and technically access the required data.

C. A paying stakeholder values the outcome.

D. The intervention will be perceived as fair.

Correct Answer: B. The organization can legally and technically access the required data.

Question 10

Why should AI-generated research summaries be checked against original evidence?

A. AI outputs are always too short.

B. Automated systems may reproduce bias or generate unsupported interpretations.

C. Human researchers cannot interpret qualitative data.

D. AI can only process financial information.

Correct Answer: B. Automated systems may reproduce bias or generate unsupported interpretations.