Test the Assumption Before You Build the Thing

You have an idea. Your team wants to build it. The plan is to ship a small version, put it in front of users, and see what happens. That feels smart. It feels like progress. But it is often the slow, expensive way to find out you were wrong.

Here is the trap leaders fall into. They treat the half-built product as the test. Building takes weeks. Code costs money. And when it flops, you still do not know why. The bet behind the idea rested on a few guesses, and one bad guess sank the whole thing. You could have found that guess in a week without writing a line of code.

The better path is simple to say and hard to do. Name your riskiest guess. Test that one thing cheap and fast. Then decide.

The product is not the test, the bet is

Most teams reach for the MVP too soon. The MVP was meant to learn cheaply, but it grew into a small product you still have to build. Thomas Nagels makes the case for a sharper tool, the Riskiest Assumption Test, which asks one question before you build: which single guess, if wrong, kills this idea?

Michael Storrs puts it plainly, that testing the assumptions behind an idea is faster and cheaper than building the product. Your product depends on a handful of things being true. Users want it. They can figure out how to use it. They will pay. Those are bets, not facts. Test the bets, not the shell around them.

Write down every guess your idea leans on

Before you can test the riskiest guess, you have to see all of them. Pull your team into a room and list every assumption behind the idea. Not the polished ones. The uncomfortable ones. "People will trust us with their money." "They will switch from the tool they already use." "They will find the value in the first minute."

The Carwow product team does this before they build a feature, listing every assumption a feature depends on, then scoring them. The point of listing is honesty. Half your team is carrying guesses in their heads that nobody said out loud. Get them on the wall so you can argue about which ones matter.

Score by damage, then attack the top one

A long list is not a plan. You need an order. The clean way is to score each guess two ways: how likely is it wrong, and how bad is it if it is wrong. High on both means it goes first. A guess that is probably true, or one that barely matters if false, waits.

Tobias Scharikow walks through turning a stack of guesses into ranked, testable hypotheses so a team knows which to test first. This is where leaders add real value. You are not the one running the test. You are the one making sure the team tests the thing that could sink the boat, not the thing that is easy to check.

Cheap tests beat clean ones

Once you know your riskiest guess, the test can be scrappy. Fernanda Garcia points to prototypes as fake, throw-away versions that let you test with real users before any code exists. Her most basic example is a flipbook: draw each screen in a notebook and turn the page to show it move. That is enough to learn if people can navigate your thing.

She splits early risk into three kinds worth naming. Market risk, nobody wants it. Usability risk, nobody can use it. Resource risk, you run out of cash before you find out. Discovery interviews handle the first. Prototypes handle the second. Testing cheap and early handles the third, because you spend days instead of months on a wrong bet.

The deep cut

The hard part is not the testing. It is admitting which guess scares you. Teams pick easy tests because a green result feels good and keeps the plan alive. Sandra Bermudez frames validation as the art of managing risk before you scale, and that word, managing, matters. You are not chasing proof that you were right. You are hunting for the one thing that could be wrong while it is still cheap to find out. If your test cannot fail, it was not a test. It was a comfort blanket.

Three questions for your team

• What single assumption, if it turns out wrong, would sink this whole idea? Put a name to it before anyone writes code or a spec.
• Can we test that assumption this week without building the product? If the answer is a prototype, an interview, or a fake door, do that instead of the MVP.
• Are we running a test that can actually fail, or one we already know will pass? If it cannot fail, pick a harder one.