Hypothesis-Driven Analysis Prompt: Structure Any Problem

You've got a problem that's too big to attack directly. Revenue's down, churn's creeping, a launch underperformed, and "let's look into it" turns into three weeks of scattered analysis that proves nothing. A hypothesis-driven analysis prompt fixes the front of that process: it turns the fuzzy question into a structured tree of testable hypotheses and a plan for which data settles each one.

This is the move consultants make on day one of a case. They don't boil the ocean. They break the problem into mutually exclusive branches, guess where the answer probably lives, and test the highest-leverage branch first. Most people skip straight to pulling data without that scaffolding, then drown in it.

The good news: that scaffolding is a prompt. The bad news is that almost nobody publishes the prompt. They publish essays about the method instead.

The gap: everyone explains the method, nobody hands you the prompt

Search this topic and you'll find excellent teaching content with one thing missing. The actual reusable prompt.

My Consulting Offer's hypothesis-driven approach guide is a solid explainer that walks through understanding the problem, building issue trees, stating hypotheses, and pivoting on data, using a worked case-study comparison. But, in its own structure, it offers no downloadable template or fill-in-the-blank prompt readers could apply to their own problem. It teaches why and how, then stops. CaseBasix's issue tree guide is the same shape: step-by-step methodology, the MECE principle, business scenarios like fast-food profitability and startup churn, and no copyable prompt that converts a problem into MECE hypotheses and an analysis plan.

So the queries "issue tree prompt" and "hypothesis-driven analysis prompt" return method articles, not the artifact. That's the gap. A prompt that does the decomposition (builds the tree, derives the hypotheses, names the data) is the thing that doesn't exist on page one. It's below.

What you can do with this prompt

• Break a vague business problem into a MECE issue tree in one pass
• Generate three to five testable hypotheses ranked by likely impact
• Get a data plan that names the exact metric or source for each hypothesis
• Catch overlap and gaps the tree creates (the model checks its own MECE)
• Decide which branch to test first instead of analyzing everything
• Turn a leadership "look into this" into a one-page analysis plan
• Reuse the same structure for churn, pipeline, cost, or launch post-mortems

Anatomy of the analysis prompt

The structure that makes this work: refuse to let the model jump to answers. Force the tree, then the hypotheses, then the data plan.

Variables  → {{problem_statement}}, {{context}}, {{known_constraints}},
             {{available_data}}, {{decision_deadline}}
Prompt     → Role: strategy analyst trained in hypothesis-driven problem solving.
             Step 1: build a MECE issue tree for {{problem_statement}}.
             Step 2: check the tree for overlap and gaps; fix violations.
             Step 3: derive 3-5 hypotheses from the branches.
             Step 4: for each, state what data confirms or kills it.
Output     → 1) The issue tree (nested bullets)
             2) A hypothesis table: | Hypothesis | Branch | Test (data needed) | Priority |
             3) "Test first:" one branch, with the reason.

The non-negotiable bit is step two. Most hypothesis prompts skip the self-check and produce a tree with overlapping branches — "marketing" and "pricing" listed separately when a pricing problem is a marketing problem, so you double-count and miss the seam between them. Telling the model to audit its own tree for MECE violations before deriving hypotheses is what separates a real analysis plan from a brainstorm.

Step-by-step usage

1. Write the problem as a question

{{problem_statement}} should be one sentence, framed as a question with a number in it where possible. "Why did net revenue retention drop from 112% to 98% last quarter?" beats "look into retention." A sharp problem statement constrains the whole tree.

2. Give it the constraints

Fill {{known_constraints}} and {{available_data}} honestly. If you can't query cohort data, say so — the model will build a plan around what you can actually test rather than an idealized one. A plan that needs data you don't have is a plan you won't run.

3. Run it and read the tree first

Read the issue tree before the hypotheses. If a branch is missing or two branches overlap, the hypotheses inherit that flaw. Fix the tree in a follow-up turn, then let it regenerate hypotheses.

4. Reprioritize the tests

The model ranks hypotheses by likely impact, but you know things it doesn't. Reorder the test plan based on what's cheap to check and what's politically live. Sometimes the lowest-impact hypothesis is the fastest to rule out, and ruling it out narrows everything.

5. Run the first test, then come back

Test the top branch. Bring the result back into the prompt as new {{available_data}} and let it re-tree. Hypothesis-driven work is a loop, not a one-shot.

Prompt-craft patterns for analytical output

Sequence the steps as hard gates. A loose prompt asks for "an analysis." A strong one numbers the steps and forbids skipping: build the tree, then audit it, then derive hypotheses. Models that get all four asks at once tend to jump to hypotheses and back-fill a thin tree. Numbered, gated steps keep the reasoning in order.

Do not state any hypothesis until the issue tree passes the MECE check.
If two branches overlap, merge or re-split them and show the corrected tree first.

Make the model name the data, not just the question. "Test this hypothesis" is useless. "Test: pull NRR by cohort for the last 4 quarters; if the dip is concentrated in one cohort, the hypothesis holds" is a plan. Force the output contract to include the specific data source or metric per hypothesis. In practice, Claude follows a multi-step gated contract like this more reliably across a long problem statement, while GPT-4o benefits from restating the "name the data" rule right before the output section.

Ask for one ranked first test. The output of analysis isn't a list — it's a decision about where to look first. End the contract with a forced "Test first:" line and a one-sentence reason. That single line is what turns the prompt from interesting into useful.

Variables you'll set

An opinion: the tree matters more than the hypotheses

Here's where this approach gets contrarian. Most people obsess over generating clever hypotheses and treat the issue tree as a warm-up. It's backwards. A weak, overlapping tree produces hypotheses that double-count and leave a blind spot, and no amount of clever guessing fixes a tree that doesn't cover the problem. A clean MECE tree, even with obvious hypotheses, guarantees you've at least looked everywhere that matters. Spend your editing time on the tree. The hypotheses fall out of a good tree almost automatically. And no, asking the model to "be more rigorous" doesn't fix a broken tree — fix the branches.

Getting started

1. Copy the prompt structure above into ChatGPT, Claude, or Gemini.
2. Write {{problem_statement}} as a single sharp question with a number.
3. Fill {{available_data}} so the plan only tests what you can check.
4. Run it and read the issue tree before anything else.
5. Fix any MECE violation in a follow-up, then regenerate hypotheses.
6. Reprioritize the test plan by cost and political heat.
7. For a version with the MECE self-check, hypothesis table, and re-tree loop already wired into the output contract, use the Hypothesis-Driven Analysis Playbook instead of rebuilding the gates each time.

If the problem you're analyzing is a decision rather than a diagnosis, the free Decision Pros & Cons prompt is a lighter starting point — and a fair test of whether you need the full playbook yet.

Structured thinking is the whole game here, and a prompt is just a way to make the structure repeatable. For the decision-doc side of analysis, see the PRD prompt for product requirements, and when the output needs to drive a roadmap, the product roadmap prioritization prompt takes ranked hypotheses and turns them into sequenced bets. Then go decompose something.