You Don't Know. You Assume.

Conviction isn’t evidence. One question tells you which one you have.

I’ve been teaching the core ideas and principles around “learning faster than the world can change” for quite a while now – long before OUTLEARN existed, back when it was mostly just a set of ideas, principles, and frameworks. And in all the rooms, across all the years I presented those ideas, the same question kept (and to this day keeps) surfacing, almost word for word: “How do I know I’m testing the right thing – and that the result actually tells me what I need to know?”

It’s a good question – and also, almost always, aimed at the wrong target. The problem is hardly ever the test; the problem is the thing you’re trying to test.

Here’s the problem: Assumptions arrive too big. Someone sits across from me, full of conviction, and says something that sounds perfectly reasonable – “a user will pay $40 a month for this.” Innocuous. One clean sentence. Except that one sentence is hiding a whole stack of separate assumptions, each one smuggled in as fact: That the user has the problem. That they know they have it. That they’d pay to solve it. That they’d pay that much. That they’d pay it to you. That they’d pay it now. Six conjectures wearing the costume of one.

And the test inherits the whole bundle. You build something to validate “users will pay $40 a month,” it comes back murky, and you’ve learned little – because you couldn’t isolate a single variable. A convoluted claim makes a convoluted test, and a convoluted test answers nothing.

Now, to be fair to ourselves: most of life runs on conjecture, and that’s completely fine. We couldn’t function otherwise. You can’t go back to first principles every time you cross a street, select a movie to watch, or pick a restaurant – the world is too complex and the day too short. We run on inherited belief, and mostly it serves us well. But when it comes to experiments – building a business, building a product, betting real time and money – you do have to go back to first principles of what you actually know to be true, and build up from there.

Which is where my single favorite question comes in, the one I ask sitting across the table from someone: “Do you know this to be true, or do you just assume it?”

It’s astonishing how often “I know” turns out to be “I assume.” You poke once, twice, sometimes more often, and the certainty dissolves. It was folklore. A best practice someone read in a deck. An industry standard nobody’s checked since 2014. What worked at the last company. “Everyone knows” this.

If this feels familiar, it should – it’s the Five Whys, the recursive interrogation Sakichi Toyoda built into the Toyota Production System. Same idea, different flavor. Not five whys here, but the same question asked again and again – do we know this to be true? – until you hit one of two floors: actual evidence, or an honest admission that you don’t know.

Once you’ve separated what you know from what you merely assume, the assumptions are out in the open. Now you can shrink them. The method is just this: atomize. Break the bundle down until each piece is a single falsifiable claim – one sentence, one variable, one thing that could be shown wrong. Take “users will pay $40 a month” and walk it down to its atoms – they have this problem; they recognize it as a problem; they’d pay to fix it; $40 is a price they’d accept; they’d buy it from us specifically; they’d buy it today. Suddenly the original question – “how do we test this in the cheapest, quickest way?” – answers itself.

Here’s the loop, repeatable on any claim you’ve got. Write the assumption as one falsifiable sentence – and if it needs an “and,” it’s not one assumption, it’s two, so split it. Ask “do we know this, or do we assume it?” – recursively – until you hit evidence or admit ignorance. For each assumption still standing, ask the real question: what’s the cheapest, quickest test that could prove this wrong? Note that – prove it wrong, not right. A test that can only confirm you teaches you nothing; you want the one that could kill the idea cheaply. Then, before you run anything, write down what result would change your mind. And run the smallest version first. Then the next. That’s it. That’s the discipline. And yes, it is the essence of the scientific method. But we tend to not do this in business.

So, the next time you catch yourself saying “I know” – do you? Or do you still assume?

@Pascal