Demos during development: what to show before it’s done without getting a new spec
The customer was shown an interim version — and came back with twenty remarks, half of them new wishes. A couple of weeks later nobody wants to hold a demo any more: “they’ll just expand the task again”.
An interim demo exists for one thing: finding the gap between what is being built and what is needed while fixing it is still cheap. Not for approval, not for a progress report, and not for collecting new ideas. When the purpose gets swapped, the demo starts working against the task: it gathers wishes, inflates the scope, and within a couple of iterations becomes a meeting everyone wants to cancel.
What to show
The temptation is to show what already looks good. It is more useful to show where the risk of getting it wrong is highest.
- A whole scenario, not a perfect fragment. A rough path from start to finish tests understanding better than a polished first screen.
- The places where the spec relied on assumptions. A demo is the best moment to check them with people who know the answer.
- Exceptions, not just the main flow. “Here is what happens if the warehouse doesn’t respond” draws more useful reactions than a fifth run of the happy path.
- Data that looks real. With “Test Testerson” and three records nobody sees long names, empty fields, or that a list of a thousand rows is unreadable.
How to prepare
A good demo is prepared with questions, not slides. Before the meeting, write down two or three questions that need answering: “did we understand correctly that partial returns are rare?”, “are these fields enough for an operator to decide?”. Then after the demo it is clear whether the answer was obtained.
And say up front what is not ready: styling, copy, speed. Otherwise half the time goes on remarks about things that will be done anyway.
How to run it
- Let the user click. When the developer drives, everyone sees how the system behaves in the hands of someone who knows it. When the user hunts for the button, you see how it really works.
- Record reactions, not just words. A pause, a repeated question, “where is the…” — these are findings as much as a direct remark.
- Don’t argue, don’t promise. “That’s what the spec says” is useless at a demo, and “we’ll do it” is dangerous: agreement given in the meeting then has to be honoured.
No decisions are made at a demo. Every “it would be nice if…” is written down and dealt with after the meeting. One phrase does the job: “Noted — we’ll go through it and come back with a decision by Friday.” It neither refuses nor promises — and buys time to understand what exactly was asked for.
Sorting the remarks
After the demo the analyst has a list. Each remark goes into one of four buckets, and each bucket has its own path.
| Bucket | Sign | What we do |
|---|---|---|
| Deviation from the spec | The spec says one thing, the system does another | A defect in the current task, no discussion |
| Error in the spec | Built as written, but the wrong thing was written | Edit the spec under the rules for mid-flight change |
| New wish | It was in neither the request nor the need before | A separate task in the queue, priority decided by the product owner |
| Taste and styling | “Different colour”, “button further left” | To the product owner; most often after release, based on data |
The line between the second and third buckets is the same as in the piece on scope boundaries: does it make sense to ship what exists without this change? If yes, it is new work.
The outcome of the sorting goes back to the demo participants: what goes into the current task, what is moved out, and why. Without that message people leave convinced they were heard and everything will be done.
When a demo does harm
- Too early. When there is nothing to show, the audience’s imagination fills the gap — and everyone sees their own system.
- Too often. A weekly showing of one screen turns the customer into a designer and the analyst into a secretary.
- The wrong audience. Only managers, without the people who will work with the system — approval is there, a test of understanding is not.
The sign the demo lost its purpose: afterwards the task got bigger, and no questions about the spec appeared.
A fifteen-minute check
Take the remarks from the last demo and sort them into the four buckets. If more than half are new wishes, the demo came either too late or without an agreed boundary. If the first two are empty, either everything really is right, or you showed only the parts where nothing could go wrong.
What next
A demo catches the gaps you can see. The rest reach testing, and there the argument every team knows begins: is this a defect, or did the spec simply leave it unsaid?