# A 30-minute weekly demo spares you the week-eight surprise

> It only works if the customer drives the software on real data and the session ends with an agreed change, not a presentation.

Original: https://fdetimes.net/en/guides/weekly-30-minute-customer-demo/

Picture week eight of a project. You share your screen to present a nearly finished build, and the customer's head of operations asks a question that silences the room: "Why can't it read attachments? Half our complaints come in as PDFs."

That question rarely shows that your code is bad. It shows that for seven weeks nobody on the customer's side got to touch the software. Each wrong assumption in that stretch was built on top of the one before, and by handover day fixing them is expensive.

For an FDE this is an occupational risk, not bad luck. You sit right next to the customer, where requirements can change from one week to the next, so the cheapest defence against surprises is a fixed rhythm: 30 minutes every week in which the customer gets to use what you have just built, with their own hands.

## The idea predates the FDE role

The Agile Manifesto's top priority is to satisfy the customer through early and continuous delivery of valuable software. It recommends delivering working software every couple of weeks to a couple of months, with a preference for the shorter timescale. It also treats working software, not documentation, as the primary measure of progress.

The Scrum Guide adds a point many teams skip. The purpose of the Sprint Review is to inspect the outcome and decide what to adapt next. The guide also warns that it is a working session, and that teams should avoid turning it into a presentation.

Put the two together and a real demo needs all three of: real software, the customer taking part, and an ending in a change. Missing any one of them, you are only reporting.

## Why 30 minutes, and why every week?

The Scrum Guide caps the Sprint Review at four hours for a one-month Sprint. Scaled down, a one-week cycle needs only about a quarter of that. Thirty minutes is lighter still: a slot that fits in a customer's calendar without anyone having to ask their manager.

The Agile Manifesto wants business people and developers to work together daily throughout the project. On a customer site that is often hard, because the real users are busy with their actual jobs. The weekly demo is the minimum contact pinned into the calendar: even if you don't meet all week, you are guaranteed one round of feedback.

The rhythm also suits teams running longer sprints. PostHog's FDE team works in two-week sprints, from Monday of one week to Friday of the next. With a weekly demo you get one check mid-sprint, while there is still time to change direction, and another at the end.

## A sample demo, minute by minute

Say you are deploying an agent that triages complaint emails for the customer service department of an insurance company. Before writing the first line of code, do what PostHog's FDE team does: write the scope up as a short brief and send it to the customer for sign-off before committing. That brief is the yardstick for every demo that follows.

| Minute | Activity | Who holds the mouse |
|---|---|---|
| 0–3 | Restate the week's goal from the brief and last week's decisions | FDE |
| 3–18 | The customer runs 5 real emails taken from their own inbox | Customer-side user |
| 18–25 | Questions, pointing out what's wrong, prioritising together | Both sides |
| 25–30 | Read the decisions aloud, agree next week's work | FDE |

The most important part is minutes 3 to 18. You don't perform. You say: "Could you pick the five hardest emails from this week and paste them in here?" When the agent misclassifies one, don't explain straight away. Ask: "If it were you, which category would this email go in, and what would you base that on?"

The answer to that question is the most valuable data of the week. If she says "you can tell from the attachment", you have found in week two the problem that the scenario at the top of this article had to wait until week eight to discover.

An FDE quoted by Insight Partners said a demo is worth far more than conversations. These 15 minutes show why.

The last five minutes are for reading aloud: "Next week: add a PDF-reading step, drop the 'other' category because nobody uses it, put the CRM integration on hold." Anyone who disagrees says so in the room, not later by email.

**Key point:** A demo that doesn't end with a recorded change is still just a presentation.

## Feedback only counts when it travels

Within an hour of the demo, send a recap in three parts: what the customer saw, what both sides decided, what's coming next week. If a decision moves away from the original brief, say so explicitly and ask the customer to confirm it again in writing. A small change that isn't recorded today easily becomes a surprise on handover day.

Feedback also has to reach your own product team. PostHog's FDE team sees itself as the fastest feedback loop between how customers actually use the product and the roadmap.

Insight Partners likewise stresses that the feedback loop to product has to be deliberate. A single line such as "insurance customer needs attached PDFs read", sent with each weekly recap, is exactly that deliberate work.

## Five mistakes that turn a demo into ritual

The most common mistake is showing slides instead of software. Slides only show what you intend to do; working software is the proof of progress. The second is demoing on sample data you wrote yourself: it was written to run smoothly, so it hides precisely the hard cases the customer cares about.

The third is inviting only the project sponsor and not the people who will use the system every day. The sponsor approves the direction; the users are the ones who find the bugs.

The fourth is hiding what is still broken. Showing the customer a half-finished feature is better than cancelling because "there's nothing to see this week", because one cancellation easily becomes a habit.

The last is the subtlest: the demo goes smoothly but nothing gets decided. If the recap has no entry under "decided" three weeks running, you are presenting, not working with the customer.

## Exercise: write the recap for the sample demo

Go back to the demo with the insurance company. Imagine the outcome: the team lead runs 5 emails, the agent classifies 3 correctly and gets 2 wrong, both with the complaint inside an attached PDF; nobody picks the "other" category; and she says the CRM integration isn't urgent. Set a 10-minute timer and write the three-part recap before reading on.

A passing version looks like this. Seen: 3/5 emails in the right category, both misses caused by the complaint being in a PDF. Decided: add a PDF-reading step, drop the "other" category, defer CRM until later. Next week: rerun these same 5 emails plus 5 new ones with attachments.

Then grade your own version with three questions. Which decision moves away from the brief, and is there a line asking the customer to reconfirm it? Which line needs to go to the product team? Would someone who wasn't at the demo understand what will be shown next week?

## Turning the demo rhythm into a job-search advantage

If you want to show that you can iterate quickly with customers, not just write code, don't put "good communication with customers" on your CV.

Instead, write one line that says what you did and where it led, for example: "Ran 30-minute weekly demos with end users; caught a scope change in week two and reconfirmed the brief in writing."

Before an interview, have a concrete story ready about a time feedback in a demo made you change direction. When reading a job description, look for the passages about working directly with customers: that is where this story is worth telling.

You don't need anyone's permission to start. Set up a recurring 30-minute meeting, invite the people who will use the system, and let them hold the mouse. The PDF question will come one way or another, and it is best to hear it in week two.

**Try this week:**

- Book a fixed 30-minute weekly slot with your current customer, and invite at least one person who will use the system every day
- Write the 0-3-18-25-30 minute agenda for the first session, and pick 5 real cases from the customer's data for them to run themselves
- Do the recap exercise in this article for the sample demo, then use the same three-part format for your first real demo, sent within an hour

## Sources

- [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html)

- [Scrum Guide | Scrum Guides](https://scrumguides.org/scrum-guide.html)

- [How forward deployed engineers work - Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work)

- [A day in the life: How four companies run FDE motions](https://www.insightpartners.com/ideas/a-day-in-the-life-how-four-companies-run-fde-motions/)