Lesson 4.4: Demo-driven development in the field

A regular, honest demo keeps a customer project on course. Learn to plan backwards from the next demo, run one well, handle feedback and avoid faking it.

By the end of this lesson you will be able to run a customer project around a regular rhythm of demonstrations: plan each stretch of work backwards from the next demo, prepare and give one that lands, take feedback and turn it into the next plan, and do all of this without overselling what exists. You will learn a five-part demo structure, a rehearsal checklist, a way to sort feedback into four kinds and the line between a demo and a trick. You will see three demos, one of which backfires, and use a simulator to find how often a team should demonstrate. This lesson closes Module 4, on building in the field. It brings together the thin slice and shortcuts list from 4.1, the choices of 4.2 and the careful assistants of 4.3, and it is about how you show all of it to the people who matter. You need no technical background to follow it.

In Lesson 4.1 you saw that a rough working version teaches more than a week of meetings. A demo is how you put that version in front of people. It is also the closest thing the role has to a heartbeat. A project with a demo every week or two has a pulse: the customer can see that it is alive, you can see whether you are heading in the right direction, and every few days there is a moment when a mistake becomes visible while it is still cheap. A project without that pulse can go silent for a month, and silence is where trust and direction are lost.

What a demo is, and is not

A demo is a short, scheduled showing of working software, on real or realistic data, to the people who will use it or decide about it, followed by a conversation. Three words in that sentence matter.

Working. The audience sees the software do something, not slides about what it will do. A slide can say anything. Software has to run. Scheduled. It happens on a date that everyone knows. The date creates pressure to finish something and a reason for the customer to engage. Conversation. The point is not to impress. It is to learn. A demo that produces no reaction has failed even if it ran perfectly.

It is not a sales presentation, a progress report or a proof that you are busy. It is the shortest route from your work to the customer's judgement, and the judgement is what you came for.

Planning backwards from the demo

Demo-driven development is a way of planning. Instead of listing everything that has to be built and working through it, you begin with the next demo and ask: what will the audience see that they have not seen before, and what is the smallest amount of work that makes that visible?

This changes the shape of the work in three ways.

It forces thin slices. "Show the first group of accounts on screen" is a demo goal. "Build the data layer" is not. The first needs a slice that goes through data, logic and screen, so you build one, as Lesson 4.1 advised.

It keeps the customer's priorities central. Each demo should show something the audience cares about, in their words: the list of overdue accounts they asked for, the number that was in the plan. If you cannot say why the audience will care, choose a different goal.

It gives hard work a visible form. Invisible work, such as error handling, monitoring and security, is easily postponed because nobody sees it. Make it demonstrable. Show the alert that fires when the nightly file is late. Show the quarantine list of rows that failed a check. Show the log of who accessed what. A customer who sees these trusts the system more, and you cannot quietly skip them.

A simple planning method is to write the demo goal for each of the next three demos in one sentence, then list the work needed for the first, and to leave the later ones loose, since feedback will change them. A typical sequence for the lender's reminder pilot looks like this. Demo · The audience will see · Work that makes it possible1 (week 1) · The data map and a sample of the real overdue file, with problems circled · Audit, sample, profile 2 (week 3) · Ten accounts sorted into two groups, with the proposed message for each · Thin slice end to end 3 (week 5) · The same on a full day's file, with the checks and the quarantine list · Door checks, language rule 4 (week 7) · The system running on real accounts for one team, with the control group in place · Deployment, access, review 5 (week 11) · Results against the target, and a recommendation · Measurement, review Notice that the first demo contains no software at all, only the data and the problems found. That is still a demo in the sense that matters: a real thing, shown to the people who will react.

The anatomy of a good demo

A well-run demo has five parts, and the whole should take about twenty minutes for a regular one, with at least half of that for conversation.

1. Start with the problem, in the audience's words. One minute. "Callers spend most of their day on accounts that would have paid anyway. Today I want to show you how the first group would be sorted." This reminds everyone why they are there and ties the demo to something they already care about. 2. Say what you will show, and what stage it is at. Thirty seconds. "This is a working prototype on masked real data. It does not send anything yet." Labelling the stage, as Lesson 4.1 advised, protects you from the prototype that ships. 3. Show one real flow. Five to eight minutes. Walk through a single task from the user's point of view: an account arrives, it is grouped, a message is drafted, a caller sees it. Narrate what the user is doing and why, not what the software is doing. Avoid showing every feature. One clear story beats five fragments. 4. Show something that did not work, or is not done. Two minutes. "These twelve accounts could not be dated and are set aside here for review. Language is missing for 38 per cent, so we default to Hindi." This builds trust and shows you know where the gaps are. It also prepares the audience for a later, more modest delivery than they might have imagined. 5. Ask for reactions, then for decisions. The remaining time. Begin with an open question: "What did you expect to see that you did not?" Then ask the decisions you need: "Can we move accounts that paid last month to the easy group? Who approves the first message template?"

