What has to be true for this to work: the assumptions list

A product owner at a supply-chain platform told me he got tired of the same feeling. A project would run for months, everything looking fine, and then something obvious would blow up. The data was not as clean as everyone thought. The users did not actually do the task the way the design assumed. The system the output fed into had a limit nobody had checked. Each time, the failure traced back to something the team had quietly assumed was true and never verified.

He realized these were not random surprises. They were assumptions. Every project rested on a stack of things that had to be true for it to work, and most of those things were never said out loud, let alone tested. They just sat there, load-bearing and unexamined, until one of them turned out to be false at the worst possible moment.

So he added one step to the start of every project. Write the assumptions list. What has to be true for this to work. Not the requirements, the assumptions underneath them. Then, for each one, decide how you would find out if it is false, and check the risky ones first.

Assumptions are the load-bearing walls you cannot see

Requirements are visible. Everyone reads them, argues about them, signs off. Assumptions are the opposite. They are the beliefs so obvious nobody thought to state them, which is exactly why they are dangerous. “The historical data is accurate enough to learn from.” “Users will trust the suggestion and act on it.” “The categories we defined actually cover the real cases.” Each of those can be false, and if it is, the project fails no matter how well you executed everything above it.

The reason they hurt so much is timing. An assumption that fails in week one is a quick pivot. The same assumption, discovered in month five, is a rebuild, because everything you built sat on top of it. The cost of a wrong assumption grows the longer it stays hidden. Writing it down and testing it early is how you pay the small cost instead of the large one.

His list for one project was short and pointed. The supplier data is complete enough to predict delays. Planners will act on a prediction rather than trust their gut. A prediction that is often right will still be trusted the day it is wrong. Each of those was a belief the whole feature depended on, and each one could be checked before building the feature.

Make each assumption testable

An assumption you cannot test is just a hope. The work is turning each one into something you can actually verify, cheaply, before you commit.

State the assumption as a plain sentence someone could disagree with. “Users will act on the suggestion,” not “the feature will be adopted.”
For each one, write how you would find out it is false. Pull a sample of the data. Watch five users. Check the system’s real limit.
Rank them by risk. Which assumption, if false, kills the project. Test those first, before you build on them.
Treat a failed assumption as information, not defeat. Better to learn it in week one than to ship on top of it.

The supply-chain team tested the “planners will act on it” assumption by showing planners mock predictions and watching what they did. Half of them ignored the prediction and did what they always did. That was the whole project’s foundation, and it was cracked. They fixed the design before building, not after, because the assumption was on a list instead of in someone’s head.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement at $2,500, building the assumptions list is core to the work. We pull the beliefs the project depends on into the open, phrase them so they can be wrong, and test the riskiest ones inside the two weeks. A false assumption caught early is the single cheapest save in an AI project, and a false assumption caught late is often the whole loss. The engagement exists to move those discoveries from month five to week one.

Every project stands on assumptions. Write them down, test the ones that would kill it, and stop being surprised by your own foundations.