Your riskiest belief deserves the cheapest test
Turn last week’s conversations into a clear bet, then design the smallest honest experiment that could prove you wrong.
Tonight you turn notes into a bet you can test
- Synthesise your conversations into themes, each backed by a count and a quote
- Score three different concepts on one scorecard and record why you rejected two
- Map your assumptions by importance and evidence across four kinds of risk
- Choose the single riskiest assumption and write it as a hypothesis
- Design an experiment with a threshold set first, using the cheapest honest MVP type
OUTPUT · Scored concepts + assumption map + Experiment Card in product/02-strategy.md
A pile of notes is not an insight
Notes
- “Sam said WhatsApp is chaotic.”
- Eleven pages of transcripts, read once
- The quote you liked best, remembered best
- Every comment weighted the same
Insight
- 4 of 6 tutors lost a booking in a message thread last month (illustrative)
- A pattern named in one line, with a count and a quote
- What people did, kept apart from what they said
- A finding that changes what you will do next
An insight is a pattern across people that changes a decision. One vivid quote is an anecdote.
Synthesis in five moves
- CAPTUREOne observation per note, with who said or did it. Keep their words, not your summary.
- CLUSTERGroup notes that describe the same thing. Move them freely; groups will change.
- NAMEGive each group a one-line name in the customer’s language, not a feature name.
- COUNTHow many people does each theme rest on? Write it as “4 of 6”.
- QUOTEPick one short quote per theme that a sceptic would accept as evidence.
If a theme has no count and no quote, it is still your opinion.
Ideation: three concepts, one scorecard
- THE JOBStart from the struggle, not a feature: tutors lose requests across channels
- THREE CONCEPTSShared booking link; assistant that reads WhatsApp; weekly-slot template, no AI
- ONE SCORECARDScore each on value to the user, effort, risk and evidence, from 1 to 5
- THE CHOICEPick the strongest bet and write one line on why it beat the others
- THE REJECTSRecord each rejected concept with its reason, so you can return to it later
Your first idea is a candidate, not the answer. Score three, choose one, and keep the reasons.
Claude Studio: synthesise with quotes, not guesses
I’m building [MY PRODUCT] for [MY USER]. Below are my notes from [NUMBER] customer conversations. I want to find the real patterns so I can choose what to test first, which is why every claim needs evidence. <notes>[PASTE NOTES]</notes> Give me 3–5 themes. For each: a one-line name in the customer’s words, how many conversations mention it (for example “3 of 5”), and one exact quote copied from the notes. Then list anything I seem to believe that the notes don’t support, marked “not in the notes”. If you’re unsure whether two notes belong together, say so. Done is a short table plus that list.
Check the response
- Every quote appears word for word in the notes
- Counts match the number of conversations
- Gaps are marked “not in the notes”
Four ways a product can fail
- DESIRABILITYDo they want it enough to change what they do today? TutorDesk: will parents use a link?
- USABILITYCan they work it out without help? TutorDesk: can a parent request a slot on a phone?
- FEASIBILITYCan you build and run it with your skills, time and Claude? TutorDesk: calendar sync?
- VIABILITYDoes the business sustain itself? TutorDesk: will tutors pay more than they cost?
Founders tend to test feasibility first because building feels like progress. Start where failure hurts most.
The assumption map: important and unproven first
- LISTWrite every belief that must be true, one per note: “We believe…”. Cover all four risks.
- IMPORTANCEPlace each one up or down: if this were false, would the product fail?
- EVIDENCEPlace it left or right: have you seen people do it, or only heard them say it?
- THE CORNERImportant and unproven sits top right. These are your leap-of-faith assumptions.
- PICK ONEChoose the one that would hurt most if wrong. Test it before you build anything.
You are not ranking what you care about. You are ranking what could sink you that you haven’t checked.
TutorDesk’s riskiest assumption
“Our riskiest assumption is that tutors want a better booking tool.”
“We believe parents will request lessons through their tutor’s link instead of a WhatsApp message.” If false, nothing else matters, and so far we’ve only spoken to tutors.
Ask
- Why is the weak version already partly answered?
- Who holds the evidence we’re missing?
- Which of the four risks is this?
- What would we expect to see if it were true?
MVP types: the cheapest test that is still honest
- CONCIERGEYou deliver the result by hand, openly, to a few people. Fits: is the outcome wanted?
- WIZARD OF OZIt looks automated, but a person does the work behind it. Fits: will they use it?
- FAKE DOORA button for a feature that doesn’t exist yet; you count clicks. Fits: is there interest?
- LANDING PAGEA page describing the offer, with a sign-up. Fits: does the promise attract them?
- PROTOTYPEA clickable mock-up people try with a task. Fits: can they work out how to do it?
Choose the cheapest type that tests your riskiest assumption, not the one closest to the product you imagine.
The Experiment Card
- HYPOTHESISWe believe [who] will [do what] because [why]. One behaviour, one group of people.
- TESTThe MVP type, who takes part, how many, and for how long.
- METRICThe one behaviour you’ll count. Something people do, not something they say.
- THRESHOLDThe result that counts as success, written down and shared before you start.
- DECISIONWhat you’ll do if you hit it, miss it, or land in between.
If no result could change your plan, it isn’t an experiment. It’s a launch with extra steps.
Set the threshold before you see the result
After two weeks: “7 of 20 requests came through the link. That’s quite promising!”
Written on day one: “Success if at least 3 of 5 tutors share the link and half of second-week requests use it. Under a quarter, we rethink.” Then we look.
Ask
- What does 7 of 20 mean under the rule we wrote?
- Why do numbers chosen afterwards always look good?
- Who should see the threshold before you start?
- What would make you stop the test early?
Claude Studio: a pre-mortem with extended thinking
Here is my Experiment Card for [MY PRODUCT]: <card>[PASTE EXPERIMENT CARD]</card> Imagine it is six weeks from now. The experiment has finished and I concluded the wrong thing: a false pass or a false fail. I want to find those failure stories now, so I can fix the design before I spend two weeks running it. Write the five most likely stories of how it went wrong, each with one change to the card that would prevent it. Rank them by likelihood. If a story depends on something you can’t know about my users, say so and tell me what I’d need to check. Done is five ranked stories and a revised card.
Check the response
- Each story names a specific way the result misleads
- Each fix is a change to the card itself
- Unknowns about users are flagged, not invented
Workshop: your assumption map and Experiment Card
Apply tonight’s methods to your own product. Leave with one assumption you can test this week and a card a stranger could run.
- Synthesise your logged conversations with Claude; check every quote against your notes (7 min)
- Score three concepts, one without AI, on one scorecard; record each reject’s reason (7 min)
- Map 8–12 assumptions across the four risks; write the riskiest as “We believe…” (10 min)
- Fill in the Experiment Card, cheapest MVP type first; set the threshold now (10 min)
- Swap cards with a partner: can they say which result would make you stop? (5 min)
Scored concepts, assumption map + Experiment Card in product/02-strategy.md
Gate: the Experiment Card
- Each theme shows a count (“3 of 5”) and a quote that appears word for word in the notes
- The map places at least eight assumptions across all four risks, by importance and evidence
- The chosen assumption sits in the important, unproven corner, and the card says why
- Three different concepts, one without AI, are scored on the same criteria; rejects keep a reason
- The hypothesis names one group and one observable behaviour; the MVP type is the cheapest test
- Threshold, end date and the decision for each result are written down before the test starts
HOMEWORK · Start the experiment this week; log results in product/evidence/ as they arrive, not at the end.
© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms