
**Core question:** how do you actually know when something is done?

## The metaphor: a handshake vs. a contract

A user story without acceptance criteria is a handshake deal. Both sides nod, both sides believe they agree, and both sides walk away with a slightly different picture of what was promised — which only becomes visible once the work is "done" and it doesn't match what either side remembers agreeing to. Acceptance criteria are the contract version of that same handshake: written down, specific, and checkable by someone who wasn't in the room when the deal was made.

 Callout type="insight" title="A shared assumption isn't a shared understanding" 
Two people can nod at the same sentence and picture two different outcomes. Acceptance criteria exist to force that gap into the open before the work starts, not after it ships.
 /Callout 

## Given / When / Then is the actual unit of "done"

The useful structure is a precondition, a trigger, and an outcome: *given* the account is locked, *when* the user requests a password reset, *then* a reset link is emailed and the lock stays in place until it's used. Each clause is independently testable — a QA engineer, a developer, and the original stakeholder can all check the same sentence against the same built feature and reach the same yes-or-no answer. That's the entire point: acceptance criteria aren't documentation, they're a test someone can actually run.

 Callout type="question" 
Could two different engineers, working independently, build testably identical things from this criteria alone? If the answer depends on both of them happening to guess the same unstated assumption, the criteria aren't finished yet.
 /Callout 

## Why this matters

"Done" isn't a feeling the team agrees on in a meeting. It's a checklist that was written before the work started, specific enough that no one — not the developer, not the tester, not the stakeholder — has to rely on memory to know whether it was actually met.



**Core question:** what should be built first, when everything feels urgent?

## The metaphor: triage in an emergency room

An ER doesn't treat patients in the order they arrived. It treats them in order of what happens if they wait — a broken finger and a chest pain case might arrive at the same moment, but nobody seriously suggests treating them first-come-first-served. Prioritizing a backlog is the same triage, not a queue: the order tickets arrived in tells you almost nothing about the order they should be worked in.

 Callout type="insight" title="Loudest voice isn't most critical" 
"Urgent" and "important" get conflated constantly on a backlog. The stakeholder who escalates the hardest doesn't automatically have the item that costs the business the most by waiting — they just have the most confidence, or the most patience for meetings.
 /Callout 

## Value and effort are the only two axes that matter

Every item on a backlog can be placed on two axes: how much value it delivers, and how much effort it takes to deliver. High value, low effort items are the ones triage would send straight to the front — the equivalent of a five-minute fix that stops the bleeding. Low value, high effort items belong at the back regardless of who's asking, no matter how urgently they're asking for it. Prioritization frameworks (MoSCoW, weighted scoring, whatever the team uses) are just formal ways of forcing that comparison instead of letting whoever asks loudest win by default.

 Callout type="question" 
For any item near the top of the backlog, ask: what actually happens if this waits one more sprint, and who notices? If the honest answer is "nothing, and no one," it isn't triage-first — it just arrived first.
 /Callout 

## Why this matters

A backlog ordered by arrival time or by who complained most recently isn't prioritized — it's just a log. Real prioritization means being able to explain, for the item at the top, specifically what gets worse if it waits — the same way an ER can explain why the chest pain goes first, not just that it does.



**Core question:** why does the problem you solve matter more than how well you solve it?

## The metaphor: a doctor who prescribes before diagnosing

A patient walks in and says "I need antibiotics." A bad doctor writes the prescription. A good doctor asks what's actually wrong first — because "I need antibiotics" is already a diagnosis the patient made themselves, and patients are usually wrong about what's actually causing their symptoms. Stakeholders do the same thing constantly: "we need a dashboard," "we need a new system," "we need an approval workflow." Each one is a prescription arriving before anyone confirmed the diagnosis.

 Callout type="insight" title="The most expensive words in a requirements meeting" 
"We need a system that..." is already a solution. It skips the one question that would have told you whether it's the right one: what problem is this actually solving, and does the system even solve it?
 /Callout 

## The requested solution has already made three decisions

By the time a stakeholder names a fix, they've silently already decided its shape, its technology, and who's responsible for it — all before the actual problem was ever said out loud. Accept the request as stated and you've inherited three decisions nobody actually examined. Walk it back to the problem first, and some of those three might turn out wrong: the right fix might be a process change, not a system; a policy change, not a dashboard.

 Callout type="question" 
Next time a request arrives starting with "we need X," ask what happens today without X. The gap between those two answers is the actual problem — X was just someone's first guess at closing it.
 /Callout 

## Why this matters

A solution chosen before the problem is understood tends to treat the stated symptom while leaving the underlying cause untouched. It still gets built, on time, to spec — and it still doesn't fix anything, because nobody ever confirmed it was aimed at the right target in the first place.



**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.