Keep the order. Many engineers reverse it, starting with the technology and ending with the problem, and the audience is lost by the time it matters.

A twenty-minute demo built this way spends its time like this.

Rehearsal and fallbacks

Demos fail for dull reasons: a login that expired, a network that dropped, a file that had changed since last night. A little preparation removes most of them.

Rehearse once, end to end, on the real setup. Not on your laptop's quiet corner, but on the screen, network and account you will use. Time it. Freeze the data. Use a fixed, checked set of cases for the demo, so that the result you rehearsed is the result you show. A live feed can change between rehearsal and showtime. Prepare the awkward questions. List five things the audience might ask that you cannot answer well, such as "what if the file is late?" and prepare short, honest answers. Have a fallback. Record the demo flow as a short video or take screenshots of each step. If the software fails, you can continue the conversation with the recording and not lose the meeting. Check access beforehand. Log in to everything fifteen minutes before. Make sure the sound, the screen share and the invitations work. Write down what you will not show. Decide in advance what is out of scope for this demo, so that a stray question does not take you into an unready part.

Predict first: you are giving a live demo to the chief operating officer, and the screen goes blank halfway through. What do you do in the next thirty seconds? Decide before reading on.

Stay calm and say plainly what has happened: "The connection has dropped. Let me show you the same flow from a recording, and I will find out what happened afterwards." Then switch to the fallback and carry on, using the time to discuss what they have seen. Do not apologise at length, do not improvise by making the failure disappear behind a patched story, and do not blame anyone. After the meeting, send a short note with the cause and, ideally, a fix and a time you will rerun the live part. Audiences forgive a failure that is handled calmly, and often remember it as a sign of honesty. They do not forgive a failure that is hidden or, worse, faked over.

Taking feedback

The demo's value is what you hear. A good habit is to capture reactions in the customer's own words as they happen, with a colleague taking notes if possible, and to sort them afterwards into four kinds.

Bug. Something does not do what it should. Fix it, and say when. Change. The software does what was planned, but the audience wants it to behave differently. "Accounts that paid last month should be in the easy group" is a change. These are the most valuable reactions, because they are what you came to hear, and they often reveal a requirement nobody had written. New idea. Something outside the current scope. Write it in the parking lot from Lesson 2.3. Thank the person, and say it will be considered after the pilot's decision. Question about the data or the world. "Why are these accounts missing?" "How does this compare with last month?" Questions often show a missing piece of understanding in either direction. Write them down, and answer them before the next demo.

After each demo, send a one-page note within a day: what was shown, what you heard, how you sorted it, what you will do before the next demo, and what you need from the customer, with dates. The note closes the loop. A customer who sees their words turned into a plan within a day trusts the process and engages more in the next demo.

Over a project, the pattern of feedback is informative. Early demos produce many changes and new ideas, as the picture forms. Later demos should produce fewer, mostly details. If the volume of feedback is not falling, the direction is not settling, and that is a sign to go back to the problem statement and the scope.

The line between a demo and a trick

Every demo is selective: you choose what to show. Selection is fine. Deception is not, and the line is easier to cross than it looks, especially when the audience is eager and the pressure is high.

These are the common ways it happens.

Showing what does not yet exist. A screen that looks complete but is driven by a script, or numbers typed in by hand, presented as live results. Cherry-picking. Showing only the cases that work and none of the failures, so the audience thinks the success rate is much higher than it is. Using cleaner data than the real thing. A demo on tidy sample data, presented as if it represented the customer's records. Skipping the stage label. Letting the audience assume that a prototype is the finished product. Hiding the shortcuts. Not mentioning that important protections, such as retries or security, have not been built.

The rule is simple. Anything that is not real must be said to be not real, in the moment, in plain words: "These numbers are from a sample, not live", "This button is a mock-up". The shortcuts list from Lesson 4.1 is your source of honesty here: it is the record of what is not yet true.

