A finished AI feature should not ship until one person can make the release call and state what evidence would change it. When approval belongs to everyone, the feature is finished in code but unfinished as a product decision.
At 9:12 on Tuesday morning, Nia sat at a café in Accra with her laptop angled away from the rain on the window. Her small team had spent two weeks building an AI reply assistant for the customer-support inbox. The release branch was green. The demo worked. A prospective customer had asked when they could try it.
Then the designer asked a plain question in Slack: “Who is approving this for release?”
The engineer thought Nia would decide. Nia assumed the customer lead had already signed off on the answers the model could send. The customer lead believed the engineer had tested the edge cases. Nobody was refusing to own the call. Nobody had been given it.
Their prospect had a review meeting later that week. If the team shipped an assistant that gave a wrong answer in front of them, the pilot could end before it began. If they delayed without a reason, the same prospect could decide the product was still too early. Both outcomes were live.
Finished code can hide an unfinished product call
A green build answers a narrow question: can this version run?
It does not answer whether the team has decided where the AI should act, where it should ask for human review, what a bad answer costs, or who can accept that cost. Those are product decisions. They become visible only when somebody has to put their name beside a release.
I have seen this failure appear in teams that are moving fast for understandable reasons. The feature began as a customer request. An engineer translated it into a build. A founder promised a date because the next conversation with a buyer needed momentum. Each step made sense on its own.
By Tuesday, though, the team had confused progress with permission.
The ambiguity gets expensive because AI features often look complete before their operating boundaries are clear. A polished interface can conceal unresolved questions about source data, confidence thresholds, escalation, and the customer promise. The model may handle eight ordinary cases well. The ninth case is usually the one a customer remembers.
That is why a release should have a named decision owner before the work reaches the final pull request. This is not a call for a large approval chain. Small teams cannot afford one. It is a call for a person who can make a reversible decision with the available evidence, then explain the conditions for changing it.
The release owner needs a decision brief, not another demo
Nia closed the demo tab and asked the team to write four sentences before anyone merged the feature.
Who is this for? What can the assistant do without review? What must it hand back to a person? What would make us pause the release?
The answers exposed the real gap. The team had tested whether the assistant could draft replies. They had not agreed which replies it could send. Refund requests, account access issues, and messages with unclear context could cause problems that a fast response would not repair. The customer lead had assumed those would be excluded. The engineer had assumed the model’s confidence score was enough.
Neither assumption was a release plan.
A decision brief can fit in a product note or the release ticket. Its value comes from forcing a trade-off into view. “Release to one pilot customer, with drafts only for sensitive requests” is a decision. “We have tested it and feel good” is a mood.
The distinction matters when runway is short. Teams often treat every delay as lost momentum. Sometimes the more expensive move is shipping a broad promise before the team can support it. [Ama’s AI demo validation](\/blog\/ai-demo-validation-what-two-real-retailer-trials-taught-ama-about-runway-aba0f731\/) makes a related point: demand evidence has to be earned in the conditions where buyers will judge it.
Workflow comes before the model
Recent survey results point in the same direction. Only 25% of surveyed product and engineering leaders reported meaningful AI acceleration, while 30% reported declining team productivity. Organizations that redesigned workflows before adding AI were more than twice as likely to report productivity gains above 20%.
That result feels familiar because the model rarely carries the whole outcome. The workflow decides who supplies context, who checks the output, where exceptions go, and how the team learns when the feature fails.
For Nia, the change was modest. The assistant would draft replies for a single pilot customer. A support lead would approve messages in the first phase. The team would review every correction at the end of the day and group the failures by cause: missing account context, unclear policy, or a model answer that sounded certain when it should have asked a question.
That created a loop they could run. It also gave the prospective customer an honest description of what they were trying.
The team did not need to wait for a perfect system. They needed a bounded release with a person responsible for the boundary.
Make the release decision visible before release day
By late afternoon, Nia had put one name beside the approval field: hers. She also wrote the condition that would stop the pilot, any reply that could create a financial commitment without human review. The team could disagree with the line. They could change it after evidence. They could no longer pretend it was absent.
On Wednesday, the customer lead opened the first queue and found three drafts held for review. One had misunderstood a request for a refund as a request for account credit. The feature had not failed publicly. The team had found a case they needed to design for.
Before your next AI release, name the decision owner while the feature still has rough edges. Ask that person to state the release boundary in writing, then build the workflow that makes that boundary real. A finished feature deserves a decision that is equally finished.
Comments
No comments yet.