A packed room can prove that a demo is understandable, surprising and easy to applaud. It cannot prove that people will return when the lights are off, the founder has stopped narrating and Monday asks them to use the product again.
In June 2012, Sergey Brin stood onstage at Google I/O in San Francisco wearing Google Glass. The presentation cut to skydivers above the city, each using Glass to share a live view of the jump. The feed continued through a rooftop landing, a bicycle ride and a descent into the conference hall.
The room had every reason to react. A computer worn like a pair of glasses had moved from a laboratory idea to a live spectacle. Google had demonstrated technical possibility in public, with the company’s co-founder guiding the story.
One question remained unanswered: what would a person need Glass for on an ordinary Monday?
The demo compressed the product’s strongest moment
The Google I/O presentation put Glass inside a carefully chosen situation. Hands-free video mattered during a skydive. The wearer had something unusual to show, and the audience immediately understood why a first-person camera was useful.
Daily use created a harder test.
Glass entered an Explorer programme in 2013, available to selected users at $1,500. Once the product left the stage, buyers had to make a series of decisions the demo had skipped. They had to decide where wearing it felt acceptable, which tasks deserved a computer near the eye, how often those tasks occurred and whether the benefit outweighed the attention the device attracted.
Google stopped selling the original consumer version in 2015. Steven Levy later documented the product’s troubled path and its second life in workplaces for Wired. The technology had worked. The public demonstration had worked. Repeated consumer use remained unresolved.
That distinction matters when a founder leaves a Friday product review with funding approval nearly secured. The room’s reaction is evidence, but it is evidence about the room.
Applause answers a narrower question
A good demo usually removes friction that the real product still contains.
The founder chooses the account. The data is clean. The user takes the expected path. The difficult edge case sits outside the frame. When the prototype hesitates, the founder explains what will happen after the next build.
None of this makes the demo dishonest. A prototype needs boundaries. The mistake comes when we treat the audience’s response as proof of behaviour the session never measured.
An investor leaning forward may mean the problem is legible. A product lead asking for access may mean the workflow feels relevant. A round of applause may mean the final reveal landed.
Return behaviour needs different evidence.
Will a player open the product without a meeting on the calendar? Will they complete the core action when nobody explains the interface? Will they come back after the novelty has worn off? If the product disappears for a week, will anyone ask where it went?
These questions are closer to the work in AI Product Validation: What Ada’s Monday Taught Femi About Building the Right Workflow. The useful signal often arrives after the presentation, when a person has to fit the product into an existing day.
Protect Monday before accepting Friday’s verdict
After a strong review, I would resist adding features requested in the room. First, I would turn the strongest claim from the demo into a return test.
Give a small group access without a live walkthrough. Define the action that represents real value before looking at the results. Then choose a return window that matches the product’s natural rhythm. A daily operations tool should earn another use quickly. A product tied to payroll, reporting or a monthly decision needs a different window.
Watch what people do after the first successful session. A second login alone may reveal little. Look for a repeated valuable action: another workflow completed, another match started, another report generated or another teammate invited because the first user needed them there.
Then speak to the people who did not return. Ask what they did instead. That answer exposes the actual competitor, which may be a spreadsheet, WhatsApp, an existing game, a colleague or no action at all.
For an early-stage team with limited runway, this separation protects the roadmap. Kelechi’s three working features and six-week constraint capture the same pressure: several things can work while only one deserves the next build cycle.
Funding should follow the evidence you have
The Friday review can still support a decision. It may justify a short validation sprint, access to more users or enough budget to make the prototype testable without the founder in the room.
It should not silently become proof of retention.
Google Glass eventually found a more specific direction in workplace use, where hands-free information could support defined tasks. The second act mattered because the context became narrower and the job became clearer. The spectacle had shown what the hardware could do. The later work had to discover where people had a reason to keep using it.
Before the funding conversation closes, write down exactly what Friday proved. Then write down what Monday must prove. Give the next tranche of time or money to that test, and let repeat behaviour make the call the room could not.
Comments
No comments yet.