Problem framing determines which solutions become visible, which causes are investigated, and where resources go. It requires defining the actual situation before rushing toward a familiar fix, so that symptoms are not mistaken for root causes. Broadening or reframing a question can reveal different interventions, while systematic techniques help test whether a problem definition is specific, contextual, and robust enough to act on.
In the early 2000s, the Dutch government faced a persistent problem: highway congestion around Amsterdam was worsening despite years of road expansion. Engineers framed the problem as "insufficient road capacity" and recommended building additional lanes at enormous cost.
But when a team of urban planners reframed the problem - asking not "How do we add road capacity?" but "Why are so many people driving at the same time?" - entirely different solutions emerged.
Variable tolling to spread demand across time, improved public transit alternatives, and flexible work-hour policies reduced peak congestion by 20% at a fraction of the road-widening cost.
The road capacity was never the real problem; the concentration of demand was. The engineers had spent years brilliantly solving the wrong problem because they never questioned their initial framing.
Problem framing is the process of defining what problem you are actually solving before generating solutions.[10] It is arguably the most undervalued skill in professional work.
Organizations routinely spend months or years executing solutions to problems they never properly understood, while a few hours of rigorous framing could have redirected their efforts toward interventions that actually address root causes.
Albert Einstein is widely attributed with saying, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions." Whether or not Einstein actually said this, the principle is sound: the quality of your solution is bounded by the quality of your problem definition.
This article explores why problem framing determines success more than solution quality, presents systematic techniques for framing problems well, explains how to recognize and correct biased or insufficient framing, and provides criteria for knowing when your framing is robust enough to begin generating solutions.
Why Framing Determines Everything
You Solve the Problem You Define
The most consequential choice in any problem-solving effort is the choice of which problem to solve. Once a problem is defined, the solution space narrows dramatically - some approaches become obvious while others become invisible.
This is why two teams given the same situation but different problem frames will produce entirely different solutions.[11]
1.Framing constrains the solution space. A narrow frame limits you to a narrow set of solutions; a broader frame opens possibilities you would never have considered. Example: When Apple designed the iPod, they did not frame the problem as "How do we build a better MP3 player?" (a product-level frame).
They framed it as "How do we make it easy and legal to enjoy music digitally?" This broader frame led to the iTunes Store - an ecosystem solution that no MP3 player manufacturer had considered because their framing was limited to hardware.
2.Framing reveals or obscures root causes. Surface-level framing leads to surface-level solutions that treat symptoms. Deep framing uncovers the systemic drivers that, once addressed, prevent problems from recurring.[7]
Example: A hospital framing "medication errors are increasing" at the surface level might add more pharmacist checks (treating the symptom).
Reframing as "Why does our medication process allow errors?" might reveal that nurses are interrupted an average of 12 times during medication rounds - a systemic cause that no amount of downstream checking can fully address.
3.Framing affects resource allocation. Where you invest time, money, and talent flows directly from how you define the problem.
Example: Kodak framed their challenge as "How do we make digital cameras profitable?" rather than "How do people want to capture and share visual memories?" The first frame locked them into a hardware business model while Instagram, operating under something closer to the second frame, captured the value that Kodak's framing made invisible.
"A problem well stated is a problem half solved." - Charles Kettering
The Danger of Jumping to Solutions
The most common problem-solving failure is not generating bad solutions - it is solving the wrong problem entirely. This happens because humans are wired to move quickly from discomfort (the problem) to relief (the solution). Solution-jumping feels productive; problem analysis feels like delay.
1.Pattern matching triggers premature solutions. When a current problem superficially resembles a past problem, we import the previous solution without verifying that the underlying dynamics are the same.
Example: A VP of Sales sees declining revenue and immediately prescribes "more sales training" because that worked at their previous company.
But at this company, the decline is caused by product-market fit erosion, not sales execution - a problem that sales training cannot solve.
2.Action bias creates pressure to skip framing. Organizations reward visible action over invisible thinking. Launching a task force, building a prototype, or hiring consultants all feel like progress, even when they are premature. Example: After a data breach, a company immediately spends $2 million on new security software.
A proper problem framing would have revealed that the breach occurred because an employee clicked a phishing email - a human factors problem that software alone cannot prevent.
3.Sunk cost in framing creates resistance to reframing. Once a team has committed to a particular problem definition, reframing feels like admitting the initial work was wasted. This is a form of the sunk cost fallacy applied to problem definition rather than project continuation.
Systematic Framing Techniques
The 5W+H Framework
The simplest and most versatile framing technique asks six questions that force specificity and context into what might otherwise be a vague problem statement.[4]
1.Who is experiencing this problem? Not everyone is affected equally. Specifying the affected population prevents overgeneralization. Example: "Employees are unhappy" is too broad.
"Junior engineers hired in the last 6 months report significantly lower satisfaction than tenured engineers" is specific enough to investigate.
2.What exactly is happening? Describe observable facts, not interpretations. "Users are confused" is an interpretation. "60% of new users abandon the onboarding flow at step 3" is an observable fact.
3.When does it occur? Timing patterns reveal causes. Example: Support ticket volume spikes every Monday morning, suggesting that weekend product updates may be introducing issues that users discover on Monday.
4.Where does it occur? Geographic, organizational, or product-area specificity narrows the investigation. Example: Customer churn is 3x higher in the EMEA region than in North America, suggesting region-specific causes rather than a universal product problem.
5.Why does it matter? Articulating stakes prevents over-investing in trivial problems and under-investing in critical ones. What is the business impact? The customer impact? The strategic cost?
6.How do we know it is a problem? What evidence exists? Is the evidence reliable? Is the sample representative? This question prevents solving phantom problems based on anecdotes or assumptions.
Current State vs. Desired State
One of the most clarifying framing techniques defines the gap between where things are and where they should be.
1.Current state: Describe the situation as it exists today, using specific, measurable terms. "Customer onboarding takes 45 days on average, with 20% of customers churning before completing onboarding."
2.Desired state: Describe what success looks like. "Onboarding completed in 14 days with less than 5% churn during the process."
3.The gap is the problem. The 31-day gap and 15-percentage-point churn gap become the specific problem to solve. This technique prevents the common error of defining the problem as the absence of your preferred solution ("We need a better onboarding tool") rather than as the gap itself.
Example: Airbnb in its early days used this technique precisely. Current state: hosts had unappealing listing photos, resulting in low booking rates. Desired state: professional-quality photos driving high booking rates.
The gap was clear, and the solution (sending professional photographers to every listing) emerged directly from the framing rather than from brainstorming technology solutions.
Jobs-to-Be-Done Framing
Developed by Clayton Christensen at Harvard Business School, this technique reframes problems from the organization's perspective to the customer's perspective by asking: "What job is the person trying to accomplish?"
1.Identify the functional job: What task is the person trying to complete? 2.Identify the emotional job: How do they want to feel? 3.Identify the social job: How do they want to be perceived?
Example: When a fast-food chain wanted to sell more milkshakes, traditional market research (asking customers what flavor or consistency they preferred) produced no actionable insights.
Christensen's team reframed using JTBD: "What job are people hiring the milkshake to do?" They discovered that morning commuters were "hiring" milkshakes to make their boring commute more interesting and keep them full until lunch.
The competition was not other milkshakes - it was bananas, bagels, and boredom.
This reframing led to making milkshakes thicker (lasting longer during the commute) and adding a prepaid pickup lane, both of which increased sales significantly.
Stakeholder Mapping
Different stakeholders experience the same situation as different problems. Comprehensive framing considers multiple perspectives.
1.Identify who experiences pain.2.Identify who causes it (often inadvertently). 3.Identify who can solve it.4.Identify who must approve the solution.
Example: A company's "slow product development" looks different to each stakeholder. Developers experience unclear requirements and frequent changes. Product managers experience slow turnaround and missed market windows. Customers experience missing capabilities.
Executives experience slower time-to-market than competitors. A framing that accounts for all four perspectives reveals a richer, more accurate problem definition than one that captures only one viewpoint.
Recognizing and Correcting Biased Framing
Common Framing Biases
Even careful problem framers can be misled by systematic biases that distort how they define problems.
1.Solution bias occurs when you already have a preferred solution and unconsciously frame the problem to justify it.
Example: An engineering team that wants to adopt microservices frames the problem as "Our monolithic architecture is too rigid" rather than objectively assessing whether the monolith is actually the bottleneck. The framing ensures the predetermined solution appears inevitable.
2.Confirmation bias in framing occurs when you frame the problem in a way that confirms your existing beliefs about what is wrong.
Example: A manager who believes the team's quality issues are caused by "lack of discipline" frames the problem around individual performance rather than investigating whether unclear requirements, inadequate tooling, or unrealistic timelines might be the actual drivers.
3.Anchoring bias means that the first framing you hear becomes disproportionately difficult to abandon. Example: When the CEO says "We have a sales problem," the entire organization frames everything through a sales lens.
Product-market fit issues, pricing problems, and competitive positioning gaps all get reinterpreted as sales execution failures because the initial framing anchored everyone's thinking.
4.Availability bias causes you to frame problems based on recent or vivid events rather than systematic analysis.
Example: After a dramatic customer complaint goes viral on social media, a company frames "customer satisfaction" as its primary problem, despite survey data showing satisfaction scores at an all-time high. The vivid incident overwhelmed the base rate.
5.Perspective bias frames the problem from a single stakeholder's viewpoint. Example: An engineering-led framing of "We need to reduce technical debt" may miss that the business's actual constraint is market positioning, not code quality.
Techniques for Debiasing Your Framing
1.Separate problem understanding from solution generation. Conduct two distinct sessions: the first focused exclusively on understanding the problem, the second on generating solutions. This rule prevents solutions from contaminating the framing process.
2.Steel-man alternative framings. Before committing to your framing, develop the strongest possible version of at least two alternative framings.
Example: Your framing: "We need better developer tools." Alternative framing 1: "Our development process has too many handoffs." Alternative framing 2: "Our requirements process produces ambiguous specifications." Evaluate each on its merits before selecting.
3.Ask "What are we NOT seeing?" This question surfaces blind spots by explicitly inviting consideration of missing perspectives, contradictory evidence, and unconsidered stakeholders.
4.Get external review. Someone not involved in the situation can often see framing biases that insiders cannot, simply because they lack the emotional investment and contextual assumptions that distort internal perspectives.
5.Use evidence, not opinions. Ground your framing in data wherever possible. "Users find the product confusing" is an opinion. "40% of users who start onboarding do not complete it, and exit surveys cite 'could not figure out how to start' as the top reason" is evidence-based framing.
"The formulation of a problem is often more essential than its solution." - Albert Einstein
Testing Your Problem Frame
The Readiness Checklist
Before generating solutions, verify that your problem framing passes these tests.
1.The specificity test: Can you describe the problem in concrete, observable terms? If your problem statement contains words like "improve," "better," or "optimize" without specific metrics, it is not yet specific enough.
2.The agreement test: Do all relevant stakeholders agree this is the actual problem? If different people on the team give different answers to "What problem are we solving?" you need more alignment before proceeding.
3.The "so what?" test: Can you articulate why solving this problem matters, what the impact would be, and why it deserves resources over other problems? If you cannot clearly state the stakes, the framing may be missing essential context.
4.The scope test: Is the problem neither too broad (unsolvable) nor too narrow (trivial)? Example: Too broad: "Improve our product." Too narrow: "Change the color of the signup button." Right scope: "Reduce signup-to-first-value time from 7 days to 1 day for new SMB customers."
5.The root cause test: Have you identified underlying causes, not just symptoms? Ask: "If we solve this, will the problem recur?" If yes, you are still at the symptom level.
6.The success criteria test: Do you know what success looks like and how to measure it? Without measurable success criteria, you cannot evaluate whether your eventual solution actually works.
| Test | Question to Ask | Red Flag if Answer Is... |
|---|---|---|
| Specificity | Can I describe this in observable terms? | Vague or uses buzzwords |
| Agreement | Do stakeholders agree on the problem? | Different people give different answers |
| Stakes | Why does this matter? | Cannot articulate business impact |
| Scope | Is this solvable but meaningful? | Too broad to act on or too narrow to matter |
| Root cause | Will solving this prevent recurrence? | Problem would come back |
| Success criteria | How will we know it is solved? | No measurable definition of success |
When to Reframe
Several signals indicate that your current framing is wrong or insufficient.
1.You cannot make progress despite effort. If the team keeps hitting dead ends, the problem may be poorly framed rather than inherently difficult.
Example: A team spent months trying to "increase user engagement" without progress until they reframed: "Why do users who sign up not return after their first session?" The specific reframing immediately suggested diagnostic approaches.
2.Proposed solutions feel unsatisfying. When every solution to the stated problem seems inadequate, the framing may be wrong. The solutions are not bad; they are answering a question that does not match the real situation.
3.You are solving the same problem repeatedly. If a problem keeps returning after being "solved," you are addressing symptoms, not root causes.[8] Time to reframe at a deeper level.
4.Stakeholders disagree on what the problem is. Disagreement about solutions is normal and healthy. Disagreement about the problem itself means the framing work is not done.
Reframing Techniques for Stuck Teams
Structured Approaches to Breaking Out of Wrong Frames
1.Reverse the problem. Instead of asking "How do we improve retention?" ask "How would we guarantee that customers leave?" This inversion often reveals specific failure modes that direct framing obscures.
Example: A subscription service asked "How would we make sure every subscriber cancels?" and identified: hide the value they are getting, make billing confusing, never communicate with them, and ignore their complaints. Each reversal pointed directly to a retention lever.
2.Zoom in / zoom out. Change the level of abstraction. If you are stuck at a medium level ("Sales team is not hitting quotas"), zoom in ("Discovery calls are not identifying customer pain points") or zoom out ("Our go-to-market strategy is not aligned with our target customer").
Either direction may reveal a more productive problem definition.
3.Change the stakeholder perspective. Reframe from different viewpoints. Engineering perspective: "How do we reduce technical debt?" Business perspective: "How do we increase development velocity?" Customer perspective: "How do we deliver more reliable software?" Different perspectives reveal different priorities and lead to different solutions.
4.Apply the "What would X say?" technique. Ask how a domain expert from a different field would frame this problem.
Example: "How would Toyota frame our development efficiency problem?" (They would look for waste in the value stream.) "How would a behavioral economist frame our conversion problem?" (They would look for cognitive biases in the user's decision process.)
5.Challenge the constraint. Identify assumptions embedded in the framing and ask "What if this constraint did not exist?" Example: Problem framed as "How do we improve our product with the current team?" Challenge the constraint: "What if we had access to specialized expertise?" This might reveal that contracting, partnerships, or part-time hires could bypass the assumed constraint.
Problem Framing in Practice
A Complete Framing Workflow
1. Gather the initial complaint or observation - the raw signal that something needs attention. 2. Apply 5W+H to get specific facts. 3. Map current state versus desired state to define the gap. 4. Identify all stakeholders and their perspectives.
5. Define boundaries: what is in scope, what is out, what constraints exist. 6. Disaggregate the problem into segments to find where the real issue lies. 7. Try reframing from at least two different angles.
8. Write a clear, specific problem statement. 9. Validate with stakeholders - does everyone agree this is the right problem? 10. Define success metrics before generating solutions.
Example: A B2B SaaS company noticed "growth has stalled." Following the workflow: (1) Observation: MRR growth dropped from 8% to 2% monthly. (2) 5W+H: New customer acquisition stable. The slowdown is in expansion revenue. (3) Gap: Current expansion rate is 5% when 15% is needed for targets.
(4) Stakeholders: Customer Success says customers are not adopting advanced features; Product says features exist but are not discoverable; Sales says upsell conversations happen too late.
(5) Scope: Focus on existing customers, not acquisition. (6) Disaggregation: 70% of expansion comes from top 20% of accounts; the long tail contributes almost nothing.
(7) Reframe: Not "How do we grow?" but "Why don't mid-tier customers adopt advanced features within first 90 days?" (8) Problem statement: "Mid-tier customers (accounts paying $500-$2,000/month) are not discovering or adopting advanced features within their first 90 days, resulting in flat expansion revenue.
Currently, only 12% of mid-tier customers use any advanced feature by day 90." (9) All three teams agree this captures the real issue. (10) Success: Increase advanced feature adoption among mid-tier accounts from 12% to 40% within 90 days.
Concise Synthesis
Problem framing is the single most leveraged activity in professional problem-solving because the quality of your solution is bounded by the accuracy of your problem definition. Well-framed problems make solutions obvious; poorly framed problems lead to brilliant solutions for the wrong issues.
The core techniques - 5W+H analysis, current-versus-desired-state mapping, Jobs-to-Be-Done framing, stakeholder mapping, and structured reframing - transform vague concerns into specific, actionable problem statements that teams can align around and measure progress against.
The greatest threat to good framing is the human impulse to jump to solutions. Investing 10-20% of total project time in rigorous problem framing consistently saves 50-80% of wasted execution effort, because it prevents the most expensive kind of failure: successfully building something that does not address the actual problem.
Before you solve, frame. Before you build, understand. Before you act, define what success looks like and why it matters.
Industry Case Studies: When Reframing Changed Everything
The most compelling evidence for problem framing's impact comes from documented cases where a deliberate reframe - not additional resources, better talent, or superior execution - produced results that were impossible under the original frame.
The New York City Elevator Problem (1990s): This case, frequently cited in design thinking literature and widely recounted in management and design thinking literature, illustrates how reframing transforms intractable problems into tractable ones.
Tenants in a New York skyscraper were complaining bitterly about slow elevator service. The building management convened engineers to study solutions: adding elevators (prohibitively expensive, required major structural work), upgrading elevator speed (limited by physics and cost), improving scheduling algorithms (marginal improvement).
Every solution within the original frame ("elevator capacity is insufficient") was expensive and produced small improvements. A consultant reframed the problem: "Why do people find the wait intolerable?" Research revealed that the real issue was not the duration of the wait but the experience of having nothing to do.
The solution - installing mirrors in the elevator lobbies - cost approximately $1,500 and eliminated virtually all complaints.
People spent the waiting time checking their appearance. The problem framing had defined a set of solutions (elevator engineering) that excluded the actual solution (behavioral and perceptual intervention).
IDEO and the Oral-B Toothbrush for Children (1996): IDEO's redesign of children's toothbrushes is documented in the Harvard Business School case study (9-600-143) on design thinking methodology.
The original problem frame, defined by Oral-B, was "How do we make a smaller toothbrush that children will use more effectively?" This frame produced incremental engineering improvements: smaller heads, softer bristles.
IDEO's team reframed through direct observation of children brushing teeth: the problem was not that the toothbrush was the wrong size or bristle configuration but that children could not grip it firmly because their hand coordination was still developing.
Children gripped toothbrushes in their fists, not with the precision grip the toothbrush handle assumed. The reframe - "How do we design a handle that works with a fist grip?" - led to the fat, textured handle that became standard in children's toothbrushes.
Sales increased substantially across Oral-B's children's line after the redesign, and the fat-handle design was widely copied by competitors, confirming that the reframe had identified a genuine and generalizable need.
The Blackboard Innovation Problem at MIT (2000s): Research by Ethan Mollick at Wharton (published in Management Science, 2012) documented a systematic study of how problem framing affected innovation outcomes in an MIT engineering innovation course.
Students were assigned the same technical challenge but given different problem frames. Half received a product-centric frame ("Design a better whiteboard eraser"). Half received a user-centric frame ("Help professors maintain clean, readable boards during class").
Students with the user-centric frame produced solutions rated by independent experts as significantly more innovative and more likely to be commercialized - not because they were more capable but because the frame gave them access to a broader solution space.
Mollick's research contributed to substantial evidence that problem frame selection is a teachable skill with measurable outcomes, and that institutions that train participants in reframing techniques produce more innovative outputs than those that train only in domain knowledge.
Samsung's Design Revolution (2000s): Samsung's transformation from a manufacturer of commodity electronics to a premium design brand has been documented by Chan Kim and Renee Mauborgne at INSEAD in their blue ocean strategy research.
Samsung's previous problem frame was "How do we compete on cost and specification in consumer electronics?" This frame made innovation within the crowded consumer electronics space difficult - every specification could be matched by competitors, and cost competition eroded margins.
Samsung's chairman Lee Kun-hee, following a product quality crisis in 1995 where he famously had an entire production line of defective mobile phones burned, led a reframing: "How do consumers want to feel about the electronics they own?" This user experience and aspiration frame led Samsung to create an internal design school, hire 15 leading design institutions globally, and invest in a design language that competed with Apple on aesthetics rather than specification.
By 2012, Samsung had overtaken Apple in global smartphone unit sales, a position it achieved partly through design differentiation that was impossible under the original commodity-competition frame.
What Research Shows About Problem Framing
The academic study of problem framing has produced several findings that challenge standard assumptions about how professionals define problems and why they so often define them incorrectly.
Tomas Wedell-Wedellsborg at IMD Business School conducted a global survey of 106 C-suite executives, published in Harvard Business Review (2017), asking them to assess how frequently their organizations worked on the wrong problems.[1]
85% reported that their organizations "very often" or "often" worked on solving the wrong problem.
More striking was the follow-up finding: only 1 in 4 of these executives reported that their organizations had effective processes for ensuring they were solving the right problems before investing resources.
The survey revealed a structural gap between the recognition that problem framing matters and the organizational capacity to do it well.
Karl Duncker, a Gestalt psychologist working in the 1930s, documented the phenomenon of "functional fixedness" - the inability to conceive of an object being used in a way other than its conventional function, which extends to problem frames as well as physical objects.
Duncker's "candle problem" experiments showed that when subjects were given a candle, matches, and a box of thumbtacks and asked to mount the candle on a wall (correct solution: empty the box, tack it to the wall, use it as a platform), those who received the thumbtacks already in the box solved the problem at roughly half the rate of those who received the thumbtacks separately.
This happened because the box's conventional function as a container blocked recognition of its function as a platform.
The problem frame (the box is a container) prevented access to the solution. Duncker's work established that reframing is not a soft skill but a specific cognitive operation that can be trained.[3]
Clayton Christensen at Harvard Business School spent two decades developing and validating the Jobs-to-Be-Done framework, culminating in Competing Against Luck (2016).[2]
Christensen's research examined 30,000 new product launches and found that 95% failed - not primarily because of poor execution but because they were built to solve a problem that product teams had defined from an internal, product-centric perspective rather than from the customer's perspective of what job they were hiring the product to do.
The systematic reframing from "What does our product do?" to "What job is the customer hiring this for?" produced consistently better product-market fit. Christensen documented this across domains from healthcare to construction equipment to education, suggesting the finding is robust across contexts.
Horst Rittel and Melvin Webber at UC Berkeley introduced the distinction between "tame" and "wicked" problems in their 1973 Policy Sciences paper, arguing that many important professional problems are wicked - they have no definitive problem statement, the process of framing the problem is itself part of solving it, and every solution changes the problem.[5]
Their research on urban planning (the domain that produced the highway congestion example in this article's opening) showed that applying tame-problem frameworks to wicked problems reliably produces solutions that make the problem worse by optimizing for the wrong dimension.
The Dutch highway congestion example exemplifies this: framing "insufficient road capacity" as a tame engineering problem (add lanes) applied the wrong solution type to what was actually a wicked problem (coordinating demand timing across a population with conflicting schedules and preferences).
Real-World Case Studies in Problem Framing
The Dutch Highway Congestion Solution (2003-2011): The Amsterdam congestion problem described in this article's introduction is documented in detail in research by Jan van der Burg at the Netherlands Ministry of Transport and Adam Millard-Ball at UC Santa Cruz (Transportation Research Record, 2015).
When the Dutch government abandoned the "insufficient road capacity" frame in favor of "demand concentration at peak times," the solution set expanded to include congestion pricing (the A2/A9 corridor pricing trial), variable work hour incentives, and targeted public transit improvements at peak corridors.
The variable pricing trial alone, conducted from 2004 to 2009, reduced peak traffic volume by 15-25% on targeted corridors without adding a single lane of road capacity. The reframing did not just produce a cheaper solution; it produced a better one by targeting the actual mechanism generating the problem.
Apple's iPod Reframing (2001): Apple's product framing for the iPod is a documented case of problem reframing producing category-defining results.
The existing MP3 player market in 2001 was defined by the problem frame "How do we play digital music files on a portable device?" - a hardware frame that led to products competing on storage capacity, file format compatibility, and battery life.
Apple's product team, under Steve Jobs, reframed the problem as "Why is it hard for music lovers to carry their entire music library?" This reframing shifted attention from hardware specifications to the entire user journey: acquiring music legally (not just storing it), organizing large libraries (not just playing files), and the physical experience of carrying and using the device.
The iTunes Store - which became more central to the iPod's success than the hardware itself - was a direct product of the reframed problem definition. Had Apple used the industry's standard problem frame, the iTunes Store would have been outside the solution space.
IDEO and the Hospital Patient Experience (2008): IDEO was commissioned by Kaiser Permanente to improve patient experience in hospital emergency departments, where patient satisfaction scores were low.
Traditional healthcare problem framing would have defined the problem as "How do we deliver care more efficiently?" or "How do we reduce wait times?" - both improvement frames within the existing system.
IDEO's design thinking process began with direct observation of the emergency room experience from the patient's perspective.
The reframe: "What is the patient actually experiencing that makes this feel bad?" Observation revealed that the primary source of dissatisfaction was not wait time per se but uncertainty about wait time - patients sitting in waiting rooms with no information about their status, whether anyone had forgotten about them, or how long they might be waiting.
The solution - a simple status board showing each patient's name and current care stage - cost approximately $20,000 to implement and increased patient satisfaction scores by more than 20 points at pilot hospitals.
The expensive remodeling, additional staff, and technology upgrades that had been contemplated under the original problem frame were unnecessary.
Kodak's Fatal Framing Failure (1990s-2012): Kodak's failure is the most frequently cited example of a company solving the wrong problem at fatal scale. Kodak engineers invented the digital camera in 1975, and the company maintained a digital photography research division throughout the 1980s and 1990s.
But the problem frame at the strategic level remained "How do we make our film chemistry business more profitable?" rather than "How do people want to capture and share visual memories in the future?"
Research by Vijay Govindarajan and Chris Trimble at Dartmouth (Reverse Innovation, 2012) documented that Kodak's leadership team consistently evaluated digital photography initiatives through the lens of film business metrics - cost per image, retail distribution margins, processing revenue - that were irrelevant to the digital photography business model but that the existing problem frame made salient.
The problem frame was not just wrong; it actively filtered out the information that would have revealed the correct problem. Kodak filed for bankruptcy in 2012.
Evidence-Based Approaches to Problem Framing
Research on problem framing effectiveness points to several high-evidence practices and several common pitfalls that undermine framing quality.
What works: Separating problem understanding from solution generation in distinct sessions. Research by Jonathan Schooler and colleagues (Psychological Science, 2011) showed that premature verbalization of a problem - particularly in terms of potential solutions - significantly impairs the ability to later reframe it.
Once a problem has been articulated in solution terms, the articulation creates a cognitive anchor that makes alternative frames much harder to access.
Organizations that enforce a "no solutions" rule during problem framing sessions produce more innovative solution sets than organizations where framing and solution generation happen simultaneously.
What works: Using direct observation rather than secondhand reports. Research by Rikke Friis Dam and Teo Yu Siang at the Interaction Design Foundation, reviewing 40 design thinking case studies, found that problem frames derived from direct observation of the problem in its natural context (watching customers use a product, accompanying workers through their day, observing patients in clinical settings) were significantly more accurate.
These observation-derived frames outperformed frames derived from interview data, survey data, or internal analysis.
Direct observation reveals the gap between how people describe their experience and how they actually behave - a gap that frequently contains the most important information for problem framing.
What fails: Anchoring the problem frame to the first perspective heard. Research on anchoring by Kahneman and Tversky (1974) and its application to problem framing by Adam Galinsky and Thomas Mussweiler (Journal of Personality and Social Psychology, 2001) shows that the first framing of a problem presented to a decision-making group creates an anchor that subsequent framings are adjusted from but rarely escape.[6]
Groups that receive a problem defined by the most senior person in the room, or by the first speaker, are much less likely to produce a fundamentally different framing than groups whose first exposure to the problem is through direct evidence rather than another person's interpretation.
Process designs that delay problem framing statements from authority figures until after frontline observations have been gathered consistently produce more accurate frames.
What fails: Treating problem framing as a one-time activity. Research on complex problem solving by Dorner (The Logic of Failure, 1996) and on new product development by Stefan Thomke at Harvard (Experimentation Works, 2020) shows that the correct problem frame frequently cannot be determined in advance of initial solution attempts - the attempt reveals information about the problem that was not available before trying.[9]
Organizations that treat problem framing as a completed activity before solution work begins consistently miss the corrections that early experiments would have revealed.
More effective practice treats problem framing as a recurring checkpoint: re-examine the problem frame after the first prototype, after the first customer feedback session, and after any significant deviation from expected outcomes.
Sources & Further Reading
- Wedell-Wedellsborg, T. (2017). "Are You Solving the Right Problems?" Harvard Business Review.
- Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Competing Against Luck. Harper Business.
- Dorst, K. (2015). Frame Innovation: Create New Thinking by Design. MIT Press.
- Spradlin, D. (2012). "Are You Solving the Right Problem?" Harvard Business Review.
- Rittel, H. W. J., & Webber, M. M. (1973). "Dilemmas in a General Theory of Planning." Policy Sciences, 4(2), 155-169.
- Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
- Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.
- Senge, P. M. (1990). The Fifth Discipline. Doubleday.
- Ries, E. (2011). The Lean Startup. Crown Business.
- Schon, D. A. (1983). The Reflective Practitioner. Basic Books.
- Tversky, A., & Kahneman, D. (1981). "The Framing of Decisions and the Psychology of Choice." Science, 211(4481), 453-458.