How to Run an Experiment Assumption Sprint
A practical guide to surfacing hidden product assumptions, ranking them by risk, and designing cheap decisive tests.
Founder, Task Machine
An experiment assumption sprint is a short, structured pass over a product idea or plan to find the assumptions most likely to break it. The output is not a roadmap. It is a ranked experiment plan that says which risk matters most, what cheap test would change your mind, and what signal counts before the test starts.
The reason to run one is simple: teams often build around the assumptions they least want to inspect. A sprint creates a ritual for finding the load-bearing beliefs before implementation turns them into sunk cost.
Why hidden assumptions quietly cost you
Product discussions often stay at the feature level. The team debates scope, design, and timing while the real risk sits underneath: whether the customer cares, whether the workflow is usable, whether the business can support it, whether the team can build it, or whether the go-to-market path exists.
The cost appears later as rework. A product that should have been rejected becomes a prototype. A demand risk gets tested with a technical spike. A technical risk gets tested with a landing page. A polished demo wins internal approval but never measures the harsh truth.
What the manual process looks like
Done well, the sprint is a five-step ritual:
- Write the product idea or plan in plain language, including the target user and intended outcome.
- Surface assumptions from PM, designer, and engineer perspectives across eight categories: Value, Usability, Viability, Feasibility, Ethics, Go-to-market, Strategy, and Team.
- State each assumption as a falsifiable claim with confidence and what breaks if it is false.
- Prioritize the list on an Impact x Risk matrix, where Risk is
(1 - Confidence) x Effort. - Design tests only for High-Impact and High-Risk assumptions, with a pre-set pass, fail, or learn threshold.
That last constraint is what keeps the sprint useful. Testing everything is wasteful. Testing only the easy assumptions is theater.
What an agent can automate
The sprint has a fixed method and a lot of structured thinking, which makes it suitable for a PM agent:
- Surface assumptions broadly. The agent checks all eight categories rather than stopping at Value, Usability, Viability, and Feasibility. Ethics, go-to-market, strategy, and team risks are often where early ideas fail.
- Make assumptions falsifiable. It rewrites vague worries into claims that can be tested, with confidence ratings and failure consequences attached.
- Prioritize with a matrix. It sorts assumptions by impact and risk, then applies the quadrant verdicts: Proceed, Experiment, Defer, or Reject.
- Choose the right test family. Demand and willingness-to-pay risks become pretotypes with an XYZ hypothesis and skin-in-the-game signal. Technical, task, alignment, edge-case, or workflow risks become Proof-of-Life probes.
- Set the threshold first. Every test gets its metric and decision rule before it runs. Probes also get a disposal plan so throwaway artifacts do not become accidental product.
The agent proposes the tests. It does not run them until the human approves which ones are worth executing.
The guardrails that make it safe
The danger in experiment work is false confidence. A nice prototype, a favorable opinion survey, or a broad market report can feel like evidence while leaving the core risk untouched.
The safe shape is a workflow that writes the experiment log, self-critiques the plan, and then waits. The reviewer checks whether all eight categories were covered, whether only High-Impact and High-Risk assumptions earned experiments, whether the tests measure behavior rather than opinion, and whether the thresholds were set before the work starts.
Set it up in Task Machine
The Experiment & Assumption Sprint playbook installs the PM agent, the experiment log document, four product-risk skills, and the workflow that surfaces, ranks, designs, critiques, and approves the plan. Setup takes a few minutes. You need a Task Machine workspace and permission to install playbooks (workspace owners have it). No connected services are required.
1. Find the playbook
Open Playbooks in your workspace and search for "experiment assumption", or browse the Research category. The card shows the PM agent, one workflow, the experiment log, and the four skills behind the sprint method.
2. Preview what it installs
Preview & install shows the PM agent, the experiment log, and the workflow stages: surface assumptions, prioritize on the matrix, design decisive tests, self-critique, and approve. This playbook has no provider picker because it runs from the plan and context you attach.
3. Give the sprint its scope
Start setup asks for the riskiest assumption, the success metric, experiment ideas, and the sprint timebox. Use concrete language. For example, name the customer behavior you need to see, the threshold that would change the decision, and the timebox for the first probe.
4. Generate and review
Generate customized playbook turns the answers into the PM agent instructions, experiment log, and workflow prompts. Review the plan before installing. Confirm the workflow proposes tests, waits for approval, and records pass, fail, or learn criteria before any test runs.
5. Install
Install customized playbook creates the sprint workflow and experiment log. Two follow-ups arrive in your inbox: prepare the assumption experiment log with current bets and prior tests, then start Surface, prioritize, design, self-critique, approve. The first run ends with the prioritized plan waiting for approval.
What good looks like
A useful sprint leaves you with three artifacts:
- A ranked assumption list. The highest item is both high-impact and high-risk, not merely easy to test.
- A decisive test design. The method matches the risk type, and the threshold is set before execution.
- A disposal plan. Any throwaway probe has a planned end date so it does not become unowned production work.
Common questions
Should every assumption get an experiment? No. Only High-Impact and High-Risk assumptions should earn experiments. Low-risk assumptions can proceed or wait, and low-impact high-risk assumptions are often rejected.
What is the difference between a pretotype and a Proof-of-Life probe? A pretotype tests demand or willingness to pay. A Proof-of-Life probe tests whether a technical, task, alignment, edge-case, or workflow risk can survive contact with reality.
Can the agent run the experiment automatically? No. It proposes the experiment plan and waits for approval. The human decides which tests run.
What should go in the experiment log before the first run? Add current bets, prior tests, known assumptions, available channels, success thresholds, and decision rules.