charlieviettq Structured Problem Solving
Framework
IRON LAW: MECE or It's Not Structured
Every decomposition must be MECE:
- Mutually Exclusive: No overlap between categories
- Collectively Exhaustive: No gaps — all possibilities covered
"Revenue = New customers + Existing customers" is MECE ✓
"Revenue = Online + Enterprise + Growth" is NOT MECE ✗ (overlapping)
Core Tools
Issue Tree: Decompose a question into sub-questions, MECE at each level
"Why is profit declining?"
├── Revenue declining?
│ ├── Volume down?
│ │ ├── New customer acquisition down?
│ │ └── Existing customer churn up?
│ └── Price down?
│ ├── Discounting increased?
│ └── Mix shift to lower-priced products?
└── Costs increasing?
├── COGS up?
└── OpEx up?
Hypothesis-Driven Approach: Instead of exploring everything, state a hypothesis and test it
- Form an initial hypothesis ("Profit declined because churn increased")
- Identify what evidence would prove/disprove it
- Gather that specific evidence
- Refine or reject the hypothesis
- Repeat
Pyramid Principle (Barbara Minto): Structure communication top-down
- Lead with the answer: Start with the recommendation, not the analysis
- Group supporting arguments: 3-5 supporting points, MECE
- Order logically: By argument strength, chronologically, or structurally
- Detail only when asked: Each level provides more detail for those who want it
80/20 Rule: Focus on the 20% of analysis that drives 80% of the answer. Don't over-analyze secondary branches of the issue tree.
Problem Solving Process
- Define the problem: "The client's profit has declined 15% YoY. Why, and what should they do?"
- Structure with an issue tree: MECE decomposition of possible causes
- Prioritize branches: Which branches are most likely to contain the answer? (80/20)
- Form hypotheses: "I believe the primary cause is..."
- Gather evidence: Test each hypothesis with data
- Synthesize findings: What does the evidence say?
- Recommend: Present using the Pyramid Principle (answer first)
Output Format
# Structured Analysis: {Problem}
## Problem Statement
{One sentence, specific and measurable}
## Issue Tree
{MECE decomposition — text or visual}
## Hypothesis
{Initial hypothesis with rationale}
## Evidence
| Branch | Hypothesis | Evidence | Verdict |
|--------|-----------|---------|---------|
| {branch} | {sub-hypothesis} | {data found} | Confirmed/Rejected |
## Synthesis (Pyramid Structure)
**Recommendation**: {answer first}
**Supporting Arguments**:
1. {argument 1 with evidence}
2. {argument 2 with evidence}
3. {argument 3 with evidence}
## Next Steps
1. {action item}
Examples
Correct Application
Scenario: "Why is our food delivery app losing market share?"
Issue tree (MECE):
Market share declining
├── Our growth slowing?
│ ├── New user acquisition down?
│ │ ├── Marketing spend reduced?
│ │ └── Conversion rate dropped?
│ └── Existing user activity down?
│ ├── Order frequency declining?
│ └── Users churning?
└── Competitors growing faster?
├── New entrant capturing share?
└── Existing competitor accelerating?
Hypothesis: "Existing user activity is down because order frequency declined after the delivery fee increase." Evidence: Order frequency dropped 22% in the month after fee increase. ✓
Pyramid: "Reverse the delivery fee increase for high-frequency users. Order frequency dropped 22% post-increase, and 60% of lost orders came from users who ordered 3+/week. A loyalty tier with waived fees for frequent users would recover an estimated 15% of lost share at a cost of NT$X/month."
Incorrect Application
- Issue tree: "Revenue problem: Online, Marketing, Customer Service" → Not MECE (overlapping categories, not exhaustive). Violates Iron Law.
Gotchas
- MECE is hard in practice: Perfect MECE is aspirational. Get as close as possible and note where categories blur. "Good enough MECE" beats "perfect but took 3 days."
- Hypothesis-driven ≠ confirmation bias: The hypothesis is a starting point to guide investigation, not a conclusion to defend. If evidence contradicts it, change the hypothesis.
- The Pyramid Principle feels counterintuitive: People naturally want to tell the story chronologically (problem → analysis → conclusion). Audiences want the answer FIRST, then the supporting evidence. Lead with the recommendation.
- Structured ≠ slow: Spending 30 minutes structuring the problem saves hours of unfocused analysis. The structure IS the speed.
- Know when to stop: Analysis has diminishing returns. If you have enough evidence to make a confident recommendation, stop analyzing and recommend.
References
- For issue tree templates by problem type, see
references/issue-tree-templates.md - For Pyramid Principle writing guide, see
references/pyramid-principle.md