Riskiest Assumption:How to Find It Before You Build

How to find your riskiest assumption: list what must be true for the idea to work, rank each by how much it would hurt to be wrong, and test the top one first. It is usually "does anyone care", not "can they use it".

How to find your riskiest assumption

You already test things. The trouble is which thing you test.

Left alone, you'll test whatever is easiest or most fun to check. For most builders that means usability. Can people work out the interface? Does the flow make sense? It's comfortable, it's measurable, and you get a clean answer by Friday.

Meanwhile your riskiest assumption, the one that could kill the whole idea, sits untouched. Does anyone actually care about this problem? That one is uncomfortable and decisive. It tends to get answered at launch, when the answer is most expensive.

So the skill isn't testing. It's choosing. Here is the method, in three moves.

Move one: write down what must be true

Take any idea you're excited about. A new product, a pricing change, a second offer, a new audience. Now finish this sentence as many times as you can: "This only works if..."

Be rude to yourself. You'll find assumptions you never knew you were making. Typical ones sound like this:

• People have this problem, and it bothers them enough to act.
• They'll change what they currently do.
• They'll understand what you're offering.
• They'll pay for it.

Say you sell a productised audit and you're thinking about a self-serve version. Your list might include: buyers will accept a report with no call, they'll trust it from someone they haven't met, they'll pay a lower price without expecting the same attention, and the version you build won't eat your existing audit sales. Four assumptions. Nobody mentioned the interface.

That's the point of the exercise. The list shows you the idea is a stack of bets, and you've only been checking one.

One more archetype, from the other side. Say you run a small paid community and you're tempted to add a premium tier. The list: members want more than they get now, enough of them want it to be worth running, they'd pay extra rather than expect it inside the current price, and you can deliver it without burning your weekends. The fourth is the only one you can check by thinking. The other three need other people.

That split matters. Some assumptions you can settle at your desk. The dangerous ones almost always live outside your head.

Free guide · 21 pagesDiscovery and delivery, one person.The Dual-Track Playbook: how to keep discovering while you keep building.Get the free guide →

Why your gut picks the wrong one

It isn't laziness. It's comfort.

Testing usability gives you a result you can act on. Testing whether anyone cares gives you a result you might not like. So without a rule, you drift to the first. You tell yourself you're being practical.

The ranking step exists to take the choice out of your mood. You write the list, you sort by damage, and the top item wins even when you'd rather it didn't. Treat that top item as a small piece of bad news you're volunteering to hear early.

There's also a tie to what you're trying to achieve. Discovery that floats free of any goal becomes curiosity. Hang each assumption off the outcome you want this quarter. If an assumption wouldn't change whether you reach it, it's not the riskiest one, however interesting it feels.

Move two: rank by damage, not by interest

Now sort the list. Not by which is most interesting. Not by which you can test quickest. By one question: if I'm wrong about this, how bad is it?

Read the right-hand column again. The damage goes up as the comfort goes down. That isn't a coincidence. It's why people test the bottom row.

If you only have time to answer one question, answer the one at the top. Everything below it is academic until that one passes.

Move three: test the riskiest assumption and nothing else

Resist the urge to run three tests in parallel. One assumption, one test, one date.

Why only one? Because you're a person with a limited number of evenings, and a discovery track that tries to do everything becomes a research project. Pick the most dangerous assumption and design the cheapest thing that could change your mind. How to do that well is the subject of testing an idea cheaply before you build.

Before you start, ask yourself the real question. If this comes back negative, will I actually stop?

If the honest answer is no, skip the test. Build the thing. At least that's honest. A test you'd ignore is worse than no test, because it costs you an evening and hands you false confidence. That is the most common way discovery becomes theatre.

Where this goes wrong

Three traps catch nearly everybody.

First, writing assumptions that are really features. "People want a dashboard" isn't an assumption. It's a solution wearing a costume. The assumption underneath might be "they struggle to see where their time goes." Dig down until the statement is about the person, not the product.

Second, ranking by what you can control. You'll be tempted to rate the assumptions you're able to fix as low risk, because you can fix them. But the ones you can't fix, like whether anyone cares, are the ones that can sink everything. Risk is about damage, not about how much you can do about it.

Third, treating your own enthusiasm as evidence. You've been living with the idea. It feels obvious. That feeling tells you nothing about whether a stranger shares it. Start from the risk, never from the thing you already want to build, or the list turns into a justification for a decision you made last week.

Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →

A note on being a one-person business

There's no colleague to say "have we checked that?" You are the person who proposes the idea and the person who approves it. That is a conflict of interest with a very good salary.

So lean on the structure. The written list does the job a sceptical teammate would do. It asks the awkward question at the moment you're least inclined to ask it yourself. Keep it where you'll see it, and look at it before you open the editor, not after.

Do the ranking in one sitting, then leave it alone. Re-ranking the list every time you feel nervous is just another way of avoiding the top item.

What to do once you know your riskiest assumption

Three outcomes, all useful.

The assumption holds. Good. Move to the next one on your list, or, if the rest are cheap to fix, start building. Either way you now build on evidence, not on a hunch.

It fails. Also good, and more valuable than it feels. You just returned weeks of evenings to something better. Record it. Write what you learned so the idea doesn't wander back in six months with no memory of why you dropped it. Killing ideas is a skill of its own, and how to kill a feature idea deals with it properly.

It's unclear. That's information too. Decide with what you have, or name the single next test. Don't sit in it. Discovery has a hazard: it always feels responsible to learn a little more. Set a limit before you start.

Free guide · 21 pagesDiscovery and delivery, one person.The Dual-Track Playbook: how to keep discovering while you keep building.Get the free guide →

A quick sanity check before you commit

Before you spend the evening, tick these off in your head.

• I listed what has to be true, in plain words about the person, not the product.
• I ranked by damage if wrong, not by interest or convenience.
• The one I picked is the one that scares me a little.
• I know what result counts as a no.
• I've decided I will stop if I get that no.

If you can tick all five, you're testing the right thing. If one of them wobbles, fix that before you start. The session that sets up the test is worth more than the test itself, because it's where you stop lying to yourself.

And pair it with a regular rhythm. A riskiest assumption found once is a nice exercise. Found every cycle, it's the thing that keeps a dual track practice pointed at something real.

Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →

Frequently asked questions

How many assumptions should I list?

As many as you can find, then rank them. The list is only useful because the ranking forces a choice. You'll test one at a time, starting with the most damaging.

What if every assumption feels equally risky?

Ask which one, if wrong, makes the others irrelevant. That is nearly always whether anyone cares enough to act or pay. Start there.

Why not test usability first?

Because it is comfortable and measurable, which is exactly why people choose it. A usable product nobody wants is still a failure. Test the decisive question before the pleasant one.

Do I need to test more than my riskiest assumption?

No. Test the riskiest one, and only if a negative result would genuinely stop you. If it wouldn't, skip the test and build.

The full method, with the checklists, is in The Dual-Track Playbook, a free 21-page playbook.