The reasons to be strict are practical. An oversold demo creates an expectation that you will then have to meet, or disappoint. It often leads, as in Lesson 4.1, to a prototype being rushed into use. And it costs you credibility, which is the one thing a forward deployed engineer cannot afford to spend. A modest demo that is entirely true is worth more than an impressive one that is partly staged.

Worked example 1: the lender's weekly rhythm

The lender's pilot follows the five-demo plan above. The effect of each demo on the plan shows how the rhythm works.

Demo 1 shows the data map and a sample file with problems circled. The head of collections learns that language is missing for about a third of the borrowers, which she had not known. She decides, in the meeting, to treat those borrowers as a separate group. The pilot is slightly smaller and much better defined than before the demo.

Demo 2 shows ten accounts sorted into two groups, with messages. She says, "Move accounts that paid last month to the easy group, and the second group needs a call, not a message." Both are changes. The engineer builds them in two days and shows them at the start of demo 3.

By demo 4 the system runs on real accounts for one team of twelve callers, with a control group. The callers themselves, who attend for the first time, say the message wording is too formal. The engineer changes it with the compliance officer's approval. Feedback has fallen from fourteen items to five.

Without the demos, each of these corrections would have arrived in a single review at the end of the project, when changing them would have cost weeks.

Worked example 2: the executive demo

The chief operating officer of the hospital group asks for ten minutes in a busy week. The engineer treats it as a different kind of demo. An executive does not want the flow of a tool. They want to know whether it works, whether it is on track and what they must decide.

The script has four steps. First, one sentence of the problem: "Bed managers spend a median of 18 minutes finding a bed." Second, thirty seconds on the screen: free beds across two hospitals, live. Third, the measured result so far: 9 minutes in the pilot hospitals and 17 elsewhere, with the accuracy check at 96 per cent. Fourth, the single decision: "I would like your approval to add the next two hospitals, which needs an hour from each hospital's IT lead."

The engineer prepares a recording in case the live screen fails, and a one-page note to leave behind. The meeting takes eight minutes and ends with the approval. The demo worked because it was fitted to the audience: results and a decision, not features.

Worked example 3: the demo that oversold

A sales team brings a prospect, a large bank, to see a support assistant. The engineer is asked to demo it live. To make it impressive, the engineer uses a hand-picked set of twenty questions that the assistant answers well, and a knowledge base cleaned for the occasion. Nothing is said about either. The prospect is delighted and signs a pilot with a target of 95 per cent of questions answered correctly.

In the pilot, on the bank's real questions and real documents, the first measured result is 71 per cent. The documents are out of date in places, the questions are messier, and several fall outside the scope of the help pages. The bank's sponsor feels misled. The engineer and the sales team spend six weeks improving the system, and the relationship is strained throughout, even though the final score reaches 90 per cent and the pilot is extended.

Nothing the engineer showed was false in the narrowest sense. What caused the damage was the unspoken: that the questions were chosen and the documents tidied. A single sentence in the demo, "these are twenty selected questions on cleaned pages, and I would expect lower on real traffic", would have set a realistic target and saved six weeks.

The pattern of feedback is worth a closer look, because it tells you whether you are converging. If each demo draws a fixed share fewer items than the last, you can estimate how many demos it takes to settle. Set the first demo's count, how fast it falls and the level you would call settled.

At the defaults, fourteen items falling by 30 per cent a demo reach three items at about the fifth demo, which matches the shape of the chart above.

How often should you demo?

A demo costs effort: preparation, rehearsal, the meeting and the follow-up. It also saves effort, by catching wrong turns early. The right frequency balances the two. Too rare and a wrong direction runs for a long time before anyone sees it. Too frequent and the team spends its time preparing instead of building.

You can see the balance in a simple model. Suppose the team makes some number of decisions about direction each month, and some share of them turn out wrong. A wrong one wastes part of the team's effort until the next demo shows it, which is on average half the gap between demos. Each demo also costs a fixed amount of preparation. Adding the two shows a total that falls and then rises as the gap between demos grows, with a lowest point in between.

The simulator below does the sum. Set the length of the project, the number of direction decisions a month, the share that turn out wrong, the share of effort wasted while a wrong one runs and the days of team effort each demo takes to prepare. It shows the waste and the preparation cost at the gap you choose, and the gap that gives the lowest total. All the figures are estimates and the model is simple, but the U-shape is real: it explains why most teams settle on a demo every one to two weeks.

