An AI feature is ready when it survives a customer’s real sequence of work, including the messy inputs, handoffs and exceptions nobody included in the demo. A polished prompt set can prove the model responds well; it cannot prove the product carries the job from beginning to end.
Consider Esi, an illustrative founder in Accra, standing beside a whiteboard at 4:40 on Friday afternoon. Monday’s rollout has already been promised to the first customer. Her laptop is open to the AI assistant her two-person team has spent weeks preparing. The demo has gone cleanly every time: paste a request, get a useful draft, approve it, move on.
The customer does not begin with a clean request.
She uploads a voice-note summary, adds a spreadsheet with two columns named differently from the template, forwards an email thread, then asks the assistant to use the earlier decision from the thread before preparing the next step. The first response sounds confident. It also pulls the wrong detail from the email and treats an internal comment as an instruction.
By 5:05, Esi can see the bad ending clearly. The customer could open the tool on Monday, catch the mistake before lunch, and decide the team sold a demo instead of a working product. The promised rollout might become a repair project before anyone has learned whether the workflow is worth paying for.
The demo tested a moment, the customer tested a chain
Prepared prompts often test the most flattering version of an AI feature. They begin with the information in the right place, the task stated clearly and a person available to correct the output. That is useful during the build. It is also a narrow test.
Real work arrives in sequences. A person starts in one place, changes their mind halfway through, refers to a decision made yesterday, adds information that conflicts with what is already there, and expects the system to know when it has reached its limit.
That difference matters especially for small teams. A founder can spend a week improving the response to a single prompt, then discover the customer’s real concern sits between prompts: Who owns the approval? What happens when the source is incomplete? Where does the final output go? Can someone see why the system made that choice?
Esi’s team had built an assistant that could draft. They had not yet made the boundaries of that drafting visible. The model was doing what they had asked, but the product had not given the customer a reliable way to inspect, correct or safely continue the work.
The feature had passed the demo because the demo assumed a clean handoff. The customer’s sequence exposed that there was no handoff at all.
Friday decisions need a smaller promise
At this point, the tempting response is to keep fixing until Monday. Add another instruction. Expand the prompt. Patch the spreadsheet parser. Hope the next test holds.
Sometimes that is the right call. Often it creates a wider surface area just before the first real use.
Esi paused the rollout promise and narrowed it. On Monday, the assistant would handle one defined step: turning approved source material into a draft for review. It would not interpret forwarded email threads as instructions. It would flag missing context instead of filling the gap with a plausible answer. The customer would choose the source material, see it before generation and approve the result before it moved anywhere else.
That is a less exciting demo. It is a more honest product.
A narrower release also makes learning possible. When the AI feature handles a specific job, the team can see where the work breaks: source quality, instructions, review, ownership or output. When it claims the whole workflow, every failure arrives as a tangle.
The same tradeoff appears in broader automation work. A promise that covers every edge case can sound ambitious during a sales conversation, then leave nobody accountable for the part that fails. What Happens When Everyone Approves the Code but Nobody Owns the Workflow? is about that ownership gap from another angle.
The first customer should be part of the test
The most useful customer test is not, “Do you like this feature?” It is, “Show me the last time you did this job.”
Then follow the work in order.
Ask what they open first. Ask what they copy from another tool. Notice the moment they stop trusting the output and check a source themselves. Pay attention to the exception they describe as ordinary: the manager who changes the brief, the document that arrives late, the detail that needs approval before it reaches a client.
These are not distractions from the product. They are the product’s operating conditions.
For AI features, a good first-customer session often produces a smaller scope and a clearer decision rule. The assistant can act when the source is approved. It can draft when the task is explicit. It must ask for review when information conflicts. It should stop when the action would create a commitment that a person needs to own.
That is also why a prompt library alone rarely solves the issue. Multiple people can write prompts that work independently while nobody agrees on which instruction applies in a real workflow. What Happens When a Prompt Library Has Multiple Contributors? explores the governance problem behind that familiar mess.
Monday became a better starting point
Esi did not get the full rollout she imagined on Friday morning. She got a customer session around one smaller job, with the source material visible and a review step that made disagreement obvious.
Later that week, the customer used the assistant to prepare a draft, stopped at the approval screen, and corrected a detail before it traveled further. That correction was not a failure of the release. It was the evidence Esi had been missing: the product had created a place for human judgment instead of hiding the need for it.
The next feature should begin there. Take one customer’s actual sequence of work, run it from the first input to the final consequence, and write down every point where a person must still decide.
Comments
No comments yet.