Thoughtful Execution (Spotify Hypothesis Tree)

A structured method for turning a product goal into a tree of insights, opportunities, hypotheses, and solutions that terminate in shipped experiments, not analysis. Built by Spotify's Growth org to fix "one goal, one idea" — teams jumping straight from a goal to a single favorite solution, shipping it, and having no way to backtrack why it failed: wrong design, wrong hypothesis, or wrong problem entirely.

The tree is a living document — it gets updated as experiment results come in, not built once and filed away.

Routing note: this skill answers "how do we reach an uncertain goal, validated by experiments" for product/software/tech/AI work, or whenever the user names the framework directly. It does not diagnose why something already happened — even in a product/software/AI context, "why did metric X change" is issue-tree's diagnostic mode. For a product problem with an already-confirmed root cause where you need an exhaustive, MECE set of fix pathways, use issue-tree's solution mode instead — its output can feed this skill's opportunity layer (see Step 3).

Step 0: Load the Prior Tree, If One Exists

This skill is a living document across sessions, not just within one — a tree built today should still be there when results come back next week. Before asking the user anything, silently check for a saved tree file for this goal (e.g. thoughtful-execution-<goal-slug>.md in the user's working/data folder — not the skill folder). If one exists:

• Load it and summarize its current state in one or two lines (goal, mode, how many hypotheses are proven/killed/open) rather than re-asking Steps 1–2 from scratch.
• Treat any new message as an update to that tree (new results, a new effort to place, a request to zoom in) rather than a fresh build.

If no saved file exists, this is a first run — proceed to Step 1 normally.

Save schema (used by Step 7 and updated by Step 8's living-tree loop): a markdown file with the pinned goal, the mode, the insights and their [assumption — verify] tags, the full tree (opportunity → hypothesis → solution) with each hypothesis tagged proven / killed / inconclusive / untested, and the experiment-plan table. Overwrite this file — don't append — each time the tree is updated, so it always reflects current state.

Step 1: Pick the Mode, Pin the Goal, and Ask What Only the User Knows

Determine which of three modes applies from the user's request. Ask only if it's genuinely unclear which mode fits — fold that into the single intake message below rather than asking it separately first.

• Mode A — Plan Forward. A goal exists, little else does yet. Build the tree top-down from scratch.
• Mode B — Map Ongoing Work. The project is already running; the user has current workstreams, experiments, or initiatives to place on a tree and read for gaps.
• Mode C — Unstick. The project feels stuck — effort is going in, the metric isn't moving, and the team needs to see what's exhausted versus untouched.

State the sharpest working version of the goal you can from what's given — one measurable metric with a target and timeframe (weak: "improve onboarding"; strong: "increase completed sign-ups by 15% this quarter") — it gets confirmed or corrected by the questions below anyway.

Ask everything in one message. A tree built without the team's own knowledge is a plausible guess dressed up as a plan. Before building anything, send one numbered question block covering whichever apply:

1. Confirm or correct the working goal (metric, target, timeframe).
2. (Mode B/C only) List current efforts — workstreams, experiments, features in flight.
3. What data, research, or user feedback already exists relevant to the goal?
4. (Mode A only) Is there a solution you already have in mind? (See the pet-idea guard below — it won't be the only branch, but naming it now saves a round-trip.)

End with an explicit escape hatch:

Answer what you can — or reply "proceed with assumptions" and I'll build a first-draft tree with every gap clearly flagged.

Wait for the user's reply before doing anything else in this skill. This replaces asking the goal, the efforts list, and the insights question as separate back-and-forths — one round trip, not three.

Pet-idea guard: if the user names a solution already in hand, do not let the tree collapse to one branch. Place it as a single solution leaf under a stated hypothesis (Steps 4–5), and build the rest of the tree — other opportunities, other hypotheses, other solutions — around it.

Step 2: Process the Answer and Tag Assumptions

Take whatever came back from Step 1's intake message — full, partial, or "proceed with assumptions" — and use it to finalize the goal and insights going into Step 3.

Anti-paralysis rule: thin or missing insights are normal — do not stall waiting for perfect data. Use benchmarks against similar products, a quick expert evaluation, or an explicit assumption.

Tag every assumption. Anything not confirmed by the user's answer — an inferred insight, a guessed opportunity, a filled gap from "proceed with assumptions" — gets tagged [assumption — verify] directly on the node it affects, so it stays visible instead of blending into confirmed facts. This is what the assumption-validation loop (Step 8) resolves.

Step 3: Map the Opportunities ("Survey the Mountains")

Mode A: From the insights, derive 3–5 distinct opportunities or problems — different "mountains," each requiring its own approach. For each, estimate:

• Height — potential impact on the goal metric if solved
• Difficulty — effort/feasibility to address

Recommend which mountain to climb first (highest height ÷ difficulty), or whether the scope needs splitting into a fresh, more detailed tree for just one opportunity.

If the user is handing off pathways already decomposed by issue-tree's solution mode, use those directly as the opportunity layer instead of re-deriving them from insights.

Checkpoint — wait for confirmation before Step 4. Present the mountains with their height/difficulty and your recommendation, then ask:

I'd recommend climbing Mountain [N] — [name] first (highest impact ÷ effort). Reply with a different number to choose another, or "confirmed" to proceed.

Choosing which mountain to climb is the single biggest strategic call in this framework — don't let the model make it unilaterally. Wait for the reply before generating hypotheses, solutions, and an experiment plan for a mountain the user might not have picked.

Mode B: Place each ongoing effort at its proper leaf in the tree (opportunity → hypothesis → solution), inferring the layers above an effort where the user hasn't stated them. Then read the assembled tree for:

• Orphans — efforts tracing up to no stated hypothesis or opportunity ("why are we building this?")
• Crowded branches — multiple efforts testing the same hypothesis while other opportunities sit untouched
• Missing layers — a solution in flight with no stated hypothesis, meaning a failure won't be interpretable later

Flag each finding explicitly in the report (Step 7).

Mode C: Same placement as Mode B, plus mark each branch:

• Exhausted — multiple solutions already tried against the hypothesis; treat it as effectively tested
• Untouched — opportunity identified but no hypothesis or solution attempted yet

Recommend the move: keep iterating a promising-but-untested branch, or abandon an exhausted mountain and climb the next one.

Step 4: Generate Hypotheses

For the chosen opportunity (or opportunities), generate a minimum of 2 hypotheses — going wide before narrowing is the point of the framework. Use a fixed, testable format:

We believe that [change] will cause [outcome] for [segment], measured by [metric].

A single hypothesis per opportunity is a red flag — if you can only think of one, the opportunity probably needs more insight before it's ready. Ask the user one targeted follow-up question about that specific opportunity rather than forcing a second hypothesis that isn't real; wait for their answer, then continue.

Step 5: Design Multiple Solutions per Hypothesis

For each hypothesis, design a minimum of 2 solution executions — at least one incremental, at least one bolder. Never test a hypothesis with a single design.

Rule to enforce explicitly: a hypothesis is never killed by one failed solution. If a solution underperforms, that disproves the execution, not necessarily the hypothesis — another design may still prove it.

Step 6: Build the Experiment Plan

Convert solutions into a table, one row per solution:

Rules for filling it in:

• Method — prefer cheap qualitative tests (card sorting, usability tests, rapid surveys) before expensive A/B builds; note which solutions can be qualitatively pre-screened.
• Decision rule — state what result proves or kills the hypothesis before running anything. No post-hoc interpretation.
• Sequencing — order rows by learning-per-effort, not by which idea is most exciting.

Step 7: Render the Report

Preferred: one self-contained HTML page. Assemble the goal, insights, opportunity mountains (with height/difficulty, or gap/exhaustion flags for Modes B/C), the hypothesis tree, solution leaves, and the experiment-plan table into a single HTML document.

Sections, in order:

1. Header — the goal, the mode (Plan Forward / Map Ongoing Work / Unstick), and any [assumption — verify] tags.
2. Opportunity mountains — cards or a ranked list with height/difficulty (Mode A), or the annotated tree with orphan/crowded/missing-layer flags (Mode B) or exhausted/untouched markers (Mode C).
3. Tree diagram — Goal → Opportunity → Hypothesis → Solution, nested visually (as in issue-tree's tree rendering), with the minimum-2 rule visibly satisfied (no hypothesis with a single child solution, no opportunity with a single child hypothesis, except explicitly flagged gaps in Modes B/C).
4. Experiment plan — the Step 6 table as a proper HTML table.
5. Next moves — the Step 8 menu.

Build requirements: fully self-contained (inline <style>, no external assets); theme-aware (prefers-color-scheme plus data-theme override); responsive with overflow-x: auto containers for wide elements; clean, professional styling — no decorative clutter.

House palette, set as CSS custom properties at :root and overridden under both @media (prefers-color-scheme: dark) and [data-theme="dark"]:

• Light: paper background #F7F7F4, charcoal ink #1B2430, deep forest green #2F6F5E as the primary accent (headers, borders, tags), one soft gold #C9A961 reserved for a single highlight only (e.g. starred leaves) — not spread across multiple elements.
• Dark: charcoal #1B2430 background, paper #F7F7F4 ink, a lightened forest green (e.g. #4E9484) as the accent so it still reads on a dark background, the same soft gold #C9A961 for the one highlight.
• Muted and understated throughout — no saturated brights, no gradients, no corporate-flashy color blocking.

How to render it: if the session has an Artifact-rendering tool available, load its design-guidance skill first if required, write the HTML to a file, and publish it. Use a stable title (e.g. thoughtful_execution_<goal_slug>) so re-renders update the same page.

Fallback: markdown/ASCII in chat. If HTML cannot be rendered, produce the same content directly in the response: an ASCII tree (Goal → Opportunities → Hypotheses → Solutions, flags/markers inline), then the experiment-plan table as markdown, then the next-moves list. State explicitly that this is the fallback and why.

Persist the tree: after rendering (HTML or fallback), write or overwrite the save file described in Step 0's schema so the next session can resume from here.

Step 8: Next Moves and the Living-Tree Loop

Close with a numbered menu the user can reply to by number:

1. Zoom in — build a fresh, more detailed tree for just one opportunity.
2. Bring results — paste experiment or test outcomes; I'll mark hypotheses proven/killed, prune or grow branches accordingly, and re-render the tree.
3. Validate assumptions — go check the [assumption — verify] tags (insights, opportunity sizing, anything guessed) against reality; come back with confirmations or corrections and I'll update only the affected opportunities/hypotheses and re-render — not rebuild the tree.
4. Diagnose instead — if the underlying cause of a problem isn't actually known yet and needs exhaustive analysis rather than experimentation, hand off to issue-tree's diagnostic mode to find it first.
5. Decide between validated options — once solutions have measured payoffs, evaluate them with expected-value-calculator.

Proceed only on the user's selection — wait for their reply.

When results come back (option 2) or assumptions get validated (option 3), this is the framework's defining behavior: update the tree, don't rebuild it. For results: mark each tested hypothesis proven, killed, or inconclusive; prune killed branches; if a hypothesis is proven, recommend iterating that branch further before jumping to a new opportunity. For validated assumptions: clear the tag where confirmed; where refuted, revise the affected opportunity/hypothesis/solution and re-check whether the minimum-2 rule (Steps 4–5) still holds for that branch. Either way, re-save the tree file (Step 0's schema) immediately after — the update must survive to the next session, not just this one.

Tone & Style

• Experiments over opinions: if a claim isn't yet tested, call it a hypothesis, not a fact, and name which row in the experiment plan would test it.
• Never let a tree collapse to one hypothesis or one solution — the minimum-2 rule is the mechanism that prevents "one goal, one idea."
• Keep insight-gap assumptions visibly tagged; don't let them silently become facts as the tree grows.
• Plain, direct language. This is a working document teams reference repeatedly, not a one-time report.

Edge Cases

• Immature / new product: keep the tree high-level and hypotheses focused on value proposition, not optimization. Bigger leaps are expected; optimization-level hypotheses come after the basics are validated.
• No experimentation infrastructure (no A/B testing tool): default Method to qualitative tests and simple before/after measurement; flag these rows as weaker evidence than a controlled experiment.
• A branch gets fully killed: don't keep iterating a dead hypothesis — move to the next opportunity mountain and say so explicitly.
• User provides both a goal and a known root cause: confirm which is actually true. If the cause truly is confirmed, hand off to issue-tree's solution mode instead (this skill starts from an uncertain path, not a confirmed one). If the "known" cause is really just an assumption, treat it as one hypothesis among several and proceed normally with Step 4.
• Mode B/C reveals no orphans or gaps: say so plainly — a clean read is a valid, useful finding, not a failure to find something.
• User wants to combine modes (e.g. map ongoing work, then plan forward from the gaps found): run Mode B/C first, then feed its flagged gaps into Step 3/4 of Mode A for the next round.
• User says "proceed with assumptions" at Step 1: build the full tree with every gap tagged [assumption — verify], and say plainly that this is a first-draft tree pending validation.