Let the Builder Drive the Demo, Let the PM Run the Room
TL;DR: For client walkthroughs, the person who built the product should drive the screens so the client sees the real work and not a secondhand retelling, while the project manager runs the room: time, questions, agreements and follow-ups. Plans should mark which sessions need a builder and be scheduled around that person, not around the room, so nobody lands in a dawn slot by accident. When you need a builder at an awkward hour, ask them once, accept the yes and never ask again, because asking twice uses up goodwill.
Iâve come to a simple rule for client walkthroughs: the person who built it drives the demo, and I, as the project manager, run the room. It sounds like a small matter of who sits where. In practice it decides whether the client sees the real thing or a retelling of it, and whether your best people are still willing to show up next time.
The clientâs clock is the clock
Clients tend to expect the vendor to work on the clientâs hours. Thatâs normal, and I donât argue with it. It does mean the vendor team has to manage its own time, because nobody else will.
In practice this shows up in where sessions land. Client meetings tend to fall in the clientâs afternoon. For part of my team, that afternoon is the middle of the night. A two-hour workshop the client books for mid-afternoon their time becomes a two-hour session at dawn for an engineer on the other side of the world.
I learned how easy that is to miss. A draft message once very nearly put an engineer into a dawn slot without anyone noticing. Someone stopped and did the time-zone arithmetic before it went out, and thatâs the only reason it got caught. Nothing in the process would have caught it. One person happened to check the maths.
So the first problem is scheduling, and it comes before any question of who drives the demo.
Say in the plan which sessions need a builder
Most client meetings donât need the people who built the product. Status updates, scope conversations and routine check-ins can run without them. Some sessions do need them: a walkthrough, a workshop, anything where the client will look at the actual screens and ask how things work.
My rule now is to write it into the plan. Next to each important session, the plan says whether a builder has to be there. Once thatâs written down, the scheduling question changes. You stop asking âwhen is the room free?â and start asking âwhen can this person realistically be there?â
That difference matters. If you schedule around the room, the builder gets whatever slot is left, and the slot left is often the one at dawn. If you schedule around the person, you see the cost before you commit to it. Sometimes you still choose the dawn slot. But you choose it on purpose, with the personâs agreement, and not by accident in a calendar invite.
The builder drives the screens
When a builder is in the session, they drive. They share the screen, click through the flows, and answer the questions about how it works.
I donât relay demonstrations any more. When someone who didnât build the thing walks the client through it, the client is watching a paraphrase. Itâs the same failure as paraphrasing a quote. Each step loses a little of the meaning: the reason a screen works the way it does, the edge case the builder already handled, the honest answer to âwhat happens ifâŚâ. The person relaying canât supply those, because they werenât there when the decisions were made.
The builder can. When a client asks something unexpected, the builder answers from the work itself and doesnât have to guess what the work does. I donât have a better reason than that for putting the builder in the driving seat. The client gets the product from the person who made it.
The project manager runs the room
Driving the screens is one job. Running the room is another, and the builder shouldnât have to do both.
As the project manager, I own the session. I open it, keep it to time, track the questions, steer the discussion back when it drifts, note what was agreed and handle the follow-ups. The builder can then concentrate on showing the work and answering about it, without also watching the clock and the agenda.
I learned this from the head of the firm I was delivering for, who put it to me in a single line before a walkthrough: âHe drives the screens, you run the room.â Itâs short on purpose. It tells each person what they own and what they donât. Nobody stands in for anyone else, and nobody covers both jobs.
Ask once, get a yes, and stop asking
The third part is the one Iâd most like other managers to take on board.
When a session needs a builder at an awkward hour, the ask should be made directly, once, and not taken for granted. In our case the head of the firm asked the engineer himself whether he would drive the screens for the walkthrough. He agreed in one word, and that settled it.
The instruction to me came with it: do not ask him a second time. So I didnât. No follow-up message, no âjust confirmingâ note the day before.
The reason is simple. A dawn slot agreed to once is goodwill. The same request made twice is a cost. The second ask suggests you didnât trust the first answer. It makes the person spend a moment deciding all over again whether to give up their early morning. It turns a favour into an obligation that keeps getting re-checked. Goodwill is limited, and repeating the request is a reliable way to use it up.
Putting it together
My approach comes down to three habits:
- Say in the plan which sessions need a builder present, and schedule those around the person, not around the room.
- The person who built it drives the screens. The project manager runs the room. Donât relay a demonstration.
- Ask once, get a yes, and stop asking.
None of this is complicated. Each habit fixes a failure thatâs easy to fall into without noticing: a calendar invite that quietly costs someone their sleep, a walkthrough that turns into a secondhand summary, a request repeated until it starts to grate.
The client works to their own clock, and I accept that. Within it, I can still decide who does which job and how often I ask people for their time. The client sees the work from the person who built it, and the session runs well because someone else is running it.