why we build — the second question
The second question
Most teams ask one question at the end of a cycle: did we ship what we said we would ship?
This is a reasonable question. It is not a sufficient one.
The second question is harder: did shipping it change what we said it would change? Did the teacher spend less time on administration? Did the receptionist have a better morning? Did the person who was going to miss the anniversary of a loss get reminded in time to do something about it?
The second question is uncomfortable because it requires admitting, upfront, what you believe will happen. Before the code is written, before the design is finished, before the first story enters the queue — you have to say: if this works, here is how we will know. A specific person. A specific change. A specific date on which someone will check.
This is not a performance requirement. It is an act of intellectual honesty. Writing the prediction before the cycle runs means committing to a version of reality that could turn out to be wrong. And if it turns out to be wrong — if the teacher still spends the same amount of time, if the receptionist still describes the morning in the same way — you have to reckon with that. Not explain it away. Reckon with it. Ask what the model got wrong. Update it. Carry that update into the next cycle.
A retrospective without a prior prediction produces feelings, not learning. Feelings have value — they are honest responses to what happened. But they cannot update the model because there is no model to correct against.
When both questions are asked — and answered honestly — something changes. The gap between what was built and what was needed becomes visible. Visible gaps can be closed. The model gets more accurate. The next prediction is better. The next cycle starts closer to reality than the last.
This is confidence — not certainty, but the measured improvement in how accurately we understand what we are building and whether it works. Like trust, it compounds. A team that has run twenty honest cycles — predictions written, checked, updated — builds differently than a team that has not. Their estimates are less wrong. Their scoping conversations are shorter. Their clients feel the difference, even when they cannot articulate why.