A working demo proves that the technology can answer a prompt. It does not prove that a specific person needs the answer badly enough to use the product on Monday.
At 11:47 PM in Lagos, the final prompt returned exactly what Femi had hoped to see. Femi is a composite founder: a backend engineer with a small SaaS product, two months of runway, and a habit of rubbing the corner of his laptop whenever a deployment is running. Around him, hackathon teams were still testing AI and digital products against real-world problems. His screen showed a clean, correct response.
For a few seconds, the decision seemed settled. Ship it.
Then one of his teammates asked, “Who sends this prompt on Monday morning?”
Nobody answered.
The question the demo could not answer
Femi’s prototype helped small distributors turn loosely written stock updates into structured purchase suggestions. A shop manager could describe what had sold, what remained, and what might run out. The model returned a proposed order.
The technical challenge had been difficult enough to feel meaningful. They had changed the prompt several times, cleaned up inconsistent inputs, and added a check to stop the model from inventing missing quantities. When the last test passed, the team had evidence that the workflow could run.
They still had no evidence that a distributor would trust it with an actual order.
That distinction threatened the next eight weeks. Femi could put his remaining cash into improving the interface and hiring a contract engineer. If demand never appeared, he would reach the end of his runway with a polished product built around an assumption. He could also stop development and spend Monday interviewing distributors. That choice felt slower, especially after a night when the software had finally behaved.
This is the dangerous moment in an AI product. The output looks intelligent, so the business begins to feel intelligent too.
I have shipped enough product to know how quickly that feeling can take over. A prompt works. A teammate records the screen. Someone says the demo will be stronger once the dashboard is cleaner. Within a week, the team is discussing authentication, billing, and model costs before anyone has named the person whose existing behaviour must change.
Monday belongs to the current workflow
At 8:36 on Monday morning, Femi sat across from Ada, another composite character, in the back room of a small distribution business in Lagos. A ruled notebook lay open beside her phone. She did not begin her day by composing a stock summary for an AI system.
She checked messages from shop owners, compared them with notes from the previous week, and called one buyer whose request was unclear. One supplier had changed what was available. Another customer still owed money. The order was partly a stock decision, partly a credit decision, and partly Ada remembering which shop usually asked for more goods after the weekend.
Femi’s demo had modelled the written request. It had missed the judgement surrounding it.
Ada could imagine using the product, but only after she had already gathered the information and resolved the uncertain parts herself. The tool sat at the end of her work, where the cost of another step was obvious and the benefit was still vague.
The bad ending was now concrete. Femi could spend his runway making the recommendation more accurate while Ada continued using her notebook and phone. His product would improve without moving any closer to her Monday.
This pattern also appears when a demo assumes the important data is waiting in one tidy system. In practice, the missing context may live in a colleague’s memory or the shared spreadsheet the demo did not account for.
A smaller promise changed the product
With the runway decision still open, Femi stopped asking Ada whether she would use an AI ordering assistant. The question invited politeness and speculation. He asked her to show him the point where she lost the most time or made the hardest call.
She pointed to the messages that lacked quantities, product names, or enough context to act. Before deciding what to order, she first had to turn those messages into something she could verify.
That gave Femi a narrower job. The product would extract the request, flag what was missing, and prepare the follow-up questions. Ada would keep control of the order.
The technical ambition became smaller. The Monday value became clearer.
Femi postponed the contract engineer and spent the week testing that single handoff. He watched for a behaviour, not praise: Would Ada paste in a real message without being reminded? Would the flagged gaps save her from rereading the thread? Would she keep the output when the hackathon was over?
This was still uncertain. A useful interview can expose a better assumption, but it cannot manufacture demand. Femi now had a test that could fail before the company spent another month building around it.
What to prove after the applause
A demo should earn the next question, not the next quarter of development.
After the model works, write down one named person, one recurring moment, and one action they already take. Then identify what your product asks them to stop, start, or trust. If you cannot describe that change without saying “businesses,” “teams,” or “users,” the customer remains too abstract.
Next, test the smallest useful part inside the current workflow. Avoid asking whether someone likes the concept. Put a real task in front of them and watch what happens when you are no longer explaining every step.
By Friday afternoon, Ada’s notebook was still beside her phone. Femi had not replaced it, and he no longer claimed that he would. His product had one modest place in her morning: turning an incomplete message into the questions she needed to send back.
The 11:47 PM answer proved the model could respond. Ada’s Monday showed Femi what was worth building.
Comments
No comments yet.