Most transformation artifacts are produced, filed, and never opened again. All the rigor underneath them — the traceability, the prioritization, the structure — is wasted the moment no one will navigate it. A living backlog is the opposite: a current, navigable view of the work that stakeholders open on their own, because it answers their question in seconds.

There is a particular kind of waste that transformations rarely notice, because it looks like completion. An enormous amount of effort goes into producing artifacts — a backlog, a traceability register, a process model, a portfolio — and every one of them is technically finished and practically dead, because no stakeholder ever opens it. It sits in a tool that requires expertise to navigate, or a document too dense to read, and so people do what they always did: they ask in a meeting. The artifact exists; its value does not. An artifact no one opens is a sunk cost with good production values.

The living backlog is the answer to that waste, and the reason it belongs in a series about craft is that it names a discipline most people treat as an afterthought: making the work usable is itself a deliverable, not polish applied at the end.

Why artifacts go unopened

Artifacts die unopened for reasons that are consistent and fixable, and none of them is that stakeholders are lazy.

They are built for the builder, not the reader. A backlog structured the way its author thinks about it — dense, single-view, assuming the tool and the context — is navigable only by someone who already holds all of that. The stakeholder who wants to glance and understand cannot, so they stop trying.

They are stale. An artifact that is accurate the day it is filed and out of date a week later teaches people not to trust it, and an artifact people do not trust is one they stop opening — which makes it staler, in a spiral that ends with everyone back in the meeting.

And they answer the builder’s question, not the reader’s. The person who built the backlog wanted to capture and organize the work. The stakeholder opening it wants to know something specific and personal: where is my thing, what is blocking it, what is coming, why does this item exist? If the artifact cannot answer those in seconds, it is, for that stakeholder, useless — however complete it is.

What a living backlog is: one model, many views

A living backlog fixes this by separating the underlying model from how it is seen. There is one source of truth — the actual backlog, structured and traceable — and on top of it, several views, each rendering the same data to answer a different person’s question.

A hierarchy or tree view shows how everything nests, from strategy down through initiatives and features to the individual work — the view for “how does this all fit together, and where does my item sit?” A dependency view shows what blocks what — the view for “why is this stuck, and what has to finish first?” A status or kanban view shows what state everything is in — the view for “what is in progress and what is done?” A roadmap or timeline view shows what lands when — the view for “what is coming, and by when?” Same data underneath; four different questions answered, for four different readers, without any of them learning the tool or asking a human.

That is the whole idea: not a prettier backlog, but a backlog you can navigate — one a stakeholder opens, explores, and gets an answer from, on their own, in the moment they have the question.

Usability is a first-class property

The deeper point, and the one worth internalizing, is that usability is not cosmetic. It is what converts all the upstream rigor into influence. A perfectly traced, perfectly prioritized backlog that no one opens changes no decisions; a slightly rougher one that stakeholders actually navigate changes many. The difference between an artifact that steers the organization and one that gathers dust is almost entirely whether people will open and can navigate it — which means the effort spent making it navigable is not the finishing touch on the work, it is the part that makes the rest of the work count.

This is easy to under-invest in because it feels like the unimportant end of the job. The analysis is done, the structure is right, surely rendering it nicely is optional. It is the opposite of optional. The rendering is the last mile, and skipping the last mile strands everything you carried the first ten.

It is also a trust move

There is a second payoff that connects this piece back to the human side of transformation. A living backlog is a small, continuous act of transparency. A stakeholder who can open a view and self-serve the answer — where is my thing, what is coming — stops feeling stonewalled by a program that only reveals itself in curated status meetings. The contrast with the opaque, presentation-only program is stark: one asks you to trust it and wait, the other lets you look. Letting people look, whenever they want, is one of the cheapest and most effective ways to rebuild the engagement that stalled programs lose. The living backlog earns trust not by promising, but by being open.

How to build it, and how it fails

The method is simple to state and easy to get wrong. Keep one source of truth and generate every view from it — the fastest way to destroy a living backlog is to fork the data into separate copies per view, because the copies diverge, the views disagree, and trust collapses the first time two of them contradict each other. Design each view around a real question a real stakeholder asks, not around the shape of the data. Make it self-explanatory, so a newcomer can navigate it without a guided tour. And keep it current, because a living backlog that stops being updated is just a static document with extra features — staleness kills it exactly as it kills every other artifact.

The failure modes mirror those rules: forked data that drifts; a build-once-and-abandon dashboard that goes stale; an over-featured showpiece that is impressive in a demo and unused in practice because it answers no one’s actual question; and the quiet confusion of believing that having a tool is the same as people using one. The test is never how capable the thing is. It is whether stakeholders open it without being made to.

The real point

The work is not done when the artifact exists. It is done when the people who need it open it and get their answer. A living backlog — one model, many navigable views, always current — is how the invisible work of a transformation becomes visible, and how the rigor buried in a backlog becomes something that actually steers decisions and rebuilds trust. Treat usability as the last, skippable step and you waste everything upstream of it. Treat it as a first-class deliverable and you turn a filed document into the thing people reach for. The measure of an artifact was never how complete it is. It is whether anyone opens it.