How to Judge a Build by Working Software, Not Status Reports

A retirement planning firm of a few dozen people kicked off with us on a Tuesday in February. On the Friday we showed them a working agent.

It was the intake agent, the one that reads the questionnaire a family fills in before a first meeting and puts what matters in front of the advisor. It was not finished, but it was running, and the people on the call could read what it produced and tell us what was wrong with it. What I said was: we promised something in a week, and we got you something in a week. The chief operating officer's reply included the words "this is really remarkable." Eleven days later the builder called it done.

Another vendor had quoted eight weeks for that same agent, and that story has its own post. This one is about what happens after the first Friday. The first demo is easy. The discipline is every one after it.

A status report is a claim

Every project produces status reports. Green, amber, red. Percent complete. They are written by the people doing the work, about the work, and they lean optimistic, because the person writing believes the slip will be caught up next week.

"Eighty percent done" describes how the builder feels. A demo describes the software. Either the brief pulls the right meetings or it does not. Either the summary names the right client or it does not. Nobody in the room has to take anyone's word for anything.

Showing working software early and often also changes what gets built in between. If you know you will be showing something working soon, you stop polishing the part nobody will see. You get the thing running end to end, ugly, first. Then you make it good, with the people who will use it watching it improve.

A lot of what I mean by Deliver Without Drama comes down to this. Drama is what happens when the first time a client sees the thing is the week it is due.

What a demo has to show

A demo can be theater too. Three rules keep it honest.

Real data. Not sample records, not a tidy test client. The firm's own records, with the missing fields, the odd naming conventions and the account that was merged twice. Sample data proves the screen. Real data proves the system.

On a larger build we are running now, an advisor portal for a wealth management firm with several hundred advisors, the plan says it outright: every screen goes live early on real data, rough, and gets refined each sprint while advisors flag what is wrong. At the start of this month the firm's own CRM data landed for the first five advisors, and the portal began showing real clients where it had shown placeholders. That is the point where feedback becomes useful, because an advisor can look at their own client and say that number is wrong. Nobody can say that about a made-up one.

Our own plan admits why this matters: we cannot know upfront whether the data we are mapping is the data we should be mapping. Only putting it in front of the people who know the clients answers that.

The person who does the work decides if it is right. Not the sponsor, and not us. The sponsor can tell you whether a brief looks impressive. Only the advisor about to walk into that meeting can tell you it missed the one thing about this family that matters. If the person who does the work is not in the demo, you are demonstrating to the wrong audience.

Running, not generated once. An agent that produced one good output on a builder's laptop has not been demonstrated. In the same portal plan, dated the first of July, we described the post-meeting agent as already producing summaries from live meeting transcripts but not yet wired to its screens or validated. That was an honest sentence and a useful warning to ourselves. Producing is not validated. Ten days later the agent was running behind its screens and checked end to end against a real meeting transcript. That is the version that counts as shown.

What the rhythm bought

By the end of April there were four working things at the retirement planning firm. A pre-meeting brief, which writes each advisor a note on who they are about to see, was one of them.

The less obvious return is where the next request comes from. When people keep watching something work on their own data, they start telling you what they would want next, in specifics, because they can now picture it. A request made in a demo meeting is worth three made in a kickoff, because the person asking has seen what the thing can and cannot do.

How to run one

Book a regular working session and keep it. Show working software whenever the build has something to show, and never cancel the session for lack of progress. A stretch with nothing to show is itself the finding, and you want to learn it in week three, not week eight.

Show it on production data, or the closest thing you are allowed to touch.

Invite the person who does the work and let them drive. Watch where they hesitate. That is your list.

Write down three things and nothing else. What they said was wrong. What they asked for next. What will be shown next.

Stop sending the status report. The demo notes are the report, and they cannot be optimistic, because everyone was there.