Assumption mapping · Roko Platform Docs

Every plan rests on claims that nobody has checked. Assumption mapping puts those claims on the table, finds the one that would hurt most if it were wrong, and tests it for a day before the team spends a quarter on it. Use it before a large build depends on an untested claim.

Write every assumption as a claim that could be false. A question cannot be tested. "Do users want this?" is a question. "Suppliers will upload their tax form before an approver asks for it" can be tested.

Kinds of assumption

Kind	The question underneath	Example claim
Desirability	Do they want it?	Suppliers will register themselves instead of waiting for an invite.
Usability	Can they use it?	Suppliers can find the missing documents without help.
Feasibility	Can we build it?	SAP accepts new vendors through its API within one working day.
Viability	Should the business do it?	Finance will accept approval by email reply for audit purposes.

David Bland's assumption mapping groups usability with desirability. Cagan names it as a separate risk. Either works, as long as someone asks the question.

Most teams list desirability well, feasibility adequately and viability barely at all. Ask directly for the claims about the business: legal, cost, sales, support and brand. Also write down the claims nobody says out loud: that the problem is worth solving, that this team should solve it, and that now is the right time.

Ranking by risk and evidence

Place each claim on two axes:

Importance: does the plan fail if the claim is wrong, or does it need a small change?
Evidence: what do you know, as opposed to believe?

Matters more ↑

Decided

Important, with evidence. Build on it.

FSAP accepts new vendors through its API.

Test first

Important, no evidence. The plan fails if this is wrong.

DSuppliers will upload tax forms themselves.
VFinance will accept approval by email reply.

Safe

Minor, with evidence. Ignore.

FThe form works on a phone.

Watch

Minor, no evidence. Tempting to test because it is easy.

DSuppliers prefer a dark theme.

Strong evidence

Weak evidence →

DDesirability
FFeasibility
VViability

Plot each claim by how much it matters and how little evidence you have. Test the top right first. The letter names the kind of assumption.

Test only the claims that are both important and unsupported. An important claim with strong evidence is a decision already made. An unsupported claim that does not matter is a distraction, and teams test those because they are easy.

Challenge weak evidence. "We have talked to customers" is not evidence for a specific claim. Ask which customers, when, and what they did.

The smallest test

Design the smallest thing that could change your mind about the riskiest claim. Prefer tests in this order:

Existing evidence. Support tickets, analytics, sales notes, or a past interview.
People who already switched. A critical incident or switch interview about what they did.
A fake door or a manual version. A button that records interest, or a person who does the job by hand behind a simple front end.
A prototype. A Roko Platform prototype for a question about use, or a spike for a question about the build.
The smallest real build. Only when the first four cannot answer the question.

Write the pass mark before you run the test: which result makes you proceed, and which result stops you. A test whose pass mark you set afterwards always passes.

Claim:      Suppliers will upload their tax form before an approver asks for it.
Kind:       Desirability
Test:       Prototype session with 6 recent suppliers, flavor 1a (upload on step 2).
Pass mark:  5 of 6 upload without a prompt  -> keep the upload on step 2.
Fail mark:  2 or fewer                       -> move the upload to an approver request.
Owner:      Maya       Due: Friday

Ruling on the result

Record one of three verdicts: passed, failed, or inconclusive.

Passed or failed: write which claim moved from belief to evidence, and what the plan says now that it did not say before.
Inconclusive: the test was wrong, not the assumption. Redesign the test, and say what was wrong with it. Do not run the same test again with more effort.

The map is done when the plan has visibly changed or visibly survived.

Common mistakes

Mistake	Fix
Every assumption is about desirability	Ask what must be true about the business and the build
Claims are written as questions	Rewrite them as statements that could be false
The riskiest claim has no test	The team fears the answer. Test it first.
The pass mark appears after the result	The test proved nothing. Run it again honestly.
"We already know this"	Ask for the evidence: from when, and about which claim
Mapping before every change	The map is a tool for risky bets, not a gate for all work

Map assumptions with your agent

Ask your agent to map the assumptions in a plan. The platform gives the agent the four steps on this page over MCP, each with a completion test: surface the assumptions, rank them, design the cheapest test, and rule on the result.

PromptMap the assumptions in a planpaste into your agent

Map the assumptions in the change request for supplier self-registration. Write each one as a claim that could be false, sort them by kind, and rank them. For the riskiest claim, design the cheapest test with its pass mark.

Record the test as a product discovery or enabling discovery goal on the Roadmap, so that the work is visible next to the delivery it protects. See Discovery.