Technote

Development workflow Practical

Series No measurement, no improvement Part 7 of 8

Put the next action next to the number

A report that changes nothing is not a report; it is a habit. One page should end in one decision.

Most people have built a careful monthly report only to have the meeting end with “thanks, very useful”. The problem is rarely effort; it is structure. A document that only lists numbers hands both interpretation and decision to the reader, and a meeting is not long enough for either.

Rewrite the purpose of a report in one sentence: after reading it, the next action is decided. Judged against that, half of most reports can go.

The shape of one page

The skeleton of a report — without the third box it is a record, not a report

The first box holds facts: figures and changes, nothing else. The second holds interpretation, and it should distinguish clearly between what was confirmed and what is a hypothesis. The third box is the reason the document exists, and it needs who, what and by when.

If the third box is hard to fill in, the metric was usually the wrong choice. Return to the question from the first part: what would you do differently if this number moved?

Fix the comparison in advance

A number on its own says nothing, so every report carries a comparison. Choose that comparison afresh each time and the report will drift, without anyone intending it, toward whichever baseline flatters.

Simply fixing the baseline in advance changes how far a report can be trusted

For a weekly business, comparing against a trailing average of several weeks is steadier. Compare against one particular week and whatever happened to be true of that week becomes your percentage change. Print the underlying counts beside any rate too: describing four becoming six as “up 50%” leaves the reader with the wrong sense of scale.

Removing things is what makes it read

Reports grow mostly because something was in the last one. Tables are added and almost never removed, and after a few months you have a document nobody finishes.

Once a quarter, ask each item the same question: has this table changed a decision in the past three months? If not, take it out. If removing it feels risky, move it to an appendix — simply separating “for deciding” from “for reference” changes how fast the front page reads.

Automated sends quietly kill reporting

A weekly export emailed by the tool is convenient, but it is numbers without interpretation or decision, so recipients stop opening it. Worse, the feeling that “reports are arriving” keeps anyone from actually looking.

Automation works better as an alarm. Keep the routine send short, and have a person interpret only when a metric leaves its agreed range. In practice that produces more decisions than a long document every week.

Turning operating rules into team habits is covered further in the development workflow archive, and how we measure before and after our own work — and what we hand over as a report — is published on the process page.

Next part

The final part is the precondition for everything above: what to check before trusting a number — internal traffic, bots and duplicated tags.

More on this topic

All technotes

Development workflow Advanced

The design QA checklist to run before release

Most design problems found after release are catchable before it, in order. Here is the pass, in three stages: rules, states and real devices.

Designers 6 min read

Development workflow Advanced

Never deploy without a way back

A rollback is not one button. It is two tracks — code and database — with an order to reverse them in, written down before you deploy.

Designers 9 min read

Development workflow Advanced

Adding your own hooks: extension points instead of edits

Code with no extension points gets forked or edited in place. Where you put do_action and apply_filters — and how many — decides how long that code survives.

Developers 7 min read

₩270,000 · Join the program