Reviews
What would have to be true?
The five-word question our whole practice runs on. A long briefing on using it to audit claims, size risks, and end the meetings that should not have started.
By TIS Partners · · 5 min
Every practice accumulates one tool it would keep if forced to surrender the rest. Ours is a five-word question: what would have to be true? Readers of these briefings have watched us apply it to queues, to shard decisions, to multi-region ambitions. This briefing is about the tool itself: where it came from, why it works, and the specific ways we deploy it, including the ways it fails, because a method briefing that omits the failure modes is an advertisement.
where does the question come from?
The formulation is borrowed from strategy work, where planners learned to evaluate options not by arguing whether they were good but by enumerating the conditions under which they would be, then checking the conditions. The move sounds trivial and is not, because it changes the type of the conversation. "Is this architecture sound?" is a matter of opinion, and opinions in a review room arrive pre-attached to their owners' positions, reputations and fatigue. "What would have to be true for this architecture to be sound?" is a matter of enumeration. Lists can be checked. Opinions can only be outlasted.
The question's real work is separation: it divides every claim into its conditions, and conditions, unlike claims, have owners, evidence and dates. The architecture is sound if the queue absorbs the Monday burst, if the failover actually fails over, if the team that operates it still exists after the reorg. Each if is now a checkable item, and, just as importantly, each unchecked if is now visible as unchecked. Most bad architecture decisions we autopsy were not wrong in their logic. They were right conditional on conditions nobody wrote down, several of which were quietly false at the time of signing.
how do we actually use it?
Four deployments, in ascending order of ceremony.
As a listening tool, silently. When a vendor, a team lead or a diligence target asserts something ("this scales linearly", "the migration is low-risk", "we can be multi-region by June"), we translate it in the notebook before responding: under what conditions is that sentence true? The translation is fast, it is private, and it converts every assertion into a checklist of questions whose answers grade the assertion. Teams that brief us have learned to expect the follow-ups to be strangely specific. This is why.
As a meeting protocol, openly. When a decision meeting stalls, two positions, no movement, we stop the argument and put the question on the whiteboard for each side. What would have to be true for the rewrite to be right? What would have to be true for the strangler path? Ten minutes of enumeration usually reveals that the sides disagree about one condition, not twelve, and that the one is either checkable (someone goes and measures) or a genuine unknown (the decision becomes explicitly a bet, sized accordingly). Either outcome beats the argument, which was heading for a decision by stamina.
As a review structure, formally. Our assessment reports have, for years, carried a section per major claim titled "conditions under which this holds", and the format has a property we did not anticipate when we adopted it: it ages well. A report that said "the platform is adequate" is useless two years later. A report that said "adequate while write volume stays under X, the vendor's roadmap ships Y, and the two engineers who understand Z remain" can be re-audited in an afternoon, condition by condition, and the re-audit tells the client precisely which changes since have consumed the margins. The question turns a review from a verdict into an instrument.
As a pre-mortem inverter, occasionally. The classic pre-mortem asks "assume it failed; why?" and suffers from the theater of imagined disasters. The inverted form asks "assume it succeeded; what had to be true along the way?" and then walks the list asking which items current plans actually secure. The gap between the success conditions and the plan is the risk register, generated in an hour, in the project's own vocabulary rather than a consultancy's taxonomy.
what would have to be true for the question to fail?
The tool's own medicine, then. The question fails under three conditions, all of which we have met.
It fails when the enumeration is performed by advocates alone. A team enumerating the conditions for its own preferred architecture produces generous conditions; the discipline requires the skeptic in the room to add the conditions the advocates find impolite, the reorg, the departure, the vendor's acquisition. The question structures honesty; it does not supply it.
It fails when conditions are enumerated and never checked. We have seen the whiteboard filled, photographed, and filed, with every unchecked if proceeding directly into the plan as an assumption. The question's output is a work queue, and a work queue nobody drains is a decoration. Each condition needs a name and a date or the exercise was calligraphy. This is, not coincidentally, what a decision record owes you: the record of which conditions were load-bearing, so that their failure later is an alarm rather than a mystery.
And it fails, more subtly, on questions of value rather than fact. What would have to be true for this product to be worth building reaches, eventually, conditions about what customers want and what the company is for, and those are not checkable by measurement, only by market and judgment. The question clarifies where the judgment sits. It does not replace the judgment, and a room that expects it to will enumerate conditions forever as a substitute for deciding. We were in that room once, as the people holding the whiteboard marker, and the meeting that should have ended in a decision ended in a taxonomy. The client was gracious. The lesson stuck.
why does five words of framing move anything?
A fair skeptic asks why relabeling an argument as a list changes its outcome, and the honest answer is about people rather than logic. The question is depersonalizing: conditions belong to the world, not to the person who raised them, so checking one is not attacking anyone. It is symmetric: both sides of a disagreement submit to the same enumeration, which is why the meeting protocol works when it works. And it is calibrating: a claim whose conditions fill a page is visibly a bet, whatever confidence its author performs, and a claim whose conditions are three short checkable items is visibly solid, whatever anxiety surrounds it. The question makes the shape of knowledge visible, and rooms decide better when they can see what they know.
The queue question, the shard question, the nines question: every briefing in this series has been the same five words wearing different clothes. We have no better tool to offer, and after this many years of practice, we have stopped expecting to find one. Ask what would have to be true. Then, and this is the entire method, go and look.