A single physical action can carry more weight than a flawless AI conversation when it proves the part investors still doubt. The better demo shows the hardest capability working under real conditions, even if everything around it remains rough.
At 11:40 p.m. in Accra, Malik stood beside a folding table holding a dented cardboard box. He had one investor meeting the next morning, a robot arm that had completed the movement once, and a conversational interface polished enough to answer every predictable question.
Malik is a composite, but the decision is familiar. His two-person team had spent weeks making the system explain what it could see, describe what it planned to do, and respond in a calm voice. Investors had already seen dozens of AI products speak with confidence. What they had not seen was Malik’s machine reach across an untidy table, adjust its grip, and lift a box whose position had changed.
He could spend the remaining hours protecting the conversation demo. Or he could risk exposing the physical action that still failed more often than he wanted.
The polished demo was proving the familiar part
The conversational interface looked ready. Malik could ask, “What is in front of you?” and receive a precise answer. He could tell the system to explain its next move, interrupt it, then ask why it had chosen that route.
The exchange felt impressive for about thirty seconds.
Then it began to feel familiar.
This is one of the harder product decisions in the current AI cycle. A team can spend its limited runway polishing the layer people understand because that layer produces a dependable presentation. The demo runs cleanly. Nobody watches an error message appear. Nobody asks why the gripper closed on empty air.
Yet a safe demo may prove very little. Investors already know a language model can hold a conversation. Malik needed to show why his company existed, and the answer was sitting on the table in front of him.
The box had been moved a few centimetres from the position used during testing. Picking it up would require perception, planning, and physical execution to work together. If the arm failed in the meeting, the investor could conclude that the product was still a narrated prototype.
That conclusion might end the conversation.
One uncertain action exposed the real product
At 12:07 a.m., Malik disabled the spoken explanation.
His co-founder, Naa, moved the box again. The robot arm rotated, paused above the wrong edge, corrected itself, and lowered the gripper. One side caught. The other slipped.
The box tipped over.
For a few seconds, neither of them spoke. They had enough runway to keep building, but another month spent preparing a prettier demonstration would push customer testing further away. The next morning’s meeting could become another polite discussion about future capability, followed by no second call.
Malik put the box upright. Naa suggested constraining the demo: one object, one instruction, no conversation unless someone asked for it. They were not hiding the unfinished parts. They were choosing the smallest action that could test the central claim.
That distinction matters. Scope reduction can create evidence when it isolates the hardest uncertainty. It becomes theatre when it removes the uncertainty entirely.
The same issue appears in software products. A founder building an AI operations tool may spend days improving the chat window while the system still cannot complete one approval correctly. A product team may perfect generated CAD output before confirming that the geometry can be manufactured, the failure explored in what happens when valid CAD geometry cannot be manufactured.
A fluent explanation attracts attention. A completed job changes belief.
The demo needed a boundary, not a disguise
By 1:00 a.m., Malik and Naa had made three decisions.
The robot would pick up one box. The box could begin anywhere inside a marked area on the table. If the action failed, Malik would show the failure plainly and explain which part of the system had broken.
That final decision removed the temptation to fill uncertainty with confidence. Founders often damage a strong technical demonstration by narrating beyond the evidence. “Today it can pick up this box” becomes “soon it can handle any warehouse item.” The first statement can be observed. The second asks the room to finance an assumption.
Malik’s demo boundary gave the investor something useful to evaluate. Could the system perceive an object it had not been precisely positioned around? Could it correct its movement before contact? Could the team identify failure without pretending the failure was irrelevant?
This is also why working demos do not settle the runway question. They open the next one: what must Monday prove? The six weeks left after the demo works is often where product judgment becomes more important than presentation quality.
The morning after changed the next test
At the meeting, the arm hesitated.
It moved left, lowered, and closed around the box. The cardboard bent slightly under the grip. Then the box rose from the table.
Malik stopped there.
He did not restart the conversational sequence or pile on future use cases. He explained the marked operating area, the previous night’s failed grip, and the next test: different box shapes under the same constraints.
The action lasted seconds. It gave the meeting a different centre of gravity. The investor could question what had happened rather than debate what a polished voice claimed would happen later.
That afternoon, Malik returned to the folding table. The dented box remained useful, but it was no longer the whole test. Naa placed a narrower package beside it, outside the shape they had tuned for.
The arm moved toward it and missed.
Now they had something worth building against.
Comments
No comments yet.