When Not to Demo the Product Yet
When Not to Demo the Product Yet
There's a moment in a product evaluation when someone says, "We can show you," and the room relaxes. Showing is progress. It's concrete, and it ends the twenty minutes everyone has spent circling an abstraction.
That relaxation is the thing to distrust — not the demo, the relaxation. The question in the room was never whether something can be shown. It was whether what gets shown can carry the decision the room is about to make. Those come apart more often than teams admit, and they come apart most expensively when the demonstration is good: when the click is instant and the path from request to result is smooth enough that nobody has to imagine anything.
Demo readiness is readiness for a particular decision. It is not readiness in general, and it is not the same thing as polish. When a team asks whether the demo is ready, the honest answer is usually "ready for what?" — and that question, asked early enough, changes what the meeting should do.
Write down the sentence the room will say
Before deciding what to show, write the belief the demonstration would install. Not the meeting's topic — the sentence you want the audience to be able to say on the way out.
- "We should fund the pilot."
- "This routing model fits how we approve purchases."
- "We can move low-value orders to unattended fulfillment."
Then ask what evidence each sentence needs. Two of those may be supportable by the same prototype. The third may not be supportable by anything you currently have. Writing them out is not paperwork; it's the point at which a vague worry ("are we ready?") turns into a checkable mismatch ("this sentence needs an observation we cannot produce").
The same move works in the other direction. If the sentence is "should we explore this at all," a paper sketch may be entirely sufficient and a polished build would be effort spent on a question nobody asked. The gap between evidence and decision can run either way, and closing it can mean showing less as easily as it means showing later.
Find the gap before you name the failure
When a demo feels premature, teams usually describe the problem as the product not being finished. Sometimes that's right. More often the problem is a mismatch between the kind of claim the meeting needs and the kind of evidence the prototype produces.
A controlled path shows something specific: this sequence of states is reachable under these conditions, with sample inputs, operated by someone who knows the system. That's a real observation and often a valuable one. It is silent on reachability under other inputs, at other volumes, unattended, or after a step somewhere in the middle fails. Those aren't refinements of the same claim. They're different claims.
Walk the workflow and sort each step into three buckets. First, behavior that exists and can be exercised. Second, behavior that exists only as a proposal on a page. Third, behavior whose status is genuinely unknown because nobody has tested it. That third bucket is the one teams skip, and it matters because neither of the neighboring buckets describes it. "We haven't verified it" is not the same as "it probably works," and it is not the same as "it probably fails." Unverified is its own state, and the honest sentence for it is "we don't know yet, and here is what would tell us."
Ask separately about data, permissions, and who is doing the work. A step that looks automatic in a demonstration may depend on someone in the room pressing a button on your behalf, and the person watching from the buyer's side cannot see that. Nor can they see that the data is a curated sample, or that a permission was granted for the demo that hasn't been granted in production. None of that is dishonest. But each one changes what the audience is entitled to conclude.
Most premature demos aren't lies. They're accurate answers to a question nobody asked.
The GOV.UK Service Manual's guidance on making prototypes, published in October 2016, draws a related line: a realistic interactive prototype can differ from production in security, performance, and purpose. The manual's concern is choosing the right type of prototype for a purpose, not avoiding early work, and it is UK government service-design guidance rather than a universal commercial demo policy. For our question it earns its keep anyway, because it names the trap exactly: presentation realism is not evidence of operational readiness. A prototype can be convincing and still be a prototype.
A constructed case
The scenario below is invented to make the choice concrete. No real company, product, or evaluation is described.
Aster has built an approval router. A purchase request enters; routing rules assign it to an approver based on amount and cost center; the approver sees the request and can approve or reject it. That part runs, and it has been exercised against sample data.
What Aster does not have is a verified connection to the supplier system. After approval, the order is supposed to reach the supplier automatically, with nobody in between. That leg has not been built against any real supplier interface. There is no authorized test environment, no credentialed sandbox, and no supplier-side contact who has agreed to receive test orders.
The buyer is evaluating whether to move low-value purchases to unattended fulfillment. Their decision, stated plainly, is that requests under a threshold get approved and placed with suppliers without a person touching them. That sentence depends on routing working, the approver's screen carrying the right information, and the supplier handoff working unattended at the buyer's volumes, with the buyer's suppliers, under the buyer's exceptions.
Aster's prototype can speak to the first two. It cannot speak to the third, because the third does not exist in any environment where it could be observed. Notice what that does and does not mean. It is not evidence that the handoff will fail. It is the absence of evidence in either direction, which is a different thing and should be described as one.
Three routes, and what each costs
The routes below are compared under the same conditions — same prototype, same buyer, same meeting — because the choice is between them, not a sequence to work through.
Show the router and change the question. Aster demonstrates the approval workflow as it actually runs and asks the buyer to decide a smaller, real thing: does this routing model fit our approval policy, and does the approver's screen show what an approver needs? The meeting can produce a genuine decision and a list of corrections. What it loses is breadth — the buyer's largest question stays open — and there is a social cost worth naming before the meeting rather than inside it. Narrowing a demo reads as evasion unless the presenter says at the top, "This answers the routing question. The fulfillment question comes later, and here is why." Announced first, the narrowing is a plan. Discovered halfway through, it's a dodge.
Show the router for real, and a proposal as a proposal. The approval workflow runs live. The supplier handoff is then shown as a design — the states, the confirmation, the failure handling — drawn or described, and marked as proposed in the same frame where it appears, not in a footnote. The decision this supports is real: whether the proposed design is worth building, and what the buyer's exception cases are. What it loses is realism, and the loss is not small. A buyer can start reasoning about a proposed design as if it were a plan, which is fine, or as if it were a capability, which is not. The presenter has to hold the line when someone asks, "So it works?" The answer is "not yet, and here is what would make that answerable," said without apology. Design feedback on an unbuilt leg is valuable. It is not validation.
Defer the fulfillment portion. Aster runs the routing discussion now and moves the unattended handoff to a later session, after a named dependency is satisfied — for instance, an authorized test environment with at least one of the buyer's suppliers, credentialed, and the person who owns that supplier relationship on the call. The current meeting can still decide the routing question and can schedule an evaluation with a defined subject. What deferral loses is immediacy and the consequential observation the buyer actually came for. It also has real costs — budget cycles, internal momentum, the patience of whoever championed this — which is why it should follow an identifiable mismatch rather than a general feeling that the product is rough. "Not yet, because we cannot observe the thing you need to decide" is a defensible position. "Not yet, because it embarrasses us" is a different one, and buyers can usually tell them apart.
Why a footer label doesn't repair the picture
There is a tempting fourth move: show a polished mockup of the whole flow, end to end, and label it as a mockup in a footer.
The problem is structural rather than ethical. The reader's inference forms while the sequence plays, not when the footer arrives. By the time the label is legible, the visual has already asserted a completed handoff — approval, transmission, supplier confirmation, no hands. A caption arriving afterwards competes with a moving image of a thing happening, and it competes from behind. If the sequence looks like end-to-end operation and the label says it isn't, the sequence is doing more work. Ask what the images asserted before the caption arrived. That belief is the one that travels back to the buyer's office.
The repair isn't a louder label. It's changing what the sequence shows. Stop the visual at the boundary of what's real, put the boundary inside the frame, and let the proposed portion look like what it is — a sketch, a diagram, a described future. A demo that visibly ends where the built product ends is more persuasive about the built product, not less, because the audience stops spending attention on what might be hidden behind the smooth part.
Name the condition, not a standard of readiness
When someone asks what would make a later demo appropriate, the useful answer is specific and the useless answer is "when it's ready." A specific answer names four things: the missing observation, the environment where it could be made, the person who can authorize that environment, and the decision it would then support.
For Aster, that might sound like: we can demonstrate unattended fulfillment once we have an authorized test environment with a supplier who will receive test orders, credentialed by that supplier's integration contact, and once we've run representative orders through it and can describe what happened. That's a condition, not a threshold. It says nothing about whether the product is good. It says what would have to become observable for the buyer's original sentence to be answerable, and who has to act for that to happen.
Notice what this form avoids. It avoids a universal readiness checklist, which would be seductive and wrong — a routing decision and a fulfillment decision can share a foundation, but the observation each one turns on is different. It also avoids asking for a perfect product. The condition is tied to one claim and expires when that claim is answered.
One honest limit belongs here. This framing is a proposal about how to choose, drawn from a well-established distinction between prototype and production. It isn't a procedure validated against a documented evaluation; no customer or product evidence was examined in putting it together. Treat it as a way to structure the conversation, not as a checked method with known outcomes.
The smaller decision
For Aster and this buyer, the sensible route is the first, with the door to the third held open. Demonstrate the approval router as it runs. Ask the buyer to decide whether the routing model fits their policy and whether the approver's screen carries what it should. Name the fulfillment gap at the top of the meeting rather than at the end. Leave with an agreed condition — in writing, with an owner — for when the fulfillment question can be evaluated, and with the authorization that condition requires.
The meeting produces less than the buyer hoped for. It also produces something true: a decision about routing that rests on an observation, and a clear statement of what would have to change before the larger question becomes askable.
That trade is worth weighing every time rather than deciding once. A rough prototype in front of a real question is often exactly the right instrument. Sometimes the product really is too early, and then the work is to say so. More often, the problem is a demonstration inviting a commitment larger than anything the demonstration can establish, and the remedy is to shrink the commitment rather than inflate the evidence.
Frequently asked questions
How can a team tell whether a demo is premature?
Write the sentence the audience should be able to say on the way out, then ask what evidence that sentence needs. If the needed observation cannot be produced, the issue is a mismatch, not necessarily an unfinished product. A controlled path may support one claim while being silent on other inputs, volumes, unattended operation, or mid-step failure.
What are the three buckets for sorting workflow steps?
First, behavior that exists and can be exercised. Second, behavior that exists only as a proposal on a page. Third, behavior whose status is genuinely unknown because nobody has tested it. Unverified is its own state; it is not the same as 'it probably works' or 'it probably fails.' Ask separately about data, permissions, and who actually does the work.
What routes are available when one part of a product cannot yet be demonstrated?
Show the part that runs and change the question to a smaller real decision; show the running part live and mark the unbuilt part as a proposal in the same frame; or defer the unobservable portion until a named dependency is satisfied. Each route has costs: narrowing loses breadth and can look evasive unless announced first, proposals lose realism, and deferral loses immediacy and may carry budget or momentum costs.
Why does a footer label not repair a polished end-to-end mockup?
The audience's inference forms while the sequence plays, not when the footer arrives. By the time the label is legible, the visual has already asserted a completed handoff. Better to stop the visual at the boundary of what is real and let the proposed portion look like a sketch, diagram, or described future.
What should a condition for a later demo name?
Name the missing observation, the environment where it could be made, the person who can authorize that environment, and the decision it would then support. For the invented Aster case, that means an authorized test environment with a supplier willing to receive test orders, credentialed by that supplier's integration contact, plus representative orders run through it. The condition ties to one claim and is not a universal readiness checklist. The article also limits this framing: it is a proposal, not a procedure validated against a documented evaluation.