The Runway Problem: Why You Can’t Prioritize a Backlog You Can’t Yet Build
A backlog tells you what the business wants. It says nothing about what can actually be built next, or what has to exist first. That missing information — the architectural runway — is why "what should we invest in?" so often has no honest answer, and why teams end up fed by hand.
You can produce a beautifully structured backlog — epics, features, user stories, all prioritized by business value — and still be unable to answer the one question leadership actually asks: what should we invest in...
Mapping Both Value Streams as One Picture
Two value streams run underneath every transformation: how the business delivers value to customers, and how the organization builds the systems that make that possible. They are almost always mapped separately, by different people, in different languages — which is exactly why the business and the technology drift apart. Putting both on one picture is the artifact that keeps them aligned.
Ask the business how it works and you get a story about process: how an order becomes a delivery, how a ...
WSJF Without the Theater
Weighted Shortest Job First is a genuinely good way to prioritize — and one of the easiest to turn into theater. The arithmetic is the trivial part. The honesty of the inputs is the whole game, and it is exactly the part organizations skip.
Prioritization is where most programs quietly go to war. Everyone's feature is the most important; every deadline is the hardest; every team believes its work should be first. Into that fight walks Weighted Shortest Job First — WSJF — with a promise that s...
The Shared Data Contract: Why Master Data Is Epic Zero
Every cross-unit ambition an enterprise has — a unified customer view, coordinated selling, trustworthy reporting, anything with "AI" attached — rests on one agreement that usually does not exist: agreement on who the customer actually is. That agreement is the real first deliverable, and almost no one funds it first.
Ask a large, multi-division enterprise a deceptively simple question — how many customers do you have? — and watch the answer fall apart. The same account turns up again and aga...
Reverse-Engineering Requirements From a Prototype
A prototype is the best tool there is for discovering what people need — and the worst possible way to record it. The step almost everyone skips is turning what the prototype revealed back into traceable requirements. Do it, and the prototype's learning survives; skip it, and you ship the mock-up's accidents as if they were the plan.
An earlier piece in this series argued that prototyping has become the primary way to gather requirements, because people reveal what they need when they react t...
Epics as Hypotheses, Not Projects — and the Review That Makes It Real
Framing a big initiative as a hypothesis instead of a project is a genuine advance. But a hypothesis is a contract that requires a counterparty — someone to read the evidence and decide. Write rigorous hypotheses into an organization with no review gate, and you have produced the paperwork of agility with the behaviour of waterfall.
There is a real and valuable shift in how mature organizations frame large investments. Instead of defining a big initiative as a project — "we will build X, by d...
The Traceability Chain: From Interview to User Story Without a Broken Link
Most backlogs cannot answer the two questions that matter most: why does this item exist, and if the business need behind it changes, what do we have to rebuild? A traceability chain answers both.
Pick any story in a large product backlog and ask the team a simple question: why does this exist? In most organizations the honest answer is a shrug, or a name — "someone asked for it," "it came out of a workshop," "it's been in there since the last planning cycle." The provenance is gone. The item...
When Building Is Cheap: Why AI Turns Delivery Teams Into Discovery Teams
Artificial intelligence does not remove the hard part of enterprise work. It removes the easy part — building — and leaves an organization face to face with everything it was using the difficulty of building to avoid.
Every article in this series has circled the same quiet truth from a different direction: in large enterprise change, building the software was rarely the real problem. The real problems were knowing what was worth building, trusting the data underneath it, deciding who owned th...
The Prototype Is the Requirement: Why Interviews Alone Stopped Being Enough
The old model asked people what they wanted and wrote it down. The new one shows them something and watches what they do. The difference is the difference between stated needs and real ones.
For most of the history of enterprise software, gathering requirements meant the same sequence of moves. An analyst or product owner interviewed stakeholders, ran workshops, and asked people what they needed. The answers were captured in a document — a requirements specification, a set of user stories, a ...
You Can’t Transform on Data No One Trusts
Agile frameworks are built to ship visible value in cadence. The data foundation everything rests on is invisible — which is exactly why it gets starved.
There is a moment in a lot of transformation programs worth learning to watch for. A leader is shown a number — year-to-date orders, pipeline coverage, the size of an account — and instead of using it to make a decision, they visibly set it aside. Sometimes they say it out loud — they no longer trust a number they are handed until they have ...