A polished AI demo proves that the product can handle a rehearsed path. The real test begins when a buyer brings up the exception that happens on an ordinary working day.
Ama, an invented composite of several founder situations I have seen, was sitting at the end of a meeting table in Accra when she asked the question nobody had prepared for. The team had shown an AI assistant turning customer messages into tidy order records. Ama leaned forward, still holding the notebook where she had marked three missing fields, and asked: “What happens when the customer pays from one phone number, sends the order from another, and asks us to deliver under a third name?”
The assistant produced a confident answer. It was also wrong.
For a few seconds, nobody spoke. The demo had worked perfectly for the fictional user in the product brief: one person, one identity, one clean transaction. Ama’s buyers did not behave that way. If the system merged the wrong records, her team could send an order to the wrong person, lose the payment trail, and spend the afternoon deciding which version to trust.
The partnership under discussion could end in that room.
The demo user had cleaner habits than the buyer
The team had built for a person who completed each step in sequence. That person entered consistent details, replied from the same account, and corrected mistakes before submitting anything.
This made the demo look good because the product always received the information it expected.
Ama’s question exposed a different operating environment. Customers changed channels halfway through a purchase. A relative sometimes paid. Someone else collected. A staff member might recognize the buyer from a previous conversation while the software treated every message as new.
The technical problem was identity matching. The product problem was deciding what should happen when identity remained uncertain.
That distinction mattered. A stronger model might infer a likely match, but “likely” could still attach a payment to the wrong order. The buyer needed the system to show doubt, preserve the conflicting evidence, and give a person a clear decision to make.
We had spent time improving the answer. Ama was asking whether the product knew when it should stop answering.
Edge cases reveal who carries the risk
Founders often treat edge cases as rare conditions to handle after launch. Buyers experience them differently. The awkward case is usually where their money, reputation, or customer relationship becomes exposed.
Ama did not care that the assistant handled the normal order in seconds. Her staff could already process a normal order. She cared about the afternoon when two credible records pointed to different customers and somebody had to release the goods.
This is why a buyer’s difficult question can be more valuable than praise after a demo. Praise tells you the path was understandable. The difficult question identifies where the buyer expects to carry the consequences of your product’s decision.
I have seen the same mistake while building automation across African, European, and US contexts. A workflow can look complete because every screen connects. Then a founder in Lagos asks what happens during an unstable connection, a German operator asks where a decision came from, or a US buyer asks which employee can reverse it. The visible feature stays the same. The operating assumptions change.
The useful response is rarely to promise that the AI will “handle it.” That phrase hides the decision the team still has to make.
The right turn was a smaller promise
With the meeting close to ending, the product lead reopened the transaction view. Instead of defending the output, he walked through the evidence the system had used and marked the point where it had guessed.
Then he changed the promise.
The assistant would suggest a match when the evidence aligned. When payment, contact, and delivery details conflicted, it would hold the order for review and show the operator exactly what needed confirmation. The team had not built that path yet, so he said so.
Ama did not approve the partnership in that moment. The risk was still live. But the conversation moved from whether the AI was impressive to whether the proposed control matched how her staff worked.
That was the first useful product discussion of the meeting.
The pattern resembles the choice in AI Product Validation: What Ruth’s Refusal Taught Daniel About Building for Demand. Refusal and difficult questions remove the comfort of imagined demand. They force the founder to decide what the product must do before someone can depend on it.
Bring the awkward transaction into the next demo
Before the next build, the team wrote Ama’s scenario at the top of the acceptance notes. They added two more cases from her notebook, each involving conflicting information and a decision that could not safely be automated.
The demo became less theatrical. It showed a clean order, an uncertain order, and the point where a person took over. That sequence explained the product more honestly than the original presentation because the buyer could see both its capability and its boundary.
When I review an AI demo now, I want one normal path and one case that could cause a real loss. I ask who notices the conflict, what evidence they receive, and whether they can reverse the decision. If the only answer is that the model will become more accurate, the product decision remains unfinished.
Ama returned for the revised demonstration. This time, she changed one customer detail midway through the order. The assistant paused, displayed the conflict, and asked for confirmation.
She put down her notebook. The room finally understood the buyer the product had to serve.
Comments
No comments yet.