The best demo feature can still be the wrong product choice when it assumes devices, data, language, or habits that customers do not have. A founder should judge a feature by whether people in the target market can use it reliably, not by how strongly it impresses investors.
At 4:40 p.m. in a small Accra meeting room, Abena was holding her phone above a laptop while three investors watched her product identify stock items through the camera. Abena is an invented composite, a founder building inventory software for independent retailers. The camera feature produced the moment everyone remembered.
Then she deleted it.
The feature that won the room
The demo looked good because the conditions were unusually kind. The laptop had a stable connection. The phone camera was clear. Every product label faced forward, and Abena already knew which items the model recognised.
One investor asked whether the camera could become the centre of the product. Another wanted it highlighted in the next fundraising conversation. Abena understood why. A screen that fills itself appears more ambitious than a shopkeeper typing quantities into a plain form.
Her actual concern sat outside that room.
Two days earlier, she had watched Efua, another invented composite, try the same feature behind the counter of her provisions shop in Kumasi. Efua held an older phone in one hand while moving a box away from a leaking refrigerator with the other. The camera failed to read a faded label. She tried again, then switched off mobile data because her remaining bundle had to last.
The third attempt returned the wrong item.
If Efua trusted that result, her stock count would be wrong before the week began. If she stopped to correct every uncertain match, the feature would save her nothing. The more serious risk was quieter: she might decide the whole product had been built for a different kind of shop.
Abena had runway tied up in the demo and a funding conversation approaching. Removing its strongest visual moment could make the product look less advanced at exactly the wrong time.
For a day, she left the feature in.
A demo rewards possibility, while a market tests repetition
Investor praise answered one useful question: could the feature make the product feel technically interesting?
Efua’s counter answered another: would she use it on a difficult Tuesday, with poor lighting, an interrupted connection, and customers waiting?
Abena reviewed the decision by following the work after the camera result. A correct scan still needed a quantity, a confirmation, and sometimes a correction. A wrong scan created extra work and reduced trust in the next one. The feature compressed the first few seconds of data entry, then placed more uncertainty into the rest of the task.
That trade could improve with better models, more training data, or narrower product categories. None of those improvements would arrive before her next release.
She faced a familiar early-stage choice. Keep the feature that sold the future, or protect the workflow customers could complete now.
This is where product judgment becomes harder than product ambition. The impressive feature may deserve a place on the roadmap. Shipping it today can still be the wrong call.
A similar tension appears when a team mistakes visible AI capability for validated demand. Ruth’s refusal exposed that gap before Daniel built further. In both cases, the useful signal came from what the customer declined to do.
Deleting code can preserve the product
With the investor review approaching, Abena removed camera capture from the primary flow. She kept a record of the tests and failure cases, then replaced the opening screen with three large actions: add stock, record a sale, correct a quantity.
The revised demo had no reveal. It showed a retailer completing the full job.
That distinction mattered. Abena could now explain exactly what the product supported under ordinary conditions and where the camera experiment had failed. She was giving up spectacle, but she was no longer asking a fragile feature to carry the credibility of the entire product.
Deleting it also changed the team’s next question. They stopped asking how to improve recognition accuracy in the abstract. They started asking which repeated entries caused enough frustration to justify another attempt, and what fallback Efua needed when recognition failed.
That is a narrower problem. It is also one a small team can test without pretending the surrounding constraints have disappeared.
The lesson applies beyond AI. A founder in Lagos, Berlin, or New York can build for the device, connection, and working habits imagined in a review room. The market often presents a rougher version of the task. Geography changes some constraints, but every product eventually meets the conditions its demo removed.
The next review starts with the hardest conditions
A week later, Abena returned to the same meeting room. This time, she placed the older phone beside her laptop before the review began.
She showed the failed recognition examples first. Then she opened the simpler flow and completed the stock update without changing devices or explaining away an error. The product looked smaller on the screen and more dependable in the hands of the person expected to use it.
Efua’s next attempt ended differently too. She entered the item, changed the quantity, and put the phone down before the customer at the counter finished paying.
The camera feature remained in Abena’s notes, waiting for stronger evidence. The release went out without it.
At your next product review, bring the weakest connection, the oldest supported device, and the least forgiving customer workflow into the room. If the best feature cannot survive those conditions, remove it before customers have to.
Comments
No comments yet.