Every plan rests on beliefs nobody has checked — including technical ones: whether an integration will hold, whether the data is actually available. I surface them, rank them by what breaks if they’re wrong, and test the top one directly. Usually a working slice in a day or two, not a study.
A large piece of work is about to start and it rests on beliefs nobody has checked. Someone says “obviously users will want this” and the room nods. The integration is assumed to be straightforward. The data is assumed to be available. The plan has one load-bearing assumption that, if wrong, invalidates the rest — and nobody has named it out loud.
I get every assumption on the table, including the technical ones. Whether an integration will hold. Whether the data exists in the form the feature needs. Whether anyone will change their behaviour.
Then I rank them by two things: how confident we actually are, and how much breaks if we're wrong. The top-right quadrant is where the work goes.
I test the riskiest one directly, and usually cheaply. A working slice in a day or two beats a research study, because the point is to find out whether the thing holds — not to produce evidence about it.
The discipline that matters: deciding in advance what result would stop the project. Without that, a test becomes a justification.
One to two weeks, usually at the front of a larger piece of work. Deliberately short — the value is in doing it before commitment, not thoroughly.
Isn't this just risk management?
Similar instinct, different scope. This is about product beliefs rather than delivery risk, and it ends in a test rather than a register.
What if the test says stop?
Then it saved you a quarter. That's the whole point, and it's why the threshold gets agreed before the data arrives.
Can this run alongside development?
Yes, though it's less valuable. The cheapest time to discover a wrong assumption is before anyone has built against it.