A launch should stop when the team can explain every feature but cannot name the customer uncertainty the product resolves. Shipping at that point produces activity, screenshots and release notes, while the buying decision remains unanswered.
At 4:47 on a Friday afternoon in Accra, Kojo had his cursor over the approval button. He is a composite founder, drawn from a familiar early-stage situation: seven weeks of runway, two engineers waiting in a video call, and a prospective customer expecting access before Monday.
The team could describe the product in detail. It imported sales records, flagged unusual changes, generated summaries and sent alerts. Then Kojo asked one question: “What decision becomes easier after the alert arrives?”
Nobody answered.
The question hidden behind the feature
The product had grown from a reasonable observation. Small retail teams kept their sales information in several places and spent too much time assembling it. Kojo’s team built an AI assistant that gathered the records and explained what had changed.
The demo worked. A manager could see that sales had fallen, which product category moved and which location reported the change. Each screen gave accurate information.
Yet the manager already knew sales were down. The uncertainty came next: was this a temporary reporting problem, a stock issue, a pricing mistake or a change in customer demand? Should she reorder, call a branch manager or wait another day?
Kojo’s product stopped before that decision.
This is where feature conversations can mislead a small team. “Can we detect the change?” sounds like a product question. “What will the customer do differently after seeing it?” exposes the commercial one.
The same gap appears when an AI demo handles the impressive path and avoids the costly decision. I wrote about a related version of it in The Missing Page Your AI Demo Avoided, and What the Customer Might Pay. The missing screen often contains the reason someone would pay.
What approving the launch would commit
Kojo had promised the prospect Monday access. Missing that promise could end the conversation. Approving the release carried a different risk: the customer might open the product, receive an accurate alert and still return to the spreadsheet and phone calls she used before.
Either outcome could cost the team the account. One would also cost them weeks of engineering time they could not recover.
At 5:06, Kojo removed his hand from the trackpad and asked the prospect for a short call. He did not ask whether the dashboard looked useful. That question tends to produce polite approval.
He put a recent sales drop on the screen and asked, “When you see this, what are you uncertain about?”
Her answer changed the launch. She wanted to know whether the decline came from missing stock or weaker demand. Those two explanations led to opposite actions. Ordering more stock could help in one case and deepen the loss in the other.
The team had been preparing to launch an alerting product. The customer was trying to avoid making the wrong inventory call.
That distinction was narrow enough to build around and important enough to delay for.
A smaller release with a clearer job
Kojo did not turn the answer into another broad feature request. He cut the release to one decision path: show the sales decline, display the available evidence around stock movement and demand, and state when the data could not support a conclusion.
The last part mattered. An AI product earns trust by marking the edge of what it knows. A confident explanation built from incomplete records would push the customer toward a decision the product had not earned.
This resembles the release problem in Should We Pause a Fintech Launch When the Demo Conditions Do Not Match Customers?. A working demo can still leave the real operating condition untested.
On Monday morning, the prospect received a narrower build than Kojo had planned on Friday. It made fewer promises. It also gave her a specific reason to open it: she could inspect one uncertain sales change before deciding whether to reorder.
The account was still unresolved. She had agreed to test the decision path, not to buy. Kojo’s runway had not grown over the weekend, and the team still had to learn whether the evidence they surfaced was sufficient.
But the next product conversation had changed. Instead of debating another chart or summary, they could watch where the manager hesitated, what evidence she checked and which action followed.
The check before your next approval
Before approving a launch, ask one person on the team to finish this sentence:
“After seeing this, the customer can decide whether to ______.”
Allow one verb and one decision. “Understand performance” is too broad. “Decide whether to reorder this week” can be tested.
Then ask what happens if the product gives the wrong answer, an incomplete answer or no answer. That exposes the evidence required, the boundary the interface must state and the risk the customer is carrying.
Kojo returned to the approval screen after the call. The large Friday release stayed stopped. In its place sat one smaller build, one unresolved buying decision and a Monday test that could fail for a reason the team would understand.
Comments
No comments yet.