Try three experiments. First, keep the defaults and look at the best gap. Second, raise the share of decisions that turn out wrong from 30 to 60 per cent, which describes a project in unfamiliar territory, and see the best gap shorten. Third, raise the days to prepare a demo to three and see the best gap lengthen. A team that makes demos cheap can afford to give them often.

At the defaults, a two-week gap costs about 1.6 team-weeks of waste plus 1.2 of preparation, 2.8 in all, and the best gap is about 1.7 weeks. A weekly demo costs 3.2 and a three-weekly one 3.2, so the two-week rhythm sits near the bottom of a shallow curve. The message is practical: the exact number is less important than having one, and keeping the cost of each demo low so that you can afford it.

Common mistakes

No rhythm. Weeks of silence, then a big reveal. Fix a regular date and keep it. Planning by components. Plan by what the audience will see next, and build thin slices to show it. Starting with the technology. Open with the problem in the audience's words, and show one real flow. No stage label. Say what the audience is looking at: prototype, pilot or production. Hiding what does not work. Show a failure or a gap. It builds trust and sets honest expectations. No rehearsal or fallback. Rehearse on the real setup, freeze the data and keep a recording ready. Losing the feedback. Capture it in the customer's words, sort it, and send a note within a day. Staging it. Say plainly anything that is not real: sample data, selected cases, mock-ups. Demoing to the wrong audience in the wrong way. An executive wants results and a decision. Users want a flow they can try.

Key takeaways

A regular demo is the heartbeat of a customer project: it shows life, shows direction and makes mistakes visible while they are cheap. Plan backwards from the next demo, asking what the audience will see and what is the smallest slice that shows it. Make invisible work, such as alerts and logs, demonstrable. Use five parts: the problem in the audience's words, what you will show and its stage, one real flow, something that did not work and an ask for reactions and decisions. Rehearse on the real setup, freeze the data, prepare awkward questions and keep a recording as a fallback. Sort feedback into bugs, changes, new ideas and questions, and send a one-page note within a day. Falling feedback shows the direction is settling. A demo selects, but never deceives. Say plainly what is not real. An honest, modest demo is worth more than an impressive one that is staged.

Check yourself

1. Name the five parts of a good demo, in order. The problem in the audience's words, what you will show and its stage, one real flow, something that did not work or is not done, and an ask for reactions and decisions. 2. Your live screen goes blank halfway through a demo for an executive. What do you do? Say plainly what happened, switch to a recording or screenshots, continue the conversation and follow up with the cause and a fix. Do not hide the failure or improvise a false story. 3. What are the four kinds of feedback, and which are usually the most valuable? Bugs, changes, new ideas and questions. Changes are usually the most valuable, because they reveal requirements nobody had written. 4. A project lasts 12 weeks. Each demo needs 1 team-day to prepare. How many team-weeks go on preparation with a demo every 2 weeks? 6 demos at 1 day each is 6 days, which is 1.2 team-weeks (using a 5-day week). 5. Why is "these are twenty selected questions on cleaned pages" worth saying in a demo? It tells the audience the result is better than real traffic will be, which sets realistic expectations and avoids a damaging gap later.

Try this

This exercise takes about forty minutes and gives you a demo plan and a first demo. Use any small project, even a spreadsheet or script from Lesson 4.1.

1. Write a demo goal in one sentence: what will a particular person see that they have not seen before, and why will they care? 2. Plan the next three demos in one sentence each. List the work needed for only the first. 3. Write the five-part script in a few lines each: the problem in their words, the stage, the flow, something unfinished and the questions you will ask. 4. Rehearse it once aloud and time it. Cut it to twenty minutes or less, with half for conversation. 5. Prepare a fallback: three screenshots or a short recording of the flow. 6. Give the demo to one real person. Take notes in their words. 7. Sort the notes into bugs, changes, new ideas and questions. Write a one-page follow-up with what you will do before the next demo. 8. Use the simulator to work out the best gap between demos for a project like yours.

A good result is a demo plan, a script, a fallback, a sorted feedback list and a follow-up note. It also completes Module 4: you can now build a rough version fast, decide what to build, put a language model to work responsibly and show it honestly. Module 5 turns to deploying and operating what you have built.

Sources

The three demos, the five-demo plan, the feedback counts and the simulator's figures are the author's illustrations for teaching, not data from real projects. The five-part demo structure, the rehearsal checklist and the four kinds of feedback are practical methods written for this lesson, not industry standards.

Tags: Forward Deployed Engineer Demos Customer communication Project delivery Beginner