Someone hands you a scope. A new product, a new service, a new initiative. It is well-intentioned. It is probably incomplete. And if you accept it at face value and start building, you will discover the gaps at the worst possible time — in production, in a review, in front of a customer who expected something the brief never quite promised but definitely implied.
The brief is not a lie. It is a compression. Every person who writes a scope document is collapsing a complex, ambiguous reality into a set of requirements that fit on a page. Things get lost in that compression. Your job is to find them before they find you.
The instinct is to start. Momentum feels like progress, and a brief with clear deliverables creates the illusion of clarity. But clarity about what to build is not the same as clarity about what could go wrong. The two require different questions — and most teams only ask the first kind.
The brief tells you the intended path. It does not tell you where the path fails.
Fault tree analysis — borrowed from engineering and aviation, where failure has immediate and irreversible consequences — is the discipline of working backwards from failure rather than forwards from intent. You start at the worst outcome and ask: what would have to be true for this to happen? Then you ask it again, one level up. And again, until you reach the conditions that are already present in the environment you are about to build in.
Applied preemptively, before a line of code is written or a team is assembled, this is not pessimism. It is precision. You are not looking for reasons not to build. You are mapping the points of failure so you can design against them — or at minimum, know where to watch.
The questions that do this work are not the ones in the standard discovery template.
Ask what the scope assumes that has not been confirmed. Every brief contains hidden assumptions — about user behaviour, about technical capability, about stakeholder alignment, about market conditions. Name them explicitly. Then ask which ones have been verified and which ones are being taken on faith. The unverified assumptions are the fault lines.
Ask what happens when the primary user does the unexpected thing. The brief describes the intended journey. Users do not always take it. They misunderstand, they shortcut, they use the product in ways no one planned for. The failure to design for this produces products that work in demos and break in the field.
Ask who is not in the room. Every brief is written by the people who were consulted. Somewhere, there is a team, a system, or a stakeholder whose requirements were not captured because no one thought to ask them. Find the gap in the consultation before it surfaces as a dependency you did not account for.
Ask what the definition of failure is. Not success — failure. Most teams can describe what a successful outcome looks like. Fewer can describe, precisely, what failure looks like and at what point they would recognise it. Without that definition, the project can drift toward failure without a clear moment where someone calls it.
Ask what cannot be undone. This is Bezos's question, made operational. Some decisions are consequential and irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don't like what you see on the other side, you can't get back to where you were before. Identify the one-way doors in the scope early. They deserve disproportionate scrutiny before you move through them. Everything else — the two-way doors, the reversible choices — can be made faster, iterated on, corrected. But the irreversible commitments, once made, define the constraints you will be working inside for a long time.
A word on calibration.
This is not a case for analysis paralysis. Not every brief warrants a full fault tree. Not every assumption needs three weeks of validation. The discipline is in knowing which decisions are one-way doors and applying rigour proportionally — slow where it matters, fast where it doesn't.
The brief for a two-week experiment does not require the same scrutiny as the brief for a two-year platform. The team launching a reversible pilot can afford to learn from failure. The team building infrastructure that will be load-bearing for the next five years cannot. Apply the depth of questioning to the irreversibility of the commitment, not to the size of the initiative.
What you cannot afford, in any case, is naive acceptance. The brief is a starting point. The questions you ask before you start are what determine whether the gaps in it become discoveries or disasters.
The team that interrogates the brief before committing is not the team that moves slowly. It is the team that moves once — in the right direction, with its eyes open, having already mapped the places where the path could fail.
The team that accepts the brief and starts is the team that discovers the fault lines in production.
The brief tells you what to build. The questions you ask before you start tell you what could break it. Ask them before the first decision becomes irreversible.