A feature is not ready when every visible test passes. It is ready when the team can explain how the first real customer enters, moves through, and exits the workflow, including what happens when reality differs from the test data.
At Knight Capital on August 1, 2012, new trading software went live in New York. The deployment covered eight servers. One server did not receive the new code.
The release entered production anyway.
The server outside the review
Knight had reused a software flag previously associated with an older function called Power Peg. On seven servers, the deployment replaced the old code as intended. On the eighth, the old code remained.
When production traffic activated the flag, that server began sending unintended orders into the market. Knight lost roughly $460 million in about 45 minutes.
The US Securities and Exchange Commission documented the failure in its 2013 order against Knight Capital Americas. The order describes weak deployment controls, including the absence of a second person reviewing the release and no written procedure requiring technicians to confirm that the correct code had reached every server.
The release process could see seven successful deployments. It failed to establish that all eight production machines matched.
That distinction matters far beyond trading systems. A team can review a feature on Friday afternoon, watch every automated check turn green, click through the polished path, and still leave the most important question unanswered: how does an actual customer reach this screen on Monday morning?
A clean demo can begin halfway through the journey
Product reviews often start from a prepared account.
The user already exists. Their permissions are correct. Their sample data has the expected fields. The integration is connected. The AI has enough context to return a useful answer. The reviewer clicks the button, receives the intended result, and approves the release.
That test proves the feature works from the point where the test begins.
A real customer may begin three steps earlier. They arrive from a sales email with no account. They sign in using a different method. Their spreadsheet uses “Customer” where the importer expects “Client.” Their workspace has no historical data. The colleague who owns the required approval is unavailable.
Each condition is ordinary. Together, they define the product the customer actually receives.
This is especially easy to miss with AI features. Teams spend time checking prompt output, latency, formatting and model behavior. Those checks matter. The first-use path can still fail before the model receives anything useful. The customer does not experience an accurate response because they never supplied the context the demo account already contained.
The recent empirical study of 147 professional developers points to the same imbalance from another direction: broader, more frequent AI-tool use was associated with perceived productivity and quality gains, while AI testing adoption trailed AI coding adoption. We are getting faster at producing code. The discipline around testing how that code meets reality has not necessarily caught up.
Review the entry path before approving the feature
I would add one short exercise to the final review: remove the prepared state.
Create a new account through the same route the first customer will use. Start with an empty workspace. Use a plausible file that was not created by the product team. Follow the instructions exactly as written. Give the account the minimum permissions a customer is likely to have.
Then ask one person who did not build the feature to complete the first useful task without verbal guidance.
This review should answer concrete questions:
- What event brings the customer into the workflow?
- What must already be true before the feature works?
- Which of those conditions does the product create, and which does it merely assume?
- Where can the customer stop without the team seeing an error?
- What evidence tells support what happened?
The aim is not to imagine every edge case before shipping. A small team with limited runway cannot do that. The aim is to test the boundary between the product and the customer, because that boundary contains assumptions your unit tests may never touch.
The same principle shaped Kofi’s decision to add human approval to an AI purchasing assistant. The demo result mattered, but the surrounding decision path determined whether someone could trust it. It also appears in Kojo’s clean support metrics, where the visible numbers could not explain the customers who had already fallen out of view.
Make the first customer part of the release
Knight Capital’s eighth server was part of production even though it sat outside the successful deployment. Your first customer’s entry path is part of the feature even when the final review begins after it.
Before approving the release, write one sentence at the top of the review document: “The first customer arrives by…”
Complete that sentence with a real acquisition route, account state and task. Then run the release from there.
If nobody in the room can finish the sentence, the team has found the next test before the customer finds the gap.
Comments
No comments yet.