The five stages: how a report becomes a product
READ TIME - 5 minutes ⏳
Email formatting looks broken? click here to view in browser.
Most of the reports in your organisation will never be opened again.
You already know which ones. You built some of them.
The symptom everyone recognises
Someone asks for a report. You build it, and it looks good in the meeting where it's presented. Three weeks later that same person is exporting it to Excel every Monday morning, rebuilding half of it by hand, and by the end of the quarter the report itself is barely opened at all.
The usual reading of this is that the user is the problem. They're attached to Excel, they never got proper training, they don't understand the tool. That reading is comfortable and it is almost always wrong. An export is a design signal: the report stopped short of the job, so the user finished the job themselves in the only environment where they had full control.
The deeper issue sits further upstream. The report was never built to be used more than once, by anyone other than the person who asked for it, in a moment other than the one it was requested for. It was a deliverable. It was never a product.
The line between a deliverable and a product
A deliverable is finished when you hand it over. A product is finished when someone else can rely on it without you.
That's the whole distinction, and it has nothing to do with polish, complexity, or how good the visuals are. A beautiful report built for one meeting is still a deliverable. A plain one that three teams reopen every week, trust without checking, and complain about when it breaks is a product. The dividing line is whether the thing was designed around somebody else's repeated use.
Once you accept that line, the definition of "done" moves. Done is no longer the moment the last visual is placed. It's the moment the report can survive your absence.
The five stages
Most reporting estates contain all five of these at once, which is part of why the situation feels so hard to diagnose. It helps to be able to name them.
Stage 1: The one-off. Built for a single meeting or a single question. No owner, no documentation, no expectation of a second life. It answers, and then it decays. This is where the Excel export lives, because the report was never designed for the follow-up question that inevitably came next.
Stage 2: The reused report. People come back to it, which is genuine progress. But every builder in the organisation solves the same problems in their own way. Filters sit in different places, the same KPI is coloured differently in two reports, navigation is invented from scratch each time. Users pay a small tax of relearning on every single report they open.
Stage 3: The standardized report. A design system exists and is applied. Layout, colour, typography, navigation patterns and interaction behaviour are decided once and reused. Reports start to look like they come from the same house, and more importantly they start to behave the same way. A user who learns one report has learned them all.
Stage 4: The trusted report. The numbers are believed without a side-check. That requires things design alone can't deliver: agreed KPI definitions, a naming convention that survives translation, a catalog that makes reports findable, an owner whose name is attached. Trust is what turns a report someone opens into a report someone acts on.
Stage 5: The product. It has an owner, a lifecycle, and a feedback loop. Usage is measured. Reports that nobody opens are retired on purpose rather than left to rot. Changes are versioned and communicated. Users have a route to say "this doesn't work" that leads somewhere. The report is maintained the way software is maintained, because that's what it is.
The wall between two and three
Almost every organisation stalls between stage 2 and stage 3, and the reason is structural rather than technical.
Stages 1 and 2 can be climbed by one motivated person. A capable builder can produce good reports on their own and people will reuse them. Stage 3 cannot be reached alone, because standardisation is a decision about what everybody does, and no individual builder has the authority to make it. This is the point where reporting stops being a craft problem and becomes an organisational one.
It's also the stage most often mistaken for solved. Importing a corporate theme feels like standardisation, and it does real work at the surface: colours, fonts, default visual formatting. But a theme standardises appearance, not decisions. It doesn't tell anyone where the filter pane belongs, how navigation should behave, which visual answers which type of question, or what a page should do when there's nothing to report. Those are the decisions that make reports feel consistent to use, and they have to be written down and agreed somewhere above the file level.
Two reports can share a theme perfectly and still teach the user two different sets of habits.
What product thinking actually adds
The four things that separate stage 5 from stage 4 are unglamorous and none of them are visual.
An owner means there's a name attached to the report when it breaks, when a definition changes, or when a new market needs adding. Without one, every report silently becomes the responsibility of whoever touched it last.
A lifecycle means reports are allowed to end. Most estates are heavy with reports nobody opens, and their weight is real: they crowd search, they dilute trust, they make the useful reports harder to find. Deciding to decommission is a design act.
Adoption measurement turns opinion into evidence. Who opens what, how often, from which device, and where they stop. This is the only reliable way to know whether the thing you built is doing the job you intended, and it's the fastest way to make the case for the work internally.
A feedback loop means users have a route to report friction, and that route visibly leads to changes. Once people see their input land, they start telling you things you would never have discovered on your own.
The through-line
Each stage on this ladder buys back the same thing: time to insight.
At stage 1 a user asks a question and the answer takes a meeting, an export, and a rebuild. At stage 3 they can navigate a new report on instinct, because it works like every other report they've used. At stage 5 they open the report, trust what they see, and act on it (which was always the point).
That's the argument to bring to management, incidentally. Not that the reports will look better, but that the distance between a question and a decision gets shorter, on purpose, and stays shorter because somebody owns it.
Where are you?
Take one report that matters to your organisation and place it honestly on the ladder. Not the best one you've built. The one people actually depend on.
If it sits at stage 2 (used, but built its own way) you're in the majority, and you already know what the next move is. It isn't a better visual. It's a decision that applies to more than one file.
Reply and tell me which stage you landed on. I'm collecting these, and the spread so far is more interesting than I expected.
See you in two weeks,
Julien
