A flawless demo can still reveal a failed product assumption when customers lack the connectivity, payment access, or daily workflow the product requires. The right response is to pause the launch, identify the dependency that broke, and test the customer’s real operating conditions before writing more code.
At 4:47 on a Friday afternoon in Accra, Kweku watched the final test order move across the screen exactly as designed. His AI purchasing assistant read a supplier message, matched the requested items, prepared an order, and opened the payment step without an error.
Kweku, an illustrative composite of founders I have worked around, had spent the week rehearsing this moment. Two takeaway containers sat unopened beside his laptop. His engineer had already started recording the launch video.
Then Adjoa, the shop owner invited to test it, held up her phone and asked a short question: “Can I do this when the network goes?”
The room went quiet.
The dependency hidden inside the demo
The team had tested the product on office Wi-Fi, with a founder account already connected to an online payment method. Adjoa bought from several suppliers through messages, calls, and handwritten notes. She sometimes shared a phone with the employee covering the counter. Payment could happen separately from the order, after stock had arrived and been checked.
The demo assumed stable connectivity, individual accounts, digital supplier records, and payment at checkout. None of those assumptions appeared on the roadmap. Together, they formed the product’s foundation.
Kweku tried the demo using Adjoa’s mobile connection. The product stalled while loading the supplier history. When it recovered, the payment step required an option she did not use for those purchases.
The launch was scheduled for Monday. A contractor had been booked to help onboard the first group of shops. If Kweku delayed, he would lose money the company could barely spare. If he continued, the first customers might meet a loading screen, a blocked payment step, and an ordering process that did not resemble their own.
For one uncomfortable minute, both outcomes looked expensive.
This is where founders often reach for a technical rescue. Cache more data. Add another payment provider. Compress the model response. Those changes may help, but they do not answer the larger question: did the team build around the way customers already work, or around the cleanest environment for demonstrating the software?
Test the conditions around the feature
I have learned to separate feature reliability from market reliability.
Feature reliability asks whether the AI can extract the right products, quantities, and supplier details. Market reliability asks whether the customer can reach the feature, provide what it needs, complete the next step, and recover when the process breaks.
Kweku’s extraction worked. His customer journey did not.
He closed the launch checklist and drew the ordering process as Adjoa described it. A supplier sent a message. Someone copied part of it into a notebook. Stock arrived. Another person checked the delivery. Payment followed through an existing arrangement. Responsibility moved between people, devices, and paper before the transaction was complete.
That map changed the next test. Instead of asking Adjoa to complete the polished flow, Kweku asked her to place one ordinary order while the team observed. They noted every handoff, every moment the phone changed hands, and every point where a weak connection could interrupt the task.
This resembles what Thandi’s paper notebook exposed in a hidden automation workflow. The steps outside the software can matter more than the intelligence inside it.
Change the decision before changing the code
With the weekend beginning, Kweku made a narrower call. The public launch stopped. Monday became an assisted field test with Adjoa and a small set of invited participants. The contractor’s time shifted from onboarding to observation.
The team also removed payment from the first test. That decision reduced the apparent completeness of the product, but it let them examine the core job: turning messy supplier messages into an order someone could review under ordinary working conditions.
This is a difficult trade when the demo looks good. Working software creates momentum. People have seen it, deadlines have been announced, and every delay feels like evidence that the team is moving backward.
Yet a launch can produce the wrong evidence. If customers abandon the flow because their connection drops or their purchasing process ends elsewhere, analytics may describe low demand. The actual problem sits one layer earlier: the product required conditions the market never promised to provide.
Before shipping, I now want three tests outside the happy path. Can the customer begin with the device and connection available during a normal workday? Can another person take over without losing context? Can the task finish when payment, approval, or fulfilment happens outside the product?
These questions also protect the roadmap from unverified work. Femi faced a related risk when assumptions became planned features before anyone confirmed the underlying need in his product roadmap decision.
The Monday after the cancelled launch
On Monday morning, Kweku stood beside Adjoa’s counter instead of watching sign-ups from the office. The connection dropped during an order. This time, the interruption was the test.
Adjoa reopened the draft, handed the phone to her employee, and corrected an item before sending the order through her existing channel. The workflow was less impressive than Friday’s demo. It was also closer to something she could use.
Kweku left with fewer launch screenshots and a better product boundary. The AI could prepare the order. The customer could review it. Payment could remain where it already worked until the team had evidence to move it.
At 4:47 on Friday, the team thought the remaining task was distribution. By Monday, Kweku knew the next build had to begin with the dropped connection and the phone changing hands.
Comments
No comments yet.