The Doubt List
The Living Brainstorm · what has to be true, and which one kills you
Testing
Every idea rests on beliefs. Most of them are fine. One or two will kill you, and the whole job is finding which. This page is the layer between deciding what to build and building it, the part almost everyone skips, because listing what might be wrong feels like a detour when you're certain.
Adapted from chapters nine and ten of Teresa Torres's Continuous Discovery Habits, credited as inspiration. Torres writes for in-house product trios with a running product and an assigned outcome; this is reshaped for pre-launch and solo work. The vocabulary is Robert's. Nothing is reproduced from the source.
01
Test the doubts, not the idea
"Does this idea work?" is a question you can only answer by building the thing, which is why so many people build the thing to find out. Break the idea into the specific beliefs holding it up and each one becomes answerable this week, for almost nothing.
✕ The idea as the unit
"Will the inventory sync product work?"
answerable in 6 months · costs the build
✓ The doubt as the unit
"Will a warehouse manager hand over their stock export to a stranger?"
answerable Thursday · costs three calls
The reframe
The doubt is the unit
An idea is untestable. The beliefs under it are testable, individually, and cheaply.
If the only way to test it is to build it, you haven't broken it down far enough.
Yours: building as the test is the most expensive habit in product work. Name it when you see it.
02
The five tests
Every doubt is one of these five. Naming which one it is tells you how to test it, because the type and the method are the same decision. Want gets skipped most and kills fastest; fail Want and every other answer was wasted effort.
WantDo they actually want the outcome this produces?The most skipped, the most lethal. Test with conversations and money, never with a demo.
CanCan they actually use it?Find it, understand it, finish it, remember it exists next Tuesday.
BuildCan we actually make it, at quality, with what we have?Test with a spike, not a product.
WorthDoes it pay for itself?Margin, cost to serve, cost to acquire, whether the price holds. See The Number.
HarmWho does this hurt, and who's left out?Ask it out loud even when nobody asked you to.
Five tests
Type decides method
Want, Can, Build, Worth, Harm. The category tells you the test.
Fail Want and nothing else mattered. Test it first, always.
Yours: Harm is not a compliance checkbox. It's the brake on habit-forming design, and it's what lets the rest be believed.
03
The Harm questions
The ones worth asking out loud, in the room, before the build. Engagement and compulsion are the same metric seen from two moral positions, and the honest move is to say which one you're building.
1 What data are you collecting, and do they know?
2 If they fully understood how you'd use it, would they still be fine with it?
3 Does this get more valuable to you the more compulsively it's used? Is that good for them?
4 Who's designed out, no money, no time, no stable housing, bad connectivity, no reason to trust you?
5 Does this expose someone who needed to stay anonymous?
Question three is the brake on The Itch. Both live in the same system on purpose.
Harm
Name which one you're building
Engagement and compulsion are one metric and two moral positions.
Nobody asks you to run this test. Run it anyway.
Yours: the honest caveat, applied to your own product instead of your own claims.
04
The Walk-Through
Assume the thing already exists and works. Now write every step every person has to take for anyone to get value from it. Every place you wrote "they" followed by a verb is a doubt. It's mechanical, it takes fifteen minutes, and it surfaces the ones nobody would have volunteered.
01They hit a stock problem and think of usWant · Can
02They find the export in their warehouse systemCan
03They're willing to hand it overWant · Harm
04Our parser handles their formatBuild
05They act on what we show themWant · Worth
5 steps → 8 doubts, and step 03 is the one that ends the company
Walk-Through
Every verb is a doubt
Assume it shipped. Map what has to happen. Flag each step by type.
Name every actor, not just the buyer. Two-sided products fail on the side you forgot.
Be literal. "They understand what it's for" is a real step and a real doubt.
05
The Autopsy
Say it out loud: it's a year from now and this failed completely. Past tense, not conditional. That single grammatical switch is the whole trick; certainty about the outcome frees people to explain it, where the conditional invites polite hedging.
"Why might this fail?"
Adoption could be slower than we hope.
There may be some technical risk.
Competition is always a factor.
"It failed. Why did it?"
Warehouse managers never got approval to share the export.
The three formats we supported covered a fifth of the market.
Ops teams already had a spreadsheet that was good enough.
Autopsy
Past tense, not conditional
Ten minutes. Alone first, then compare.
Alone first is not a formality; group-first collapses to the loudest voice in the room.
The conditional gets you hedging. The past tense gets you the list.
06
The Kill Grid
You'll have thirty doubts and time to test four. Sort them on two axes: does the product die if this is false, and do you actually know or are you guessing. Only one quadrant is worth your week.
You have evidence
You're guessing
Fatal
Watch itSafe today. Re-check when the market moves.
Test this →The only quadrant that earns your week.
Survivable
IgnoreKnown and harmless.
Park itUnknown but it won't kill you. Later.
Within the top right, rank by cheapest to disprove. You want the fastest available no.
Kill Grid
Stakes × what you know
Test high-stakes, low-evidence. Nothing else.
The trap is the top left. Evidence feels like momentum, and confirming what you knew is the most comfortable way to learn nothing.
Yours: rank by cheapest to disprove, not by most interesting.
07
Design for the no
Before you run anything, write down the result that would make you stop. If no possible outcome would change the plan, you're not running a test; you're running a demo, and it's cheaper to skip it and admit you've already decided.
| Doubt type | Cheapest real signal | Not this |
|---|
| Want | a conversation, a pre-order, a deposit | a demo they said they liked |
| Can | one person touching a paper sketch | a survey about usability |
| Build | a two-day spike on the risky part | the whole architecture |
| Worth | a spreadsheet and a price conversation | waiting for real revenue |
| Harm | asking the people who'd be affected | asking your own team |
→ Write the decision rule first: what fraction, of how many, doing what, means go.
→ Five people this week beats fifty next quarter. Speed fights your own escalating commitment.
Test design
Write the no in advance
Match the test to the doubt type, not to your appetite for building.
If it takes six weeks it isn't a test; it's the thing.
Yours: the rule gets written before. Results come in soft, and a bar you can move is not a bar.
08
Ways this goes wrong
Each of these looks like discovery from the outside. That's what makes them expensive; they're productive-looking ways to learn nothing.
Assumption theatre
Listing forty doubts and testing the four that were already safe.
The unfalsifiable test
No result would have changed anything. It was a demo wearing a lab coat.
Confirming
Recruiting the people who already agreed, then calling the result a signal.
Skipping Harm
Nobody asked, it's awkward, and it's the one that ends up in public.
The MVP as the test
Six weeks of building to answer a question three calls would have settled.
Moving the bar after
Results come in soft, the threshold quietly relaxes, everyone agrees it's promising.
Anti-patterns
Productive-looking failure
Discovery that can't produce a no isn't discovery.
The test: name the result that would stop you. If you can't, you've decided.