Structured Problem Diagnosis

Part of the Problem → Solution → Communicate framework. Starts the Problem phase — diagnosing root causes before jumping to solutions.

Break problems into components before jumping to solutions. Adapted from Watanabe’s Problem Solving 101 for business and growth contexts.

Philosophy

Most teams skip straight from “something’s wrong” to “let’s try this fix.” The gap between symptom and solution is where diagnosis lives. Without it, you’re guessing.

This skill walks through a structured process: define the problem precisely, decompose it into testable parts, form hypotheses, identify what data you need, and isolate the root cause. It works for marketing problems, product issues, business performance gaps, or any situation where something is underperforming and you don’t know why.

Before Starting

Ask: “What’s the problem you’re trying to solve? What made you notice it?”

Clarify whether this is:

• A metric problem — something measurable is declining or underperforming
• A qualitative problem — something feels off but isn’t easily quantified
• A strategic problem — a gap between where you are and where you want to be

Step 1: Define the Problem

A well-defined problem is half-solved. Vague problems produce vague solutions.

The Problem Statement Formula

[X] is [current state] instead of [target state]

Examples:

• “Trial-to-paid conversion is 4% instead of 8%”
• “Monthly churn is 6% instead of 3%”
• “Organic traffic is 12K/mo instead of 25K/mo”

Questions to Ask

1. What specifically is underperforming? (Be precise — not “growth” but “new user signups from organic search”)
2. What’s the current baseline? (Exact number or best estimate)
3. What’s the target? (Where should it be, and says who?)
4. When did it start? (Was there a specific inflection point?)
5. How big is the gap? (Magnitude helps prioritize)

Output

A single, crisp problem statement with baseline, target, and gap size.

Step 2: Build a Logic Tree

Decompose the problem into its component parts using MECE (Mutually Exclusive, Collectively Exhaustive) principles. No overlaps, no gaps.

Choose Your Tree Type

Math Tree (Most Common for Metrics)

Decompose the metric into its mathematical components:

Revenue declining
├── Volume (transactions)
│   ├── Traffic
│   │   ├── Organic
│   │   ├── Paid
│   │   └── Direct/Referral
│   └── Conversion rate
│       ├── Landing page → signup
│       ├── Signup → activation
│       └── Activation → purchase
└── Value (per transaction)
    ├── Average order value
    └── Product mix shift

Building the Tree

1. Start with the problem statement at the top
2. Ask: “What are the 2-4 major categories this breaks into?”
3. For each category, ask: “What sub-factors drive this?”
4. Go 2-3 levels deep (rarely need more)
5. Verify MECE: Do the branches cover everything? Do they overlap?

MECE Check

• Mutually Exclusive: If I fix branch A, does that automatically fix branch B? If yes, they overlap — restructure.
• Collectively Exhaustive: Is there any possible cause NOT captured in the tree? If yes, add a branch.

See references/watanabe-framework.md for MECE principles and tree-building techniques. See references/logic-tree-examples.md for 4 worked examples.

Output

A visual logic tree (text-based or diagram) with 2-3 levels of decomposition.

Step 3: Develop Hypotheses

For each leaf node (or promising branch) of the logic tree, form a testable hypothesis.

Hypothesis Format

If [this cause is true], then [we’d expect to see this evidence], because [this mechanism explains it].

Examples:

• “If paid traffic quality dropped, then we’d see lower conversion from paid visitors specifically, because the targeting was broadened last month.”
• “If onboarding emails are being filtered, then we’d see lower open rates on day-1 emails, because the new domain hasn’t built sender reputation.”

Prioritize Hypotheses

Score each hypothesis on three dimensions:

Rank by total score. Focus on the top 3-5 hypotheses first.

Output

A ranked list of hypotheses in If/Then/Because format with priority scores.

Step 4: Data Requirements

For each prioritized hypothesis, define exactly what data would confirm or reject it.

Data Requirements Table

Questions for Each Hypothesis

1. What specific data point confirms this?
2. What specific data point rejects this?
3. Where does this data live? (Analytics tool, database, CRM, team member’s head)
4. Who owns this data?
5. How fresh does the data need to be?
6. Is this data currently available or does it need to be gathered?

Important

This step identifies what data you need and where it lives. It does NOT gather the data — that’s the user’s job. The skill should clearly flag what’s needed so the user can go collect it.

Output

A complete data requirements table with sources, owners, and availability status.

Step 5: Analyze & Identify Root Cause

Once the user has gathered data, walk through each hypothesis.

Analysis Process

For each hypothesis:

1. Present the evidence — What did the data show?
2. Verdict — Confirmed, rejected, or inconclusive?
3. If confirmed — How much of the gap does this explain?
4. If rejected — What did we learn? Does it point to a different cause?
5. If inconclusive — What additional data would resolve it?

Root Cause Statement

When you’ve identified the root cause(s), synthesize into:

The primary root cause of [problem] is [cause], evidenced by [data]. This explains approximately [X%] of the observed gap.

If multiple root causes:

Root Cause 1 (explains ~60% of gap): [cause + evidence] Root Cause 2 (explains ~25% of gap): [cause + evidence] Unexplained (~15%): [what’s still unknown]

Next Steps

After identifying root cause, suggest:

• Immediate action: What can be done now?
• Investigation needed: What requires deeper analysis?
• Handoff: Which skill to use next — typically mkt-initiative-planner (Generate mode) to brainstorm solutions

Output Summary

A complete diagnosis includes:

1. Problem Statement — X is Y instead of Z
2. Logic Tree — MECE decomposition of the problem
3. Hypotheses — Ranked If/Then/Because statements
4. Data Requirements — What data confirms/rejects each hypothesis
5. Root Cause Statement — The identified cause(s) with evidence and gap attribution

How to Work

• Don’t rush to solutions. The urge to fix is strong — resist it until diagnosis is complete.
• Ask questions at every step. The user knows their business better than you.
• Be honest about uncertainty. “We don’t know yet” is a valid answer.
• Keep the logic tree simple. 2-3 levels is usually enough. More depth adds complexity without clarity.
• If the user doesn’t have data for a hypothesis, don’t guess — flag it as a gap and move on.
• The goal is a root cause statement, not a comprehensive audit of everything.