Writing Requirements That Survive Contact With Engineering

Most requirements documents fail the same way: they read perfectly clearly to the person who wrote them, and then fall apart the moment an engineer asks the first follow-up question in sprint planning. The gap isn't intelligence or effort — it's that the requirement was written to describe the what the business wants, without ever forcing a decision on the edge cases that engineering will inevitably hit first.


**Core question:** why do good decision-makers treat a coin flip completely differently from a genuinely unknown future?

## The metaphor: a labeled deck vs. an unlabeled one

**Risk** is a deck of cards where you know exactly what's in it — you might not know which card comes next, but you know the odds. Insurance, casino games, and most everyday probability puzzles are risk: the deck is labeled, even if any single draw is uncertain.

**Uncertainty** is a deck where you don't even know what's in it — new categories of cards you've never seen, or cards that don't exist yet. Launching a genuinely new product, predicting a novel technology's effect on a market, forecasting a one-off geopolitical event — these aren't risk. There's no stable deck to calculate odds from.

 Callout type="insight" title="Confusing the two is the actual mistake" 
Treating uncertainty as if it were risk — assigning confident percentages to things that are fundamentally unknowable — is where most bad forecasts come from. The math looks rigorous. The deck was never labeled.
 /Callout 

## Why this distinction changes behavior

Under risk, the right move is to calculate expected value and act on it — the odds are real, so trust the math. Under uncertainty, the right move is different: build in optionality, run small reversible experiments, and stay able to change course, because no calculation can tell you the "true" odds of something that's never happened before.

 Callout type="question" 
Before trusting a forecast, ask: is this a labeled deck, or an unlabeled one? The confidence in the delivery tells you nothing about which one it is.
 /Callout 

## Why this matters

Good decision-makers don't have better crystal balls. They're just more honest about which situations are a labeled deck and which ones aren't — and they stop demanding false precision from the ones that aren't.



**Core question:** why does a price settle where it does, instead of anywhere else?

## The metaphor: two crowds pushing on a door

Picture a door with people pushing from both sides. On one side, buyers push harder the cheaper the price gets — more people want in at a bargain. On the other side, sellers push harder the more expensive it gets — more people are willing to sell if the reward is bigger. The door settles wherever the two pushes exactly cancel out. That resting point is the price.

Push either crowd harder — more buyers show up, or sellers become scarcer — and the door slides to a new resting point. Nobody decided the new price. It's just where the pushing balances again.

 Callout type="insight" title="Price is a byproduct, not a decision" 
No single person sets the market price of wheat, oil, or a stock. It emerges from thousands of independent pushes finding their balance point — which is why prices can shift overnight without anyone "deciding" to change them.
 /Callout 

## Why shortages and gluts are the same phenomenon

A shortage is just the door stuck too far toward the buyers' side — the price is artificially low, so more people want in than the sellers' side can supply. A glut is the mirror image: price stuck too high, sellers piling up with no buyers pushing back. Both are the same mechanism, just displaced from the balance point — usually by something external holding the price fixed (a price cap, a subsidy, a shock to supply).

 Callout type="question" 
Next time you see a shortage in the news, ask: is demand suddenly rising, or is something stopping the price from finding its natural balance point?
 /Callout 

## Why this is worth understanding

Once you see price as a balance point rather than a fixed fact, a lot of economic behavior stops being mysterious: why gas prices spike during shortages, why concert tickets get scalped, why a heatwave moves the price of ice cream. It's always the same two crowds, pushing.



**Core question:** out of everything an organization *could* build, why does it build this instead of that?

## The metaphor: a scale, not a checklist

A business case isn't a list of reasons something is good — almost anything can be justified with a long enough list of upsides. It's a scale, with cost and risk on one side and value on the other, built to be checked *against a specific alternative*: doing nothing, or doing the next-best thing on the list. A business case that never names its alternative isn't really a case for anything — it's just enthusiasm.

 Callout type="insight" title="The real competitor is usually 'do nothing'" 
Most business cases quietly compare an idea to nothing at all, when the real competition is every other initiative fighting for the same budget and the same engineering time this quarter.
 /Callout 

## The four things a real business case answers

- **What changes if we do this?** — the measurable outcome, not the feature list.
- **What does it cost, including the cost of *not* doing something else?**
- **What has to go right for the value to actually show up?** — the assumptions the case is quietly resting on.
- **How would we know, after the fact, whether it worked?**

 Callout type="question" 
If you can't answer the fourth question before the project starts, ask whether anyone will actually check afterward — or whether "success" will just be declared by default.
 /Callout 

## Why this matters

The organizations that build the right things aren't the ones with the best ideas — everyone has good ideas. They're the ones that can weigh ideas against each other honestly, using the same scale every time, instead of whichever argument was pitched most persuasively in the room.
