Zero-Based Roadmapping: Making Every Product Investment Earn Its Place

Most roadmaps are inherited and capacity is assumed. We take last year's plan, carry forward whatever is still in flight, add a few new ideas on top and call it strategy. The result is a roadmap shaped more by history and by whoever shouted loudest than by where the value actually is.

There is a better way, and it comes from the finance world: zero-based budgeting. Applied to product management, I call it the zero-based roadmap.

What is zero-based budgeting?

Zero-based budgeting (ZBB) was developed by Peter Pyhrr at Texas Instruments in the early 1970s and later adopted by Jimmy Carter as Governor of Georgia. The principle is simple: instead of taking last year's budget and adjusting it up or down, every period starts from zero. Every line of spend has to be justified on its own merits, as if it were being proposed for the first time. Interestingly, I wrote my accounting dissertation on zero-based budgeting but didn't do the best job of convincing my lecturer. Maybe this will be my redemption.

Traditional incremental budgeting asks "how much more or less than last year?" Zero-based budgeting asks "why should we spend anything on this at all?"

From zero-based budget to zero-based roadmap

For a product team, the budget is capacity: the engineering, design and product hours available in a planning cycle. A zero-based roadmap starts each cycle with that capacity unallocated. Nothing gets a slot simply because it was on last quarter's plan. Every initiative, whether it is a new module, a platform upgrade or a customer request, has to make its case against everything else competing for the same hours.

The danger with a pure zero-based approach is that the unglamorous work loses. New features always look more exciting than upgrading a framework or fixing a reconciliation bug. If you are not careful, you optimise for value in the short term and cut too close to the bone on maintenance and quality, and that debt comes back with interest.

That is why I structure the roadmap into four buckets. Each bucket gets an explicit share of capacity, and items inside each bucket compete on value from zero.

The four buckets

1. Strategic: the big bets (50%)

Half of your capacity goes to the initiatives that change your position in the market: new capabilities, new segments, new platforms. These are the items that justify the product's existence two or three years from now. Ring-fencing 50% guarantees that strategic work is not slowly eaten away by the urgent. Within the bucket, every bet still has to earn its place from zero each cycle, including the ones already in flight.

2. Maintenance: keeping the engine healthy (25%)

Maintenance keeps the product's technical components up to date: frameworks, libraries, infrastructure, security patching and end-of-life dependencies. It also means looking forward. If your growth plan says you will double the customer base or data volumes, maintenance is where you address the performance limits and bottlenecks before customers hit them. Treat this as an investment in the product's ability to scale, not as overhead.

3. Bugs: plan for what you know will happen (15%)

Every product has bugs, and pretending otherwise means every bug fix steals time from something else. The simplest and most honest way to size this bucket is to look back. Average the effort your team spent on bug fixing over the previous years and reserve that capacity up front. If your quality is improving, the number comes down over time. If it is going up, that is a signal worth investigating.

4. Tactical: responsiveness and delight (10%)

The tactical bucket gives a legitimate home to the work that keeps customers and colleagues happy:

• Priority customer requests that unblock a renewal or a key account
• Small improvements that delight customers out of proportion to their size
• Changes that make Professional Services' lives easier, reducing implementation effort and time to value

Without a defined bucket, this work either never happens or hijacks the roadmap through escalation. With one, you can say yes to the right requests without derailing strategy.

An example

Suppose your team has 1,000 days of capacity for the year. Strategic gets 500 days. Your technical roadmap and growth plan call for 250 days of maintenance. Bug effort averaged 140 days over the last three years, so you reserve 150 to give yourself a small buffer. That leaves 100 days for tactical work. Now every item in every bucket competes from zero for its share.

The pros

• Every investment is justified. Zombie projects that survive only because they were on last year's plan get exposed and stopped.
• Trade-offs become visible. Stakeholders can see exactly where capacity is going and why, which makes roadmap conversations about value rather than volume.
• Health of the product is protected. Maintenance and bug capacity is ring-fenced, so it cannot be quietly raided for the next shiny feature.
• Strategy gets a guaranteed share. Big bets do not starve under a constant flow of urgent requests.
• Planning is evidence based. Sizing the bug bucket from history replaces guesswork with data.
• Customer responsiveness is built in. The tactical bucket lets you react to customers and Professional Services without breaking the plan.

The cons

• It takes effort. Rebuilding the roadmap from zero every cycle is more work than rolling it forward, and it needs discipline from the whole leadership team.
• It can disrupt long-running bets. Multi-year initiatives can suffer if they are re-litigated too aggressively every cycle. Re-justify them, but judge them on their long-term value, not on what they delivered last quarter.
• It relies on good data. You need reliable records of effort spent on bugs and maintenance. Many teams discover their tracking is not good enough the first time they try.
• Maintenance value is hard to quantify. Upgrades and performance work rarely have a revenue number attached, which is exactly why they need a protected bucket rather than competing head to head with features.
• Buckets can become rigid. The percentages are a planning tool, not a law. If a critical incident or a major customer situation arises, you need the flexibility to rebalance and explain why.
• It can create friction. Asking teams to justify work they consider untouchable can be uncomfortable. Strong facilitation and transparency help.

Why I believe it is worth it

The core job of a product leader is to put limited capacity where it creates the most value. Zero-based roadmapping forces that question to be asked honestly, every cycle, for every item. For me as a VP of Product, the biggest benefit was that every item on the roadmap became defensible.

Every item on the roadmap is defensible

Every product leader knows this conversation. Sales comes to you with an urgent feature request. A customer needs it, the deal depends on it, and it has to be on the roadmap this quarter. It is one customer. You want to say no, but how do you say no without looking like you are standing in the way of revenue?

Without a zero-based roadmap, it becomes your opinion against theirs, and the loudest voice usually wins. With one, every row on the roadmap has already been justified from zero, with its value and its cost visible to everyone. That changes the conversation. Instead of saying no, you ask a question:

"Which one of these $1m+ items do you want me to remove from the roadmap to add in your $400k request?"

That question turns a demand into a trade-off. Occasionally the request genuinely is worth more than what it would displace, and it earns its place. Far more often, everyone in the room can see that it is not, and the request is weighed against the tactical bucket or moved to the next cycle. Either way, the decision is made on value, in the open, and you can defend every row.

But value is not only new features. A product that ships big bets while its foundations crumble, its bug backlog grows and its customers feel ignored is not a healthy product. The four bucket model gives you the best of both: the rigour of zero-based thinking and the protection of the work that keeps the product reliable, scalable and loved.

Finance teams have used zero-based budgeting for decades to make sure every pound and dollar earns its place. Product teams should hold their roadmaps to the same standard. Start from zero, fund the big bets, protect the foundations, plan for the bugs you know are coming, and leave room to delight. That is how you focus investment on the highest value without cutting too close to the bone.