Problem Framing Explained: Defining Problems Before Solving Them
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. 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.
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. 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.
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. 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.
References
- 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.
Frequently Asked Questions
Why does problem framing matter more than solution finding?
Well-framed problems are half-solved—poor framing leads to brilliant solutions for wrong problems, while good framing often makes solutions obvious. **The power of framing**: Einstein supposedly said: 'If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.' **Why framing determines success**: **You solve the problem you define**: Frame it wrong, solve wrong problem. **Example**: Problem framed as: 'How do we get more users?' Build growth features, run ads. Actual problem: Existing users don't get value, churn quickly. More users makes problem worse. Wrong framing led to counterproductive solution. **Framing opens or constrains solution space**: How you frame determines what solutions are possible. **Example narrow**: 'How do we reduce page load time?' (Technical framing). Solutions limited to: Code optimization, caching, CDN. **Example broader**: 'How do we improve perceived performance?' (Experience framing). Additional solutions: Loading skeletons, progressive rendering, managing expectations. Broader framing unlocks more solutions. **Framing reveals or obscures root causes**: **Example surface framing**: 'Employees keep making mistakes.' Surface solutions: More supervision, punishment. **Example root framing**: 'Our process allows critical errors without safeguards.' Root solutions: Process redesign, error-proofing, automation. Framing depth determines solution quality. **What good problem framing provides**: **Clarity on what you're solving**: Specific, not vague. Actionable scope. **Understanding of why it matters**: Stakes and impact clear. Motivates right level of effort. **Shared understanding**: Team aligned on problem, not working on different problems. **Evaluation criteria**: Know what success looks like. Can measure if solved. **Example of framing power**: **Company situation**: E-commerce startup, growth stalled. **Poor framing**: 'We need more features.' Team builds feature after feature. Growth doesn't improve. Wrong problem. **Better framing**: 'Why is growth stalling? Acquisition working? Activation? Retention?' Analysis shows: Acquisition fine. Users sign up but don't complete first purchase. Retention fine for users who purchase. **Actual problem**: 'Why do users browse but not purchase?' Investigation: Checkout flow confusing. Trust signals weak (new brand). Shipping costs hidden until final step. **Real problem framed**: 'Users abandon checkout due to: confusion (UX), trust concerns, surprise costs.' **Solutions now obvious**: Simplify checkout. Add trust badges and reviews. Show shipping costs upfront. Growth resumes. Good framing revealed real problem; solutions became apparent. **The danger of jumping to solutions**: **What happens**: See problem, immediately think of solution. Lock onto solution. Start implementing. **Why it fails**: Haven't understood problem deeply. Solution may address symptom not cause. Better solutions never considered. **Example**: Customer support overwhelmed. Quick solution: Hire more support agents. (Solution-first thinking). Better approach: Why is support overwhelmed? Investigate: 60% of tickets are 'How do I do X?' questions. Root cause: Documentation poor and feature discoverability low. Better solution: Improve docs and in-app guidance. Prevents tickets rather than scaling to handle them. Jumping to solutions skips crucial problem understanding phase. **The lesson**: Problem framing matters more than solution finding because you solve the problem you define—wrong framing leads to solving wrong problems. Framing opens or constrains solution space and reveals or obscures root causes. Good framing provides clarity on what you're solving, why it matters, shared team understanding, and evaluation criteria. Poor framing leads to brilliant solutions for wrong problems; good framing often makes solutions obvious. Invest time understanding and framing problem before generating solutions—saves effort and increases success probability dramatically.
What are effective techniques for framing problems correctly from the start?
Systematic framing techniques transform vague complaints into actionable problem statements—using structured approaches prevents premature solution-jumping and ensures solving right problems. **Technique 1: The 5W+H framework**: **Questions**: Who is experiencing this problem? What exactly is happening? (Observable facts). When does it occur? Where does it occur? Why does it matter? How do we know it's a problem? **Example**: Complaint: 'Sales team is underperforming.' Apply 5W+H: Who: Enterprise sales team (not SMB). What: Missing quarterly quota by average of 30% for past 2 quarters. When: Started Q3 last year when moved upmarket. Where: Primarily in EMEA region. Why matters: Enterprise segment is strategic growth focus. How we know: CRM data shows pipeline conversion rates dropped from 25% to 15%. Specific, contextual problem emerges. **Technique 2: Current state vs desired state**: **Template**: Currently [specific situation] is happening, causing [specific consequences]. We want [specific desired outcome] instead. Gap between current and desired state is the problem. **Example**: Currently: Customer onboarding takes 45 days on average, causing delayed time-to-value and 20% of customers churning before fully onboarded. Desired: Onboarding in 14 days with <5% churn rate. Problem: 31-day gap and 15% churn gap. Need to understand what causes extended onboarding and early churn. **Technique 3: Jobs-to-be-done framing**: **Approach**: Frame problem in terms of what people are trying to accomplish (job) and why current situation fails. **Template**: [People] are trying to [accomplish job] in order to [higher goal]. Currently they struggle because [specific obstacles]. **Example**: Sales reps are trying to quickly understand prospect needs in order to personalize outreach. Currently they struggle because: relevant information scattered across 5 tools, takes 30 minutes to research each prospect, information often outdated. Problem clearly framed around the job and obstacles. **Technique 4: Constraint identification**: **Approach**: Identify what can't change or is hard to change. Reveals realistic problem boundaries. **Categories**: Non-negotiable constraints (regulations, budgets, time). Difficult-to-change factors (culture, technical debt, market conditions). Variables you can control. **Example**: Problem: Need to scale customer support. Constraints: Can't increase budget by more than 20%. Can't compromise response quality. Must support 3 timezones. These constraints shape how problem must be solved—likely optimization and automation, not just hiring. **Technique 5: Stakeholder mapping**: **Approach**: Identify who is affected and how. Different stakeholders may experience problem differently. **Questions**: Who experiences pain? Who causes it (possibly inadvertently)? Who can solve it? Who has to approve solution? **Example**: Problem: 'Slow product development.' Stakeholders: Developers experience: Unclear requirements, frequent changes. Product managers experience: Slow turnaround on features. Customers experience: Missing needed capabilities. Executives experience: Slower time-to-market than competitors. Each stakeholder has different perspective—comprehensive framing considers all. **Technique 6: The 'So what?' cascade**: **Approach**: State problem, then ask 'So what? Why does this matter?' Repeat 3-5 times to reach core issue. **Example**: Statement: Page load time is 3 seconds. So what? Users wait longer. So what? Some users abandon. So what? Conversion rate drops. So what? Revenue decreases. So what? Miss growth targets. Core issue: Revenue impact, not just technical metric. Reveals true stakes. **Technique 7: Disaggregation and segmentation**: **Approach**: Break broad problem into specific segments to find where real problem lies. **Example**: Broad: 'Customer churn is high' (12%). Segment by: Time-to-churn: 60% churn in first month (onboarding issue). 30% churn months 2-6 (early value realization issue). 10% churn after 6 months (long-term product fit issue). Customer type: Enterprise: 5% churn. SMB: 15% churn. Disaggregation reveals: Real problem is SMB onboarding, not general churn issue. Focused problem framing enables targeted solution. **Technique 8: Hypothesis-driven framing**: **Approach**: Frame as testable hypotheses about cause. **Template**: We believe [problem] is occurring because [hypothesis about cause]. We can test this by [evidence/experiment]. If we're right, we should see [prediction]. **Example**: Hypothesis: Low conversion is occurring because pricing page is confusing. We can test by: A/B testing redesigned pricing page. If we're right: Redesigned page will increase conversion. Testable framing enables learning. **Technique 9: Boundary questions**: **Approach**: Explicitly define what's in and out of scope. **Questions**: What are we solving? What are we NOT solving? What timeframe matters? What resources available? What's success metric? **Example**: Problem: Improve developer productivity. Boundaries: In scope: Development workflow tools and processes. Out of scope: Hiring, compensation, office environment. Timeframe: Show improvement within 6 months. Resources: One developer advocate, $50K budget. Success: 15% reduction in time-from-commit-to-production. Clear boundaries prevent scope creep and misalignment. **Technique 10: Problem reframing exercise**: **Approach**: Deliberately reframe problem from multiple angles. Reveals assumptions and new possibilities. **Reframing lenses**: **Technical vs business**: Technical: 'How do we scale database?' Business: 'How do we support 10x more customers profitably?' **Internal vs external**: Internal: 'Our sales process is too slow.' External: 'Customers can't evaluate our product efficiently.' **Prevent vs cure**: Prevent: 'How do we stop bugs from reaching production?' Cure: 'How do we fix production bugs faster?' **Cost vs value**: Cost: 'How do we reduce support costs?' Value: 'How do we maximize customer success?' Different framings reveal different solutions. **Common framing mistakes to avoid**: **Mistake 1: Stating solution as problem**: Bad: 'We need a mobile app' (that's solution). Better: 'Users can't access our service when away from desktop, limiting usage.' **Mistake 2: Vague problem statements**: Bad: 'User experience could be better.' Better: 'Users abandon shopping cart at 35% rate, primarily due to confusing checkout flow.' **Mistake 3: Accepting first framing**: First framing often wrong. Challenge and reframe multiple times. **Mistake 4: Individual blame framing**: Bad: 'John keeps making mistakes' (blames person). Better: 'Quality control process allows critical errors to reach production' (systems framing). **The problem framing workflow**: **Step 1**: Gather initial complaint or observation. **Step 2**: Apply 5W+H to get specifics. **Step 3**: Map current state vs desired state. **Step 4**: Identify stakeholders and their perspectives. **Step 5**: Define boundaries (in/out of scope, constraints). **Step 6**: Disaggregate into segments if needed. **Step 7**: Try reframing from different angles. **Step 8**: Write clear problem statement. **Step 9**: Validate with stakeholders—do they agree? **Step 10**: Define success metrics. **The lesson**: Frame problems correctly using techniques: 5W+H framework (who, what, when, where, why, how), current vs desired state, jobs-to-be-done framing, constraint identification, stakeholder mapping, 'so what?' cascade, disaggregation and segmentation, hypothesis-driven framing, boundary questions, and problem reframing exercise. Avoid mistakes: stating solutions as problems, vague statements, accepting first framing, and individual blame. Use systematic workflow: gather complaint, get specifics, map states, identify stakeholders, define boundaries, disaggregate, reframe, write statement, validate, define success. Good framing transforms vague into specific, reveals root causes, opens solution space, and aligns teams. Time invested in framing saves exponentially more time solving right problems.
How do you know when you've framed a problem well enough to start generating solutions?
Well-framed problems pass specific tests—team alignment, clear success criteria, stakeholder agreement, and actionable scope indicate readiness to move from problem definition to solution generation. Tests for well-framed problems: Test 1 (The specificity test): Can you describe the problem in concrete, observable terms? Poor: 'User experience needs improvement' (vague). Good: '40% of mobile users abandon checkout at payment step, compared to 15% on desktop' (specific). If you can't be specific, need more investigation. Test 2 (The agreement test): Do all stakeholders agree this is the problem? If stakeholders have different views of problem, you're not ready. Need alignment first. Example: Engineering sees problem as 'technical debt.' Product sees problem as 'missing features.' Sales sees problem as 'pricing.' Not the same problem—need alignment before solving. Method: Write problem statement. Share with stakeholders. Ask: 'Is this accurate?' Iterate until agreement. Test 3 (The 'why it matters' test): Can you articulate why solving this problem is important? What's the business impact? User impact? Strategic impact? If you can't clearly state why it matters, either: Problem isn't actually important (don't solve), or you don't understand context well enough yet (keep investigating). Test 4 (The scope test): Is the problem bounded appropriately? Not too broad (unsolvable) or too narrow (trivial). Goldilocks scope: Specific enough to be actionable. Broad enough to matter. Example too narrow: 'Button on page 7 is wrong color' (trivial). Example too broad: 'Improve entire product' (unsolvable). Example right scope: 'Simplify onboarding flow to reduce abandonment from 40% to 20%' (actionable and meaningful). Test 5 (The success criteria test): Do you know what success looks like? Can you measure it? Example: Problem: Improve customer support quality. Success criteria: Response time under 4 hours. Resolution time under 24 hours. Customer satisfaction above 4.5/5. Ticket escalation rate below 5%. If you can't define success metrics, not ready for solutions yet. Test 6 (The root cause test): Have you identified underlying causes, not just symptoms? Ask: 'If we solve this, will the problem recur?' If yes, you haven't reached root cause. Example: Problem: 'Support volume high.' Symptom-level: Just need more agents? Root cause: Why is volume high? If due to product confusion, adding agents doesn't solve root cause. Test 7 (The constraint clarity test): Are constraints explicit? Budget limits, time limits, technical constraints, political constraints? If constraints not clear, solutions may be infeasible. Example: Problem: Scale infrastructure. Constraints: Can't exceed current budget. Can't hire more staff. Must maintain 99.9% uptime. Now solutions must work within these constraints. Test 8 (The reframe test): Have you tried framing problem multiple ways to ensure you're seeing it clearly? Try reframing from: Different stakeholder perspectives. Different levels of abstraction (tactical to strategic). Different time horizons (short-term vs long-term). If only considered one framing, might be missing better problem definition. Test 9 (The question test): Can the problem be stated as a clear question? Problem as question form forces clarity. Example poor: 'Users are having problems' (statement). Example good: 'Why do 40% of new users abandon onboarding at step 3?' (question). Question format suggests investigation paths. Test 10 (The team readiness test): Can team articulate the problem without looking at notes? If team members give different explanations, problem not well-framed yet. Need shared understanding. Method: Ask 3 team members independently: 'What problem are we solving?' If answers align, good framing. If divergent, need more alignment. When to move from framing to solution generation: Green lights (proceed to solutions): All tests above pass. Team aligned on problem. Stakeholders in agreement. Success criteria defined. Root cause identified (not just symptom). Constraints explicit. Scope appropriate. Yellow lights (need more work): Some alignment but not complete. Success criteria vague. Unsure about root cause vs symptom. Proceed cautiously, revisit framing as needed. Red lights (not ready): No team alignment. Stakeholders have conflicting views. Can't articulate why problem matters. No success criteria. Unclear if symptom or root cause. Don't proceed—will waste effort on wrong problem. The 'readiness checklist': Before generating solutions, complete this checklist: â–¡ Problem statement written and specific. â–¡ All stakeholders have reviewed and agree. â–¡ Success criteria defined and measurable. â–¡ Constraints explicitly identified. â–¡ Root cause analysis completed. â–¡ Scope boundaries defined (in/out of scope). â–¡ Team can articulate problem without notes. â–¡ 'Why it matters' is clear. If all checked, ready for solutions. If gaps, address them first. Common mistake: Premature solution generation: Trap: Feeling pressure to 'do something', jump to solutions before problem well-understood. Result: Solving wrong problem, wasted effort. Example: Team spends 3 months building feature. Launches. Doesn't solve problem. Why? Problem wasn't well-framed—built solution to what they thought problem was, not actual problem. Better: Invest 10-20% of project time in problem framing. Saves 80%+ of wasted execution effort. The lesson: Know problem is well-framed when it passes tests: specificity (concrete observable terms), agreement (stakeholder alignment), 'why it matters' (clear importance), scope (bounded appropriately), success criteria (measurable), root cause (not just symptom), constraint clarity (explicit limits), reframe (multiple perspectives considered), question format (clear question), and team readiness (shared understanding). Use readiness checklist before proceeding to solutions. Green lights: all tests pass, proceed. Yellow: some gaps, proceed cautiously. Red: major gaps, don't proceed yet. Resist pressure to jump to solutions prematurely—investing 10-20% of time in proper problem framing saves 80%+ of wasted execution solving wrong problems. Well-framed problem makes solution generation much more effective and efficient.
How do you reframe a problem that your team is stuck on or approaching incorrectly?
Reframing stuck problems requires stepping back to challenge assumptions, explore alternative perspectives, and question whether you're solving the right problem—use structured techniques to break out of current framing. Signs your team is stuck in wrong framing: Can't make progress despite effort. Proposed solutions feel unsatisfying. Solving same problem repeatedly. Team has strong opinions but no alignment. Simple problem feels overly complex. When you see these signs, time to reframe. Reframing techniques: Technique 1 (Question the question): Current framing is implicit question. Make it explicit, then challenge it. Steps: Write down current problem as question. Ask: 'Is this the right question?' 'What question should we be asking instead?' Example: Current: 'How do we add more features faster?' Challenge: 'Is more features the goal? Or is it user value? Market differentiation? Revenue growth?' Reframe: 'How do we increase user value with minimal feature complexity?' Different question = different solutions. Technique 2 (Reverse the problem): Instead of 'How do we achieve X?', ask 'How would we cause opposite of X?' Reveals constraints and hidden assumptions. Example: Current: 'How do we improve customer retention?' Reverse: 'How would we drive customers away?' Insights: Confusing product. Broken promises. Poor support. Unexpected charges. Reframe: 'What are we currently doing that drives customers away, and how do we stop?' Different perspective reveals actual problems. Technique 3 (Zoom in / zoom out): Change level of abstraction. Zoom in (tactical): Make problem more specific, narrower scope. Zoom out (strategic): Make problem broader, higher-level. Example: Current (medium): 'Sales team isn't hitting quotas.' Zoom in: 'Discovery calls not identifying customer pain points.' Zoom out: 'Go-to-market strategy not aligned with target customer.' Either reframing might reveal better problem definition. Technique 4 (Change stakeholder perspective): Reframe problem from different stakeholder's viewpoint. Example: Current framing (engineering perspective): 'How do we reduce technical debt?' Reframe (business perspective): 'How do we increase development velocity?' Reframe (customer perspective): 'How do we deliver more reliable product?' Different perspectives reveal different priorities and solutions. Technique 5 (The 'Jobs to be Done' reframe): Shift from solution-focused to outcome-focused. Ask: 'What is the user/customer trying to accomplish?' Example: Current: 'We need faster search functionality.' Reframe via JTBD: 'Users are trying to find relevant information quickly to make decisions.' Insight: Maybe search isn't only solution—better organization, recommendations, or predictive content might work better. Technique 6 (The 'What's the real problem?' cascade): Keep asking 'What's the real problem?' until you reach deeper issue. Example: Problem: 'Team is missing deadlines.' What's the real problem? Tasks taking longer than estimated. What's the real problem? Estimates are consistently wrong. What's the real problem? We don't understand complexity before committing. What's the real problem? No discovery phase before estimation. Reframe: 'How do we build adequate discovery into our planning process?' Deeper problem revealed. Technique 7 (The constraint reversal): Identify constraints, then ask: 'What if this constraint didn't exist?' Reveals if constraint is real or assumed. Example: Current: 'How do we improve product with current budget?' Constraint: Budget fixed. Reversal: 'If budget wasn't constrained, what would we do?' Answer: Hire specialized expertise. Reframe: 'Can we access expertise without hiring? Consultants, part-time, outsourcing?' Constraint reversal reveals alternative paths. Technique 8 (The time horizon shift): Reframe problem with different time horizons. Example: Current (short-term): 'How do we hit this quarter's revenue target?' Reframe (long-term): 'How do we build sustainable revenue growth over 3 years?' Different timeframe changes problem completely—short-term might focus on quick wins, long-term on fundamental business model. Technique 9 (The 'What would expert X say?' reframe): Ask: 'How would [domain expert, competitor, outsider] frame this problem?' Example: Current framing (internal): 'Our development process is slow.' Reframe: 'How would Toyota (lean manufacturing) frame this?' They'd ask: What's the value stream? Where's the waste? What's the bottleneck? Fresh perspective breaks current framing. Technique 10 (The adjacent possible): Look at adjacent domains or analogous problems for reframing ideas. Example: Current: 'How do we improve our customer onboarding?' Look at adjacent: How do video games onboard users? How do consumer apps? Insight: They use progressive disclosure, quick wins, guided tutorials. Reframe: 'How do we create progressive onboarding with early wins?' Analogies spark new framings. Facilitating reframing with stuck teams: Step 1 (Acknowledge being stuck): 'We're not making progress with current approach. Let's step back and reframe.' Permission to challenge current thinking. Step 2 (Make current framing explicit): 'How are we currently framing this problem?' Write it down. See it clearly. Step 3 (Challenge assumptions): 'What are we assuming? What if those assumptions are wrong?' List assumptions explicitly. Question each one. Step 4 (Generate alternative framings): Use techniques above to generate 3-5 different ways to frame problem. Don't evaluate yet—just generate. Step 5 (Evaluate framings): For each framing: Does this reveal new solutions? Does this feel more accurate? Does this align team better? Choose most promising reframing. Step 6 (Test new framing): 'If we frame it this way, what solutions emerge?' If new framing unlocks progress, adopt it. If still stuck, try another reframing. Example of successful reframing: Team stuck: 'How do we get users to use Feature X we built?' Stuck because: Feature adoption remains low despite marketing, onboarding improvements. Reframe attempt 1 (Zoom out): 'Do users even need Feature X?' Insight from research: Users solving problem differently—Feature X addresses problem they don't have. Real reframe: 'What problem are users actually trying to solve, and how do we help?' Investigation reveals: Users need Y, not X. Reframe unstuck team—now building right solution. The reframing mindset: When stuck, your framing is probably wrong. Be willing to question everything, including original problem definition. Best reframing often feels like 'wait, we were solving wrong problem entirely.' The lesson: Reframe stuck problems by questioning the question (challenge implicit framing), reversing the problem (ask how to cause opposite), zooming in/out (change abstraction level), changing stakeholder perspective, using 'Jobs to be Done' (outcome focus), cascading 'what's the real problem?', reversing constraints (question assumptions), shifting time horizons, asking 'what would expert say?', and looking at adjacent domains (analogies). Facilitate reframing by acknowledging being stuck, making current framing explicit, challenging assumptions, generating alternative framings, evaluating them, and testing new framing. Signs you need reframing: can't make progress, solutions feel unsatisfying, solving same problem repeatedly, no team alignment. Successful reframing often reveals you were solving wrong problem—be willing to question everything. Reframing is tool for getting unstuck when current problem definition isn't yielding progress.
What's the relationship between problem framing and solution quality, and how do you prevent biased framing?
Problem framing directly determines solution quality—narrow framing constrains solutions, biased framing leads to predetermined conclusions, and poor framing wastes resources solving wrong problems. Prevent bias through deliberate perspective-taking, assumption-testing, and structured reframing. How framing determines solution quality: Relationship 1 (Framing sets solution space): How you frame determines what solutions you'll consider. Narrow framing: 'How do we make our emails less likely to be marked as spam?' Solutions limited to: Email content changes, sender reputation, technical email settings. Broader framing: 'How do we improve communication with customers?' Unlocks: SMS, in-app messages, push notifications, customer portal, phone support. Framing opens or closes solution space. Relationship 2 (Framing reveals or hides root causes): Surface framing points to symptoms. Deep framing points to root causes. Surface: 'How do we reduce bugs?' Solutions: More testing, better developers. Deep: 'Why do bugs reach production? What system gaps allow this?' Solutions: Inadequate code review, unclear requirements, technical debt, deployment process. Depth of framing determines solution effectiveness. Relationship 3 (Framing affects effort allocation): How you frame determines what you invest in. Problem framed as: 'Support costs too high.' Solution focus: Reduce support costs (hire cheaper, outsource, automation). Problem reframed as: 'Customers need too much support—why?' Solution focus: Improve product (better UX, documentation, onboarding). Dramatically different investment priorities based on framing. Relationship 4 (Framing influences success metrics): How you frame defines what success looks like. Framing: 'How do we increase website traffic?' Success metric: Traffic volume. Framing: 'How do we increase qualified leads?' Success metric: Lead quality and conversion. Different success metrics = different solutions = different outcomes. Sources of biased framing: Bias 1 (Solution bias): Already have preferred solution, frame problem to justify it. Example: Want to build mobile app. Frame problem as: 'Users need mobile access.' Reality check: Do users actually need mobile? Or is desktop fine? Bias creates problem to match desired solution. Bias 2 (Confirmation bias): Frame problem in way that confirms existing beliefs. Example: Believe customers churn due to pricing. Frame: 'How do we make pricing more competitive?' Ignore: Other churn reasons (product fit, support quality, competitors). Framing focuses only on confirming hypothesis. Bias 3 (Availability bias): Frame based on recent, memorable information rather than comprehensive view. Example: Recent customer complaint about feature. Frame: 'We need to fix Feature X.' Reality: One complaint among 10,000 satisfied users. Not representative but recent = feels important. Bias 4 (Anchoring bias): First framing you hear becomes anchor, hard to reframe. Example: Executive says 'We have sales problem.' Team frames everything as sales problem. Reality: Might be product-market fit, pricing, positioning—not sales execution. Initial framing anchors thinking. Bias 5 (Perspective bias): Frame from single stakeholder's perspective. Example: Engineering perspective: 'We need to reduce technical debt.' Other perspectives ignored: Business needs features, customers need reliability, support needs documentation. One-sided framing. Bias 6 (Sunk cost framing): Frame problem to justify continuing current investment. Example: 'How do we make Project X successful?' (After investing 6 months). Reframe: 'Should we continue Project X or pivot resources?' Sunk cost prevents objective reframing. Techniques to prevent biased framing: Prevention 1 (Separate problem understanding from solution generation): Rule: No solutions during problem framing phase. Forces focus on understanding problem before jumping to answers. Method: Two distinct meetings—first meeting only frames problem, second meeting generates solutions. Prevention 2 (Multi-stakeholder framing): Gather perspectives from different roles before finalizing framing. Method: Interview: Customers, frontline teams, leadership, different departments. Synthesize: What do different perspectives reveal? Comprehensive: Framing that accounts for multiple views. Prevention 3 (Challenge assumptions explicitly): List assumptions embedded in framing. Question each assumption. Method: Write problem framing. Ask: 'What are we assuming here?' List assumptions. For each: 'What if this assumption is wrong?' Prevention 4 (Steel-man alternative framings): Before committing to framing, develop strongest alternative framings. Method: Current framing: [Your framing]. Alternative framing 1: [Different perspective]. Alternative framing 2: [Different level]. Alternative framing 3: [Different timeframe]. Evaluate: Which framing most accurate? Forces consideration of alternatives. Prevention 5 (Evidence-based framing): Ground framing in data, not opinions or hunches. Method: Claim: 'Users find product confusing.' Evidence: What specific data shows this? (Analytics, user research, support tickets). Framing: Based on evidence, not assumption. Prevention 6 (The 'What are we NOT seeing?' question): Deliberately ask what your framing might be missing. Method: After initial framing, ask: 'What perspectives haven't we considered?' 'What evidence contradicts this framing?' 'What would someone disagree about?' Surfaces blind spots. Prevention 7 (Reframe from opposing view): Deliberately frame problem from opposite perspective. Method: Your framing: 'How do we grow faster?' Opposite framing: 'How do we grow more sustainably?' 'How do we improve before scaling?' Opposite perspective reveals different priorities and assumptions. Prevention 8 (Use structured frameworks): Apply frameworks like 5Ws+H, Current vs Desired State, Stakeholder Mapping. Structure reduces bias by forcing comprehensive consideration. Prevention 9 (External review): Have someone not involved review framing. Method: Outside person reads problem framing. Asks: 'What assumptions do you see?' 'What's missing?' 'How else could this be framed?' Fresh eyes catch bias you don't see. Prevention 10 (Time delay and reflection): Don't finalize framing immediately. Method: Draft framing. Wait 24-48 hours. Revisit with fresh perspective. Ask: 'Does this still seem right?' Time reduces attachment to initial framing. Signs your framing is biased: Red flags: Solutions seem obvious from framing (solution bias). Only one way to frame makes sense (confirmation bias). Based on recent events or loud voices (availability bias). Designed to justify existing project (sunk cost bias). One stakeholder's view dominates (perspective bias). Can't articulate contrary views (lack of consideration). If you see these signs, revisit framing with bias-prevention techniques. The bias-checking ritual: Before finalizing problem framing: â–¡ Have we considered multiple stakeholder perspectives? â–¡ Have we listed and challenged our assumptions? â–¡ Have we generated alternative framings? â–¡ Is this grounded in evidence, not opinion? â–¡ Have we asked 'What are we NOT seeing?' â–¡ Would outsider see this differently? If any boxes unchecked, framing potentially biased. The lesson: Problem framing determines solution quality by setting solution space, revealing or hiding root causes, directing effort allocation, and defining success metrics. Prevent biased framing (solution bias, confirmation bias, availability bias, anchoring bias, perspective bias, sunk cost framing) through techniques: separate problem understanding from solutions, gather multi-stakeholder perspectives, challenge assumptions explicitly, steel-man alternatives, use evidence-based framing, ask 'what are we not seeing?', reframe from opposing views, use structured frameworks, get external review, and allow time for reflection. Signs of biased framing: solutions seem obvious, only one framing makes sense, based on recent events, justifying existing projects, single perspective dominates, can't articulate contrary views. Good framing is comprehensive, evidence-based, multi-perspective, and assumption-tested. Quality of framing directly determines quality of solutions—biased framing leads to suboptimal solutions regardless of execution quality.