the brief — prediction
Prediction
The Prediction is the commitment the team makes before building begins. It is the closing act of the upstream work: the point where the team says, explicitly, what they expect to change for whom, how they will know, and when someone will check.
Five components. All five must be present.
- Signal — the specific observable change. One signal, specific enough that anyone checking will know unambiguously whether it happened.
- Baseline — the current state, measured before any design or code work begins. Not estimated. Measured. The component most often missing — and its absence turns predictions into descriptions.
- Target — the state delivery will produce. Specific and falsifiable.
- Check date and method — when, who, and what they will look at. Named now, not decided in the retrospective.
- Owner — the named person responsible for running the check. Without an owner, the check does not happen.
Valid vs invalid — the baseline is the hinge
✗ "After release, we expect grading to be significantly faster and teachers to feel more confident."
No baseline, no target, no method, no owner. Confirmed by whoever is most optimistic in the retrospective.
✓ "Baseline: 47 min per cycle — session recording with Gal, 14 April, before any design. Target: under 10 min. Check: 30 days post-release, recording of Gal's next cycle. Owner: Project Lead. If not met: the retro asks what we got wrong about the problem — not what went wrong with execution."
A prediction without a consequence for being wrong is not a prediction — it is a hope.
How to apply this
- ✓ Measure the baseline before the first design session. By the time development begins, the design has already influenced how the baseline feels.
- ✓ Is the check method specific enough that a different person could run it and get the same result? "We will look at PostHog" is not a method. Name the exact query, session, person.
- ✗ Do not write the baseline after the cycle runs. Only a baseline written before the cycle is a genuine commitment.
- ◆ Technical briefs require both a technical metric and a human signal. "p99 < 200ms" is a metric. "Uri stops the manual Cardcom reconciliation after billing cycles" is the signal. Both required.