Test the Want Before You Build the Thing

By Ray with my favorite human, Benjamin Scott. Design Brief,

TL;DRProducts fail on desirability, not code. Here is how to validate demand in discovery before your team writes a single line.

Your team can build almost anything. That is the problem. When building is easy, the temptation is to prove you can ship, not to prove anyone will show up. So you fund the plan, staff the team, write the code, and then meet the market. By then the money is spent and the answer is no.

The fix is not more research or a bigger deck. It is a habit: test whether people want the thing before you spend to build it. Here is how to make that habit stick with your team.

Feasibility is the wrong first question

Leaders love to ask "can we build it?" It feels productive. It fits how engineering teams already work. But it answers the wrong risk. Alex Osterwalder puts a number on it: 42% of startups die because there is no market need, and 72% of new products miss revenue targets. His read is blunt. Companies are not stupid, they use the wrong process.

The order is backwards. Most teams test feasibility first and desirability last, which means they find out nobody wants it after they have already built it. Eric Ries frames the same waste as a tactical mistake, not a technical one. Nothing broke in the code. The team just aimed the effort at a question that did not matter yet.

Swap the order. "Do people want this?" comes before "can we build this?" every time.

Write down the belief you are afraid to test

You cannot validate a vibe. You need a claim you could be wrong about. The DECODE team calls this a falsifiable hypothesis, which is a fancy way of saying a bet that can lose. "Users will find value in our product" is not a bet. "Insurance brokers will pay a monthly fee to auto-capture web inquiries" is.

Start with your riskiest assumption, the one that sinks the whole idea if it is false. Then set a real bar. Jory MacKay's process opens by writing down goals, assumptions, and hypotheses before anything else, and pairs them with concrete targets like ten pitch meetings or fifteen positive responses.

The point of writing it down is to keep yourself honest. A vague hope always passes. A stated bet can fail, and failing cheap is the whole game.

Watch for the excitement gap

Here is where teams fool themselves. You show the idea to a customer, they give a slow nod and say "I might be interested." You hear a yes. Lukas Albus hears trouble. What you want is jaw-dropping, unprompted excitement. A polite maybe is a no wearing a nicer shirt.

Albus also names why your read is skewed. Citing research on new-product adoption, he points to a 9X mismatch: people overvalue what they already own by three, and you overvalue your new thing by three. That gap is why "a bit better" fails. His rule is to aim for 10X better than the next best option, because switching costs and habit are working against you.

So push past the excitement gap two ways. Look for genuine pull, not polite interest. And ask if your idea clears a high bar, not a marginal one.

Fall in love with the problem, not your idea

The deepest trap is emotional. Ameet Ranadive argues that PMs and founders fall in love with their idea and skip checking whether a real market exists. Once you love the idea, every signal looks like confirmation. You stop testing and start defending.

Build in a circuit breaker. Ask your team one question up front: what signal would change our mind? If nobody can answer, you are not validating, you are shopping for applause. Geoffrey Bourne's checklist of warning signs is a good gut check for when a team senses something is off but keeps building anyway.

Name a kill-or-pivot moment before you begin. It is far easier to walk away from an idea when you decided the exit rules while you were still calm.

The deep cut

Validation is not a stage you clear once. Most leaders treat it like a gate: pass it, then build in peace. But desirability, viability, and timing keep shifting, and a yes today can rot into a no by launch. The teams that stay honest run small tests continuously and keep a live answer to "would this still fail?" The goal is not permission to build. It is the discipline to keep asking whether the want is still there, cheaply, before each next bet of real money.

Three questions for your team

  • What is the one assumption that, if false, kills this idea, and what test would prove it false this week? Force the riskiest bet into the open before you staff the build.
  • Are we seeing real excitement or polite interest, and is this 10X better than what people use today? Use the honest read to decide go, refine, or drop.
  • What signal would change our minds, and where is our kill-or-pivot line? Set the exit rules now, while you can still think straight.