METIS LABS
A status report tells you how busy your supplier has been, which is not the same as telling you whether your project is working. Here is why we replaced ours with a working demo every week, and what that costs us when the week has gone badly.
Every software supplier has a way of telling you how things are going, and usually it is a document. It arrives on a Friday. It has a red, amber or green square near the top. It describes work: tickets moved, items in progress, points completed, risks noted. It is quick to produce, it is easy to read, and it can be entirely accurate while telling you almost nothing about whether the thing you are paying for is going to work.
We do not send them. Once a week, at a fixed time, we show you the software running. Not slides about the software, not a recorded walkthrough, the actual thing, on a screen, with someone from our team clicking through it while you watch. If a feature is half built, you see it half built. If the week produced nothing worth showing, you see that too, and we have to say why out loud.
What a status report actually measures
A report measures effort. It can be green for six weeks in a row while the project quietly goes wrong, because everything it describes is true: people did work, tickets did move, the plan was followed. None of that is evidence that the software does the job. Effort and outcome come apart all the time, and the report is not built to notice when they do.
It also puts distance between the person writing and the person reading. The writer chooses which facts go in and which words describe them. "Integration in progress" covers a component half finished and a component that has not been started. Nobody is lying. The format simply allows an honest person to be vague, and vagueness accumulates until the month before launch, when it stops being possible.
And it invites the wrong vocabulary. Story points, burndown, velocity, capacity. Those are measures of how busy we are, and we have argued before that the only figure worth reporting is one that belongs to you, agreed before anyone writes code. We covered that in Set the number before you write the code. The demo is the other half of the same idea: the number tells you whether the project is winning, and the demo shows you the thing the number is describing.
What a demo forces
You cannot demo software that does not run. That sounds obvious, and it is the entire point. A weekly demo means the system has to be in a runnable state fifty-two times a year, which quietly kills the failure mode where three developers build in parallel for two months and discover in week nine that the pieces do not fit. On Brandhub, a platform we have been building for about twenty-two months, that is roughly ninety of these, and every one of them was a small integration check that did not turn into a large one.
It also changes who spots the problem. When you watch someone use the thing, you notice what a document cannot carry: the step that takes four clicks and should take one, the wording that means something different in your industry, the case nobody thought to ask about. You notice it in week six, when it is a conversation, rather than in user testing, when it is a change request.
A few rules we hold to about the demo:
- It runs on a real environment, not a laptop. Software that only works on the machine of the person presenting it is not evidence of anything. If it cannot survive being deployed, we have not finished.
- We show the week we had, not the week we wanted. No hiding a broken screen by demoing around it. If something regressed, it goes in the demo, and we say what we are doing about it.
- The agreed number comes with it. Every demo ends with where that figure stands. A good-looking demo and a flat number is a conversation we would rather have in week eight than in month six.
- You drive, at least sometimes. We hand over and let you click. It is the fastest way to find out whether something is actually usable, as opposed to demonstrable by the person who built it.
What it costs us
It is more expensive than writing a document, and we should be honest about that. Keeping a system permanently demonstrable is real engineering work: environments that stay current, data that looks like yours, a build that does not fall over on a Thursday afternoon. Some of that time would otherwise go into features.
The harder cost is the bad week. Sometimes a demo is four minutes long because a difficult problem swallowed the sprint, and someone has to stand up and show a client very little. A status report would have absorbed that comfortably. Amber, some careful sentences, on we go. The demo does not let you. That discomfort is doing something useful, because it means a bad week gets discussed while it is one bad week, but nobody enjoys it, and pretending otherwise would be dishonest.
It also removes an option we might sometimes want, which is to look better than we are. We think that is a good trade. A client who has watched the software every week is not surprised at the end, and a project without surprises at the end tends to be a project that finishes.
Ask to see it running
You do not need to work with us to get the benefit of this. If you are commissioning software from anyone, ask to see it running every week, from the first week, on an environment that is not a developer's laptop. Then watch what happens to the answer.
A supplier who is building well will find the request easy, and will probably be glad of it. A supplier who hesitates, or offers a recording, or suggests a fortnightly walkthrough deck instead, is telling you something worth knowing early. The request costs you nothing and it surfaces the answer in days rather than quarters.
If you want to see what this looks like in practice before deciding anything, ask us for a demo of something we are building and we will show you a real one, unpolished. Open a conversation and tell us what you are trying to build. We would rather show you a working screen than send you a document about one.