Operator Playbook · Strategy
The Assumption Audit
A decision discipline for the operating leader staring at an AI backlog — how to separate the initiatives worth funding from the ones quietly burning, built on the reform Mark Leonard ran at Constellation Software.
The backlog nobody wants to read out loud
Look at your AI backlog. Not the roadmap slide — the real list. The pilots that got funded last year, the vendor trials someone is “still evaluating,” the internal projects with a champion who moved to a different team eight months ago and never told anyone.
Now ask a harder question about each one: what has to be true for this to work, and who is proving it?
For most items, there is no answer. There is a budget line, a Slack channel, and a quiet monthly burn. There is no single sentence naming the assumption the project lives or dies on, and there is no single name accountable for testing it. The project is not succeeding and it is not failing. It is drifting, and drift is the most expensive state an initiative can be in, because it consumes money and attention while producing neither a result nor a decision.
Mark Leonard, who built Constellation Software into one of the best-run acquirers of vertical-market software on the planet, named this pattern precisely in his 2012 president’s letter. The company’s long-gestation R&D projects, he wrote, tended to “drag on with a low but perpetual burn rate under a part-time leader who didn’t feel ultimately responsible.” Read that sentence again with your AI backlog in mind. It is the same pattern. It is almost always the same pattern.
This playbook is the discipline Constellation used to fix it, turned into an exercise you can run against your own backlog this week.
What Leonard actually changed
The reform Constellation ran in 2012 was not complicated. It was four moves, and every one of them is portable.
First, they separated the long-gestation bets from ordinary spend. Constellation gave them a name — “Initiatives” — and stopped letting them hide inside the normal operating budget where nobody scrutinized them as bets. If a thing is a speculative wager on an uncertain future, it should be tracked as one, not smuggled in as a line item.
Second, they required every Initiative to state the assumption it lived or died on, and a test for that assumption. Not a business case. Not a deck. The single load-bearing belief, written down, plus the experiment that would prove or disprove it. This is the move that does the most work, and it is the one most AI backlogs skip entirely.
Third, they created a dedicated Initiative Champion role — one accountable owner. Not a steering committee. Not a part-time leader borrowing hours from a day job. One name, ultimately responsible. Leonard’s diagnosis of the old system was that the part-time leader “didn’t feel ultimately responsible,” and the fix was to make someone feel exactly that.
Fourth, they kept early burn low until proof of concept — “sometimes even getting clients to pay for the early development” — and they triaged the moment a key assumption proved wrong. A dead assumption was not a failure to be managed quietly. It was a signal to stop, and stopping was the point.
The result surprised even Leonard. Once each bet had to name its assumption and carry an accountable owner, “the number of new Initiatives proposed plummeted.” His read on that drop was not that the company had become timid. It was that the prior volume had been waste — proposals that never should have been funded, that only survived because no one had made them say what they were betting on.
His own summary of the method is the most honest description of disciplined experimentation I have found from an operator: “We just had a hunch… and started measuring them… with measurement came adjustment and adaptation. It took 6 years.”
Six years. Note that. The discipline was not a quarter’s initiative. It was a decade-scale change in how the company thought about its own bets.
Why this maps onto AI so cleanly
Constellation’s Initiatives were software R&D projects. Your AI backlog is a stack of software R&D projects wearing a fashionable label. The economics are identical: a set of speculative bets, each with an uncertain payoff, each easy to fund and hard to kill, each capable of burning quietly for years under a part-time owner who does not feel ultimately responsible.
The difference is that AI arrives with more momentum and less scrutiny than almost any technology before it. The vendor pressure is higher. The fear of being left behind is louder. Both of those forces push in exactly the wrong direction — toward funding more bets faster, with less clarity about what each one is actually wagering on. That is the disorganized-optimism trap, and it is the reason an assumption audit is worth more in 2026 than it would have been for Leonard in 2012.
The company that ran on organized skepticism ended up with fewer, better bets and a burn rate that stayed low until proof arrived. The company running on disorganized optimism ends up with a backlog it cannot read out loud.
The audit
Here is the exercise. Block ninety minutes. Bring the real list, not the roadmap.
1. List every funded or queued AI initiative. All of them — the pilots, the vendor trials, the internal experiments, the “we’re still looking at it” projects. If money or engineering hours are attached, it goes on the list.
2. Write one sentence per item naming its live-or-die assumption. The single belief that, if false, kills the project. Not “improve customer service” — that’s a goal, not an assumption. The assumption is the thing you are betting is true: “We believe the model can resolve tier-1 billing inquiries without a human, at a quality our customers won’t churn over.” If you cannot write that sentence for an item, that is not a small gap. It means nobody has decided what the project is testing, which means it cannot succeed or fail — it can only drift.
3. Put one name against each — the person accountable for proving the assumption. One name. Not a team, not a committee, not “IT.” The Initiative Champion. If the honest answer is “no one, really,” you have found a part-time-leader project, and Leonard already told you how those end.
4. Kill or park anything with neither an assumption nor an owner. This is the hard part and the whole point. A project with no stated assumption and no accountable owner is not an asset. It is a quiet burn rate. Killing it is not a loss; it is the recovery of money and attention that were producing nothing. Expect this step to feel uncomfortable, and expect the discomfort to be the tell that you needed the audit.
5. Re-rank the survivors by whichever assumption is cheapest to test. Not by upside, not by executive enthusiasm — by cost of proof. The bet whose load-bearing assumption you can validate for the least money and time goes first, because the fastest thing an experiment can do for you is tell you to stop. Constellation kept early burn low precisely so that a wrong assumption cost little to discover.
6. Keep early burn low until the assumption survives contact with the real workflow. No scaling, no platform build, no company-wide rollout until the core belief has been tested against how the work actually happens — not in a demo, not in a pilot sandbox, but in the real workflow with the real operators. The assumption that survives that contact is the one worth funding to scale. The one that dies there was going to die anyway; you just found out for a fraction of the price.
Run this and the backlog reorganizes itself. A few items sharpen into real bets with owners and tests. Most reveal themselves as drift. That reveal is the entire return on the exercise.
The number that should end the “we need more control” argument
There is a predictable objection to this discipline: if we let individual owners run their own bets, won’t it get chaotic? Don’t we need central control? Constellation’s own data answers it.
Leonard runs a radically decentralized company. Its operating units averaged 44 employees, and when he checked whether unit size predicted performance, the correlation was effectively nothing — an R² below .001. Size did not explain results. Meanwhile the head office, the central-control function, fell from 3.0% of revenue in 2004 to 0.5% by 2016. His summary of why that worked: “trust trumped central bureaucracy.”
The lesson for your backlog is not “abolish oversight.” It is that oversight belongs in the discipline — the stated assumption, the named owner, the cheap test — not in a central committee that approves everything and is accountable for nothing. Accountability distributed to named owners beat control centralized in a head office. It is the same principle as the audit: put the responsibility on a name, make the bet say what it’s wagering, and let the test decide.
And when the discipline holds, the payoff compounds the way retention does. Constellation’s customer attrition ran around 4% a year — an average customer life of roughly 26 years. That is what disciplined, un-glamorous, assumption-tested operating buys over time. Not a press release. A quarter-century customer.
You cannot name the assumption from a conference room
Every step of this audit depends on one thing being true: that you can actually write the sentence — the real assumption each AI initiative lives or dies on. And here is the trap. You cannot write that sentence honestly from a conference room, or from a vendor’s deck, or from a roadmap someone built by reading other companies’ case studies. The real assumption a workflow initiative rests on only becomes visible when you watch the workflow happen — when you sit with the person who runs it and see where the judgment actually lives, where the exceptions hide, where the model would meet the messy reality it has to survive.
That is the discipline geniant sells. Before any AI gets built, they sit with how the work actually happens, find the one workflow quietly bleeding margin, and name the assumption the fix rests on — then build and ship it to production with one senior-led team, your systems of record left in place, in weeks rather than months. It is the assumption audit run for real, on your actual work, by people who do it for a living.
I’m a Partner at geniant, so you know where I stand. Since 2003 the people behind it have done one thing: understand how work actually happens, then build software that works the way humans do. That’s the discipline this playbook describes — watch the work, name the assumption, test it cheap, scale only what survives.