Tentativ
NB · Les på norsk

← Back to articles

27 September 2026 · 2 min read

Test the riskiest assumption first

Every idea rests on assumptions. Some of them get very expensive if they're wrong. Start with those.

Explore · Assumptions map

Importance ↑
littleEvidence →lots

Nothing in the corner yet. Drag the most important, least proven assumptions to the top left.

After David Bland. Drag the assumptions to where you think they belong.

Our name comes from the Latin tentare, to attempt. That's no accident. Most of our work is about finding out what works before being wrong gets expensive.

The most important habit we know is easy to say and hard to do: test the assumption that costs the most if it's wrong, and test it first.

Every idea rests on assumptions

A new service is a bundle of claims. People have this problem. They want to solve it this way. They understand the solution. We can build it. It pays off.

Marty Cagan splits product risk into four: value (will people want it?), usability (can they use it?), feasibility (can we build it?) and viability (does it work for the business?). It's a good checklist for finding your assumptions.

Sort them

Write the assumptions on sticky notes. Sort them along two axes: how important is it for the idea to succeed, and how much do you actually know? David Bland calls the exercise assumptions mapping.

The assumptions that are important and have little evidence behind them are the ones you test first. The rest can wait.

Test cheaply

You rarely need code to learn something. Some of the methods we use most:

  • Conversations with people who have the problem, about what they do today rather than what they think they would do
  • Paper prototypes and clickable sketches, tested with five users
  • Wizard of Oz: the service looks automatic, but a person does the work behind the scenes
  • Concierge: run the service by hand for a few users before you build it

Decide in advance what changes the plan

Before the test starts, write down which result would make you change course. If you do it afterwards, you'll almost always find a reason to carry on as before.

It's also fine if the answer is "we don't know yet". Then you've learned what the next test needs to be.

This isn't slowness

Some people feel testing slows them down. It's the other way around. A couple of weeks of cheap tests can save months of building something nobody needs. The most expensive mistake is the one you discover after launch.

By
Isabel Esbjug
Articles