NKD_4 — The Limit of Intention

NKD_4 — Anytime we do something, we don't know exactly what we've done.

The misconception it corrects

Modern delivery practice treats the released product as the known output of an intentional process. The team scoped a feature, built it to spec, tested it against requirements, and shipped it. The thing now in the world is the thing the team meant to ship. The release notes describe it accurately.

This is almost never true. The thing shipped is not what the team meant to ship; it is what the team's interaction with the world produced. The release notes describe the team's intention. They do not describe the thing now in the world, which is in continuous, irreducible interaction with users, contexts, infrastructure, and competing products, all of which are themselves changing.

NKD_4 names this. Anytime we do something, we don't know exactly what we've done — because what we have done is determined by the world's response, not by our prior model of it.

What it changes in practice

The release is the start of the research, not the end. Teams that internalise NKD_4 plan, before launch, what they will learn from the launch — not just what they will measure for performance. Performance metrics tell you how well the intended thing is performing. NKD_4 metrics tell you what was actually built.

Surprise is tracked as data. Most teams have no record of what surprised them about their own product after launch. NKD_4-trained teams maintain a surprise log — every unexpected user behaviour, unexpected usage context, unexpected market response. The log is the most honest description of what the team actually shipped.

Roadmaps become responsive, not directive. A roadmap that treats next quarter's plan as fixed assumes that this quarter's release was understood. NKD_4 challenges that assumption. Roadmaps shift from delivery plans to learning plans — sequences of releases each of which is designed to make the next one's plan possible.

A working method: the surprise log

The technique is simple. We have yet to see it fail to produce useful output in client engagements.

After every significant release (a feature, a product, a campaign, a partnership), the team maintains a running log with one column per week for the first quarter post-launch:

The discipline is to write something every week, even when nothing dramatic happened. The cumulative log is a far more accurate description of what was shipped than the release notes.

Three things tend to emerge.

First, the team learns to distinguish between foreground surprise (the unexpected adoption pattern, the surprising review, the strange use case) and background surprise (the slow drift in how the product fits into users' lives that becomes visible only when the weeks are read in sequence). Background surprise is invisible at any single week's standup; the log makes it legible.

Second, the surprise log becomes the most useful input to the next release. Teams that maintain one ship better second releases.

Third, the log accumulates institutional knowledge about how this team is calibrated. You can read the log six months later and see, in plain English, the patterns of where the team's intuitions hold and where they break. That is metadata about the team itself, and it is enormously valuable in deciding what to delegate, what to instrument, and where to look harder next time.

A note on humility as discipline

NKD_4 sounds, on the surface, like a counsel of intellectual humility. It is — but humility here is a working discipline, not a sentiment. It is the discipline of keeping the model of the released product open for longer than the team's intuitions would prefer. Intuition wants closure: we shipped it, we know what it is, let us move on. NKD_4 says: not yet. Not until the world has weighed in. And the world weighs in slowly.

Where this principle lives in our work

NKD_4 shows up most often in our work with start-ups and product organisations, where the temptation to declare a release "understood" and move on is structurally rewarded by quarterly cycles. The surprise log is the artefact that most often gets pushback at the start of an engagement ("we already have analytics") and most often gets adopted permanently by the end.

Key takeaway: what you shipped is not what you meant to ship — it is what your release plus the world produced. Maintain a surprise log to track the difference, and treat each release as a hypothesis whose truth value is determined by the world.

← NKD_3 | Next: NKD_5 — Designing under epistemic humility →