⏱️ 13 min read◆📊 Advanced◆🎯 Strategy & Decision-Making
Most problems do not get solved — they get managed. A recurring issue gets handled repeatedly without anyone stopping to ask why it keeps happening. A decision gets made based on whoever spoke most confidently in the meeting, with consequences nobody anticipated because nobody systematically examined the trade-offs. The difference between solving problems and managing them permanently is frameworks.
Quick Answer
Problem-solving frameworks are structured thinking processes that prevent blind spots, create shared language, and produce documented reasoning — not just conclusions. Claude becomes dramatically more powerful when frameworks are applied because it can execute the thinking process faster, more thoroughly, and more consistently than any individual can alone. This chapter covers five frameworks: Root Cause Analysis (recurring problems), Decision Matrix (multi-criteria choices), SWOT Analysis (strategic position), 5 Whys (fast diagnosis), and Pre-Mortem (risk surfacing before commitment).
A framework does not tell you the answer. It tells you the questions to ask, in the right order, so nothing important gets missed. Claude can execute these frameworks faster and more thoroughly than most teams can alone — but the frameworks must be applied properly to produce value.
What Are the Five Problem-Solving Frameworks in This Chapter?
Framework 1
Root Cause Analysis
For recurring problems — finds the cause rather than treating symptoms
Framework 2
Decision Matrix
For multi-criteria choices where stakeholders disagree
Framework 3
SWOT Analysis (Done Properly)
For strategic position assessment with cross-quadrant strategy
Framework 4
The 5 Whys
Fastest path from symptom to root cause — minutes, not meetings
Framework 5
Pre-Mortem Analysis
Assumes failure before it happens — surfaces risks while they can still be prevented
Why Frameworks Beat Intuition
Three reasons frameworks outperform experience-based gut decisions:
Frameworks prevent blind spots — Every person systematically overlooks certain dimensions. Frameworks are checklists for the mind, forcing attention to perspectives that get skipped naturally.
Frameworks create common language — When a team runs a SWOT, everyone knows what is being discussed. When the 5 Whys is applied, the conversation moves toward causes rather than symptoms.
Frameworks produce documentation — An intuition-based decision produces a conclusion. A framework-based decision produces a conclusion plus a record of how it was reached — invaluable when explaining the decision, when conditions change, or when reviewing what went wrong.
How Do You Apply Root Cause Analysis with Claude?
1
Root Cause Analysis
Use when the same problem keeps recurring
When to use
The same problem returns after being fixed
A fix worked temporarily but not permanently
Multiple related problems are occurring simultaneously
A significant incident or failure has occurred
I need to perform a root cause analysis on this problem:
PROBLEM STATEMENT:
[What happened, when, how often, who is affected, what the impact is]
KNOWN SYMPTOMS:
[What is observable and measurable]
CONTEXT:
[Recent changes, relevant history, what's different from normal]
Please conduct a systematic root cause analysis:
STEP 1: PROBLEM DEFINITION
Restate the problem precisely — specific, measurable, factual, no assumptions yet.
STEP 2: DATA GATHERING
What additional information would be needed for a complete analysis?
What data is available vs missing?
STEP 3: CAUSAL MAPPING
Map potential causes:
- Immediate causes (what directly caused the symptom?)
- Intermediate causes (what caused the immediate causes?)
- Root causes (what fundamental condition enables the problem?)
Use a cause-and-effect structure, not just a list.
STEP 4: ROOT CAUSE IDENTIFICATION
Which causes, if fixed, would permanently eliminate the problem?
Which are symptoms vs causes?
Rank by likelihood and impact.
STEP 5: CONTRIBUTING FACTORS
What conditions allowed the root cause to exist or persist?
(Process gaps, system weaknesses, human factors, environmental factors)
STEP 6: RECOMMENDATIONS
For each identified root cause:
- Short-term fix (contain the immediate problem)
- Long-term fix (address the root cause permanently)
- Prevention measure (stop it from occurring again)
STEP 7: VERIFICATION APPROACH
How will we know if the fix worked?
What metrics should improve and by how much?
What is the monitoring plan?
Real Example: Customer Churn Problem
PROBLEM: Customer churn increased from 3% to 7% monthly over the past quarter.
Known symptoms:
- Exit surveys mention "not getting value" most frequently
- Churn highest in months 2-3 after signup
- Enterprise customers churning at lower rate than SMB
- Support ticket volume increased 40% same period
Context:
- Launched new onboarding flow 4 months ago
- Hired 3 new customer success reps who joined 3 months ago
- Raised prices by 15% for new customers 6 months ago
Please conduct root cause analysis on this churn increase.
What this surfaces: not just "onboarding is broken" but the specific failure points, contributing factors (new CSM reps still learning, price sensitivity in SMB), and differentiated recommendations for short-term containment versus long-term fix.
How Do You Build a Decision Matrix with Claude?
2
Decision Matrix
Use when choosing between options with multiple criteria
When to use
Multiple viable options with different strengths
Stakeholders disagree on the right choice
Criteria feel conflicting (cheaper vs better vs faster)
The decision has long-term consequences worth examining carefully
A documented justification is needed for the decision
I need to choose between these options:
OPTIONS:
A) [Option A name and brief description]
B) [Option B name and brief description]
C) [Option C name and brief description]
CONTEXT:
[Situation, key constraints, timeline]
DECISION CRITERIA:
[List factors that matter — or ask Claude to suggest criteria]
Please build a decision matrix:
STEP 1: CRITERIA DEFINITION
Define and clarify each criterion. What does "good" look like for each?
Add any criteria that may be missing given the context.
STEP 2: WEIGHTING
Assign weights to criteria (must total 100%):
- Which criteria are non-negotiable? (eliminate options that fail these)
- Which are most important to the outcome?
- Which are nice-to-have vs essential?
STEP 3: SCORING
Score each option against each criterion (1-5 scale):
1 = Poor, 2 = Below average, 3 = Acceptable, 4 = Good, 5 = Excellent
Explain specifically why each option scores as it does — not just the number.
STEP 4: WEIGHTED TOTAL
Calculate weighted scores. Show the matrix in table format.
STEP 5: SENSITIVITY ANALYSIS
What if the weights were different?
Which criteria being more/less important would change the winner?
Are there options that dominate across most criteria?
STEP 6: RECOMMENDATION
What does the matrix indicate?
Are there qualitative factors the matrix doesn't capture?
What is the recommended choice and why?
What conditions would change this recommendation?
Real Example: Technology Stack Decision
Options:
A) PostgreSQL — relational, proven, team has experience
B) MongoDB — document store, flexible schema, good for rapid iteration
C) Cassandra — highly scalable, but steep learning curve
Context: Early-stage startup, 2 backend engineers, expected 100K users
in year 1, potentially 10M in year 3. Time-to-market matters more
than perfect architecture.
Criteria: development speed, cost at current scale,
cost/performance at 10M users, learning curve for team,
ecosystem maturity, schema flexibility.
Please build the decision matrix.
How Do You Run a SWOT Analysis That Actually Produces Strategy?
3
SWOT Analysis (Done Properly)
Specific, evidenced, with cross-quadrant strategy
The problem with most SWOT analyses: they produce obvious, generic observations — "our strength is great customer service," "our weakness is we are small" — and result in no actionable output. Done properly with Claude, a SWOT becomes a sharp strategic tool.
Three rules for a useful SWOT
Specificity: "Strong brand" is useless. "NPS of 72, 40% of new customers come from referrals, 3 industry awards in 2 years" is useful.
Internal vs External: Strengths and weaknesses are within your control. Opportunities and threats are in the environment.
Cross-quadrant strategies are mandatory: SO (strengths → opportunities), ST (strengths → threats), WO (fix weaknesses → opportunities), WT (protect against vulnerabilities). Without this, a SWOT produces four lists instead of a strategy.
Please conduct a rigorous SWOT analysis for:
SUBJECT: [Company / product / team / initiative]
CONTEXT:
- Industry: [Your industry]
- Stage/Size: [Early startup / Growth / Enterprise]
- Market position: [Leader / Challenger / Niche player / New entrant]
- Timeframe: [Next 12 months / 3 years]
AVAILABLE INFORMATION:
[Revenue, market share, customer feedback, competitive info, resources]
STANDARDS FOR THIS ANALYSIS:
STRENGTHS (Internal):
- Each point must be specific and evidenced, not generic
- Rate each: Sustainable competitive advantage / Temporary / Table stakes
- Flag anything competitors could easily replicate
WEAKNESSES (Internal):
- Be honest — this is where most analyses fail
- Rate each: Critical (must fix) / Significant (should address) / Minor (monitor)
- Distinguish fixable weaknesses from fundamental constraints
OPPORTUNITIES (External):
- Must be external market conditions, not just "we could do X"
- Rate by: Attractiveness (size, growth) × Accessibility (our ability to capture)
- Flag time-sensitive opportunities
THREATS (External):
- Must be external factors, not internal failures
- Rate by: Probability × Impact
- Distinguish industry-wide threats from company-specific ones
CROSS-QUADRANT STRATEGIES:
SO: How do our strengths position us to capture opportunities?
ST: How do our strengths help us counter threats?
WO: What weaknesses must we fix to capture key opportunities?
WT: What is our most vulnerable position and how do we protect it?
PRIORITY ACTIONS:
Based on cross-quadrant analysis, what are the top 5 strategic priorities?
How Do You Apply the 5 Whys with Claude for Fast Diagnosis?
4
The 5 Whys
Fastest path from symptom to root cause
Developed by Toyota, the 5 Whys is the fastest path from symptom to cause. Ask "why" five times in succession, each answer becoming the input for the next question. Simple in structure, powerful in what it reveals.
When to use
Quick investigation of a specific failure or incident
Understanding why a process broke down
Investigating a customer complaint
As a first step before a larger root cause analysis
Apply the 5 Whys technique to this problem:
PROBLEM: [State the specific problem or failure]
Instructions:
- Start with the problem statement
- Each "Why" answer should be specific and factual, not assumed
- Flag where the analysis enters assumption territory vs known fact
- If there are multiple possible answers to a "Why", branch the analysis
- Don't stop artificially at 5 if the root cause hasn't emerged
- Don't go past 5 if the root cause is clear earlier
After the 5 Whys:
1. Identify the root cause(s)
2. Note which answers were factual vs assumed (mark assumptions)
3. Identify what data would validate the assumed answers
4. Recommend the fix that addresses the root cause, not a symptom
Real Example — Worked Through
Problem: The weekly report was not sent to the board on Friday.
Why 1
The analyst responsible did not submit it on time.
Why 2
They did not know it was due on Friday — they thought Monday.
Why 3
The deadline was not in the task management system, only in an email from six months ago.
Why 4
There is no standard operating procedure for recurring deliverables.
Why 5
When the original process was set up, it was communicated verbally and never documented.
Root Cause
Lack of documented processes for recurring responsibilities across the team.
Fix: Not "remind people of deadlines" — but "implement standard operating procedures for all recurring deliverables." The 5 Whys moved from a personnel issue to a process issue in five steps.
How Do You Run a Pre-Mortem Analysis with Claude?
5
Pre-Mortem Analysis
Imagine failure before it happens — while you can still prevent it
A post-mortem analyses failure after it occurs. A pre-mortem runs before — it is a structured exercise where the team assumes the initiative has already failed and works backward to surface the reasons. It bypasses the optimism bias that causes teams to downplay risks during planning by shifting into failure mode, which makes risks far easier to see.
When to use
Before significant investments of time, money, or people
Before product launches or entering new markets
Before major organisational changes
Any time the cost of failure is high enough to justify advance planning
Please conduct a pre-mortem analysis for this initiative:
INITIATIVE: [What you're about to do — launch, build, implement, etc.]
PLAN SUMMARY:
[Brief description of what you're planning, timeline, key assumptions]
CONTEXT:
[Resources available, team, external dependencies, market conditions]
PRE-MORTEM EXERCISE:
Assume it is [12 months / end date] from now and this initiative
has failed completely.
STEP 1: FAILURE SCENARIO GENERATION
Generate 10-15 specific, concrete reasons why this failed. Include:
- Execution failures (did it wrong)
- Planning failures (planned the wrong thing)
- External failures (environment changed)
- Resource failures (ran out of time/money/people)
- Assumption failures (key assumptions proved wrong)
Be specific — not "poor execution" but "we underestimated the
technical complexity and the feature took 3x longer than planned,
consuming the budget before launch."
STEP 2: PROBABILITY × IMPACT RATING
For each failure scenario:
- Probability: Low (under 20%) / Medium (20-50%) / High (over 50%)
- Impact if it occurs: Minor / Significant / Fatal
STEP 3: HIGH-PRIORITY RISKS
Identify the top 5 risks (highest probability × impact)
STEP 4: MITIGATION STRATEGIES
For each high-priority risk:
- Early warning signal (how would we know this is materialising?)
- Prevention measure (what reduces the probability?)
- Contingency plan (if it happens anyway, what do we do?)
STEP 5: PLAN ADJUSTMENTS
Based on this analysis:
- What should change about the plan before starting?
- What assumptions need validation before committing?
- What should be monitored most closely once started?
How Do You Combine Multiple Frameworks for Complex Problems?
The most sophisticated problem-solving sequences frameworks based on the nature of the situation:
Sequence 1 — Recurring Problem
5 Whys → Root Cause Analysis → Decision Matrix (solution selection) → Pre-Mortem (on the solution)
Sequence 2 — Strategic Decision
SWOT Analysis → Decision Matrix → Pre-Mortem (on the chosen option)
Sequence 3 — New Initiative Planning
Pre-Mortem → Root Cause Analysis (of most likely failure) → Decision Matrix (for mitigation options)
When the right framework is unclear, ask Claude directly:
Here is the situation: [describe situation]
Given the nature of this problem, which framework(s) would be
most appropriate and in what sequence?
Briefly explain the reasoning, then proceed with the
recommended approach.
The Core Principle
Claude does not just produce the output of a framework — it can also suggest which framework to use, identify where a framework is being applied incorrectly, and flag when an analysis is entering assumption territory versus drawing on known facts. Describe the situation first; let Claude recommend the approach.
What Are the Most Common Mistakes When Using Problem-Solving Frameworks?
Mistake 1: Jumping to Solutions Before Understanding the Problem
❌ "We're losing customers. Let's improve the product."
✅ Run RCA or 5 Whys first. The answer might be pricing,
support, or onboarding — not the product at all.
Mistake 2: Treating Frameworks as Formalities
❌ SWOT with generic bullet points nobody debates
✅ Force specificity: every point needs evidence or data behind it
Mistake 3: Skipping Cross-Quadrant Analysis in SWOT
❌ Four quadrants filled, meeting ends, nothing actionable emerges
✅ Always complete SO/ST/WO/WT strategies — that is where the value lives
Mistake 4: Stopping the 5 Whys Too Early
❌ "Why did the report fail? Because John didn't submit it.
Solution: Remind John."
✅ Ask why five times → finds the process failure, not a person to blame
Mistake 5: Running Pre-Mortem After Commitment
❌ Pre-mortem after budget is approved and announcement is made
✅ Pre-mortem before major commitments — while plans can still change
Key Takeaways
Frameworks prevent blind spots — They force questions that would naturally be skipped
Root Cause Analysis for recurring problems — Treat causes, not symptoms, or the problem returns
Decision matrices force explicit trade-offs — Remove opinion and gut feel from consequential choices
SWOT requires specificity — Generic observations produce generic strategy; evidence makes it useful
5 Whys for fast diagnosis — Surfaces root causes in minutes, not meetings
Pre-mortem before commitment — Imagining failure surfaces risks while they can still be prevented
Combine frameworks for complex situations — Sequence them based on the type of problem
Assignment: Apply One Framework to a Real Problem
Beginner: Pick a recurring small problem in current work. Run the 5 Whys with Claude. See how deep the actual cause goes — it is almost always deeper than the first answer.
Intermediate: Run a decision matrix on a decision currently being faced. Weight the criteria first before seeing Claude's analysis, then compare. Where does the structured approach change the thinking?
Advanced: Run a pre-mortem on an initiative currently in planning. Identify the top 3 risks, build mitigation plans, and share them with the team before launch.
Reflection questions: Which framework revealed something that had not been considered? Where did the framework force more specificity than felt natural? How did having a structured output change how the problem or decision was communicated to others?
Frequently Asked Questions
The five frameworks are: Root Cause Analysis (for recurring problems — finds causes rather than treating symptoms), the Decision Matrix (for choosing between options when multiple criteria matter and opinions diverge), SWOT Analysis done properly (with specificity, evidence, and cross-quadrant strategy generation), the 5 Whys (the fastest path from symptom to cause, asking why five times in succession), and Pre-Mortem Analysis (assumes the initiative has already failed and works backward to surface risks before they materialise).
Use the 5 Whys for quick investigation of a single, specific failure — understanding why one process broke down, investigating a customer complaint, or diagnosing an incident before a larger analysis. Use Root Cause Analysis for recurring problems where multiple contributing factors are likely, where the problem has broad impact, or where a thorough investigation is needed including data gathering, causal mapping, contributing factor identification, and a structured verification approach. The 5 Whys is often a useful first step before root cause analysis — it identifies the right area to investigate before going deep.
Most SWOT analyses produce generic observations that lead to no action — phrases like "great customer service" or "strong team" that could describe any company. A useful SWOT requires specificity (every point must be evidenced with data or examples), honest assessment of weaknesses (the most commonly skipped part), and cross-quadrant strategy generation — SO strategies using strengths to capture opportunities, ST strategies using strengths to counter threats, WO strategies fixing weaknesses to access opportunities, and WT strategies protecting against the most vulnerable combination. Without the cross-quadrant analysis, a SWOT produces four lists instead of a strategy.
A pre-mortem assumes a future initiative has already failed and works backward to surface the reasons. Unlike a post-mortem, which analyses failure after it has occurred, a pre-mortem runs before commitment — while the plan can still be changed. It bypasses the optimism bias that causes teams to downplay risks during planning by shifting into failure mode, which makes risks much easier to see. A pre-mortem produces specific failure scenarios, probability and impact ratings, early warning signals, prevention measures, and contingency plans — before any of them are needed.
Yes — the most powerful problem-solving often sequences frameworks. For recurring problems, a common sequence is 5 Whys to identify the right area, then Root Cause Analysis for a thorough investigation, then a Decision Matrix to choose between solution options, then a Pre-Mortem on the chosen solution. For strategic decisions, SWOT Analysis followed by a Decision Matrix followed by a Pre-Mortem works well. When the right framework is unclear, describe the situation to Claude and ask which frameworks would be most appropriate and in what sequence.