How to Balance Multiple Product Roadmaps Against One Pool of Engineering Capacity

The first time we moved a component between teams at Trainline it took months and it was chaos. Two teams with different branching strategies, different deploy pipelines, different definitions of “done”, different opinions about how a service should be shaped. Nobody had a runbook for the thing they were inheriting. Everyone had a runbook for the thing they were giving away, and it was in someone’s head. By the time the dust settled, we’d lost of whole quarter of squad productivity (squaductivity 🤔).

A couple of years later we could move a component between teams in a sprint, and a whole product in a month, and nobody thought it was remarkable. Same people, same products, same growth targets (actually higher because… private equity). What had changed was that we had built the muscle. That muscle is what actually determines whether an organisation can balance multiple product roadmaps against one pool of engineering capacity. The templates and the tooling come a distant second.

To balance multiple product roadmaps against one pool of engineering capacity, treat capacity as fungible across the portfolio and teams as the unit that moves. Categorise every big bet, put a number on it, allocate whole squads to the highest-value problems, hold teams stable within a quarter, and standardise engineering practices so that moving a team is cheap when the numbers say it should happen.

This is precisely what RoadmapOne was built to make visible. Every objective is tagged by the product and the growth pillar it serves, allocated to specific squads in specific sprints, and the analytics view tells the leadership team, at a glance, what share of capacity each product is actually getting. When the allocation needs to change, you drag a squad from one objective to another and watch the portfolio picture update. The game of Tetris a CPO plays every quarter, sliding big bets into the teams that can deliver them, is what the grid was designed for. But the tool only helps if the organisation can execute the move it shows you. That is the muscle.

Sign up (free) to see capacity allocation across all your products in RoadmapOne

The grown-up question: are we making the best use of all our resources?

Most companies are not single-product companies. They have a portfolio : a cash cow that pays the bills, a growth product the board is excited about, something in incubation that may or may not turn into anything, and a couple of products nobody has had the courage to switch off. Each sits at a different point in the product lifecycle , and the capacity each one deserves changes as it moves along that curve.

That is the whole problem in one sentence. If products sit at different lifecycle stages, and lifecycle stages change, then the right allocation of capacity across products changes too. So capacity has to move. Not occasionally, as a reorganisation with a consultancy attached, but routinely, as a normal part of running the business.

The question a board asks, or should ask, is always the same: are we making the best use of all our resources by allocating them to the highest-value opportunities? Nobody on a board asks whether the checkout team is happy owning checkout. They ask whether the £4 million a year that team costs is producing more value there than it would anywhere else. At the level of the P&L every pound of product and engineering capacity is fungible, a point I made in the context of Zone to Win : two million pounds allocated to Product X is two million pounds not allocated to Product Y.

The honest answer is usually uncomfortable. Team sizes on the org chart reflect where the company placed its bets two or three years ago, not where the value is today. The growth product is under-resourced. The mature product has a team sized for a build phase it finished long ago. And somewhere there is a zombie project with fifteen engineers on it because the HiPPO who sponsored it is still in the building. Reallocating those teams to the things that actually drive growth is the most valuable thing a product leadership team can do, and the thing it is least equipped to do.

Why teams end up welded to products

When I ask leadership teams why the allocation across products has not changed in three years, the real reasons are rarely the ones they give.

The first is inertia. The org chart mirrors the product list. Headcount was budgeted per product line. Each team has a manager whose standing is, implicitly, the size of their team. Nothing in the system rewards anyone for giving capacity away, so the roadmap for each product is built to fit the team it happens to have, rather than the other way round.

The second is that most organisations do not have the skills to make the comparison. To move a team from Product A to Product B you need to say, with a straight face and some numbers, that the next opportunity on B is worth more than the next opportunity on A. That means stack ranking initiatives across products, which is harder than ranking within one, and writing a business case a CFO will accept. Most product organisations have a backlog per product, groomed by a product manager whose job is to make that product better, and no mechanism for comparing the top of one backlog with the top of another. The prioritisation frameworks exist. The discipline to apply one across the whole portfolio, in the same units, usually does not.

Then there is the fear. It seems super-hard the first time, and the specific fear is that the team will leave if their project gets put on ice. In my experience that absolutely does not happen. People are perfectly happy to move, as long as you explain why. What they hate is being moved without explanation, or being left on a product everybody privately knows is going nowhere. The fear that people will quit is nearly always the sponsor’s fear, projected onto the team.

Underneath all three is the question I keep coming back to on this blog: is the team solving a commercial problem or delivering features? If the checkout team’s mandate is “build the new checkout”, moving them off it feels like taking away the thing they exist for. If the mandate is “get conversion from 31% to 36%”, then moving them to a product where the same effort moves a bigger number is not a demotion. It is a promotion. Teams that own outcomes rather than outputs can see the higher-growth opportunity in the new metric immediately. Teams in a feature factory cannot, because nobody has ever shown them the number.

Nothing kills productivity like changing course

There is a version of this article that reads as “reallocate freely”, and that version is wrong. As a general rule, nothing damages productivity as much as constantly changing what a team is working on. I have written about priority whiplash at length: every change of direction throws away context, half-finished work, stakeholder relationships and the tacit knowledge of a codebase that takes months to build. A team redirected every few weeks never gets past the first third of anything, and the engineers update their CVs.

So the tension is real. Capacity has to move, because the value moves. Teams must not be jerked around, because that destroys the capacity you were trying to redeploy. The resolution is not to pick a side. It is to be deliberate about what moves at what cadence, and to make the moves that do happen as cheap as possible. That gives you an operating rhythm and a set of engineering preconditions.

The operating rhythm: what moves monthly, what moves quarterly, what moves when it must

The rhythm we settled on at Trainline, and the one I now recommend, has three layers.

Targets move monthly. The problem a team is solving for, expressed as a business metric with a number on it, is reviewed every month. Most months nothing changes. Some months the target moves, because the metric has been hit, or the problem turned out to be different, or a bigger opportunity has opened up elsewhere in the portfolio. Changing a target is cheap when the team already owns an outcome: the team keeps its codebase, its stakeholders and its ways of working. Only the number changes.

Teams stay with products within a quarter. We tried hard to hold teams static against products, and certainly within a quarter. A quarter is long enough to deliver something meaningful and short enough that a mis-allocation does not cost the year. If the portfolio picture says a team should move, the move is scheduled for the quarter boundary and the team knows a quarter ahead. This is the rule that reconciles “capacity must move” with “stop changing course”, and it makes the quarterly planning conversation the right forum for the allocation decision.

Components and products move when the numbers say so. Sometimes a whole product changes hands, because the team that built it is the team you want on the next big bet and the product now needs a smaller, steadier team in keep-the-lights-on mode. Sometimes a single component moves because ownership has drifted away from the team that touches it most. These moves are rarer, they are the ones that hurt the first time, and they are why the paved road below matters so much.

One rule sits under all three layers: the squad moves as a unit. Planning at the individual level , pulling one engineer off here and lending another there, is the most damaging planning antipattern I know, and it is doubly damaging when reallocating across products. When a squad moves together, people move with their friends. The product person comes with them. The ways of working, the retro habits, the on-call rota, the in-jokes, all arrive intact on the new problem. A squad is a working system; an individual is a resource. Move the system.

Sign up (free) to plan squad moves at the quarter boundary with RoadmapOne scenarios

The paved road: standardisation is the precondition for mobility

Here is the part most articles on multi-product roadmaps skip entirely, because it is an engineering problem rather than a product one. You cannot move teams cheaply between products if every product is built differently.

When we did our first move at Trainline, the cost was almost entirely the differences between teams. Different repo conventions, CI pipelines and deploy mechanisms. Different approaches to observability, so the inheriting team could not see what the service was doing. Different on-call arrangements, so nobody knew who got paged. Different ideas about what a story looked like and what “done” meant. None of those differences existed for a good reason. Each team had been left to choose, and each had chosen slightly differently.

As we standardised product and engineering practices and patterns across teams, the moves got cheaper, and eventually they became second nature. The list is not exotic: repo and service conventions, CI and deploy pipelines, on-call and runbooks, observability, a shared definition of done, and a common way of writing objectives and backlogs so a team inheriting a product can read its roadmap without a translator.

I would add one item that matters more than any of those: a consistent technology stack. A highly heterogeneous stack limits your options before you start, because a team that knows one set of tools cannot safely own a service built with another. A good architecture function is invaluable here, precisely because it resists the “let a thousand flowers bloom” approach to technology selection. Netflix’s paved road, a supported, well-lit path teams are strongly encouraged to stay on, is the right mental model. On a core-banking platform I was involved with, some teams had chosen Liquibase for schema migrations and others had chosen Flyway. Two tools, one job, no reason. In 99% of cases, just choose one and standardise. Everybody wants to faff about with MongoDB or a graph database at some point. Is it a graph-shaped problem? Sort of. Okay, then back in your box. Good architects earn their keep by saying that kindly, and often.

If I had to pick the single thing that mattered most, it would be CI and deploy pipelines. I am slightly obsessed with them as a way to simplify and enforce standards across an organisation, because a shared pipeline is a standard that enforces itself. If every service deploys the same way, every team can deploy every service, and the scariest part of inheriting a product, “how do I get my change into production without breaking it”, is already solved. A pipeline is worth more than a wiki page of standards, because nobody reads the wiki page. Design systems, for what it is worth, I have never cared about in this context; they matter for the customer, not for mobility.

People hate standardisation the first time. Every team believes its codebase is special and its choices were considered. Some were. Most were not, and the ones that were are rarely worth the mobility they cost. Eventually it becomes normal, then invisible, and one day you move a product between teams in a month and nobody mentions it.

People are happy to move, as long as you explain why

The condition attached to “people don’t leave” is that you explain why, and the quality of the explanation is the difference between a team that arrives on the new problem energised and one that arrives resentful.

The explanation is not complicated when the team already owns a business metric. “You have been working on getting activation on Product A from 40% to 50%. You got it to 48% and the last two points will cost more than they are worth. Product B has a conversion problem worth roughly three times the remaining activation gain on A, and you are the team best placed to fix it. Here are the numbers.” A team that has been solving commercial problems rather than delivering features sees the higher-growth opportunity immediately. They have been trained to want the bigger number.

What you do not need to do is make promises about the thing they are leaving behind. This surprises people. The instinct is to reassure the team that their product will be looked after and their roadmap still delivered. Resist it. The team has either delivered a great result, in which case the job is done, or the organisation has learned something about the problem it asked them to solve, in which case the job is also done. That problem is closed. Now there is a new one. The moment you promise the old roadmap will still be delivered by somebody, you have created a zombie: a product that should have gone into keep-the-lights-on mode now has a ghost team of expectations attached to it.

This is the CPO’s conversation, with the CTO alongside, not something delegated to a line manager with a slide deck. The people being moved should hear the portfolio logic from the person who owns the portfolio.

The discipline on the CPO’s side: categorise, quantify, play Tetris

Everything so far makes moves cheap and acceptable. None of it tells you which moves to make. That part is a discipline, and it belongs to the CPO and the leadership team.

First, categorise the big bets. Every significant initiative gets tagged by the product it belongs to and the kind of value it is meant to create. Run / Grow / Transform is a really great place to start because a CFO can use it, but there are twenty-odd tagging methodologies and the best is often the company’s own list of “we will win by” pillars. Tagging lets you see the allocation across products in the same units, which is the precondition for comparing them.

Second, put a number on each bet. Not a precise number; a defensible one. Expected revenue impact, cost avoided, risk retired, in the currency the board uses. This is where the business case skill comes in, and it is the skill most product organisations lack. Without a number the allocation conversation is a negotiation between product managers about whose product matters more. With a number, it is arithmetic.

Third, play Tetris. You have a fixed number of squads and sprints, which is the honest capacity of the organisation, and a ranked list of bets with numbers on them. You slide the bets into the squads, biggest value first, subject to the constraint that squads stay put within a quarter and move as units at the boundary. Some bets do not fit. That is the point. Capacity-based planning exists so that what does not fit is visible before the year starts rather than discovered in November.

This is the part of the job RoadmapOne does better than anything else I have used, and it is the reason the product exists. Squads in rows, sprints in columns, objectives dragged into the cells. Tags roll up into the analytics view so you can see what share of capacity Products A, B and C are getting and whether that matches where the value is. And scenario roadmaps let you play the game three different ways, with three different team moves, and compare the portfolio picture of each before you commit. A move that looks obvious on a slide often looks different when you can see what it does to the rest of the board.

One caveat from the AI-era reframe that runs through everything I write now. The cost of building has collapsed; the cost of deciding what to build has not. That shifts the weight of this discipline towards categorise-and-quantify and away from delivery. Moving a team is cheap once the paved road exists. Knowing where to move it is the scarce skill, and it is getting scarcer.

A worked example

Suppose you run a business with twelve squads and three products.

Product A is the cash cow: mature, 70% of revenue, five squads because five squads is what it took to build it. Product B is the growth product, three years old, 25% of revenue and growing at 40% a year, with four squads. Product C is an incubation bet with three squads, launched eighteen months ago, 5% of revenue and flat.

Tag the initiatives and put numbers on them. Product A’s top remaining bets are worth perhaps £300k a year each, and the fifth is worth less than the squad costs. Product B’s backlog has three bets worth over £1 million each that nobody has capacity to start. Product C has not moved in a year and the team’s own retros say the market is not there.

The Tetris move is obvious once the numbers are on the table. Product A goes to three squads, enough to keep it healthy and take the two bets that clear the bar. Product B goes to six. Product C goes to a minimum viable team of two engineers and a product person with a single, time-boxed problem: prove there is a market by the end of the quarter, or go into keep-the-lights-on mode. Three squads move, all at the quarter boundary, all as units.

What makes that plan executable rather than a slide is everything above. The moving squads can deploy Product B’s services on day one because the pipeline is the same. They can read Product B’s roadmap because objectives are written the same way. They arrive with their product person and their ways of working intact, and they arrive knowing why, because the CPO showed them the £1 million bets and the £300k bets side by side. What makes it fail, in most organisations, is that Product A’s head of engineering has five squads on the org chart and a strong view about keeping them, Product C’s sponsor sits on the executive committee, and nobody has done the numbers.

Common mistakes

The most common mistake is reorganising instead of reallocating. A reorganisation is a one-off, expensive, consultancy-shaped event that redraws the org chart and then leaves it fixed for another three years. Reallocation is a routine that happens at every quarter boundary and is boring by design. If your allocation across products only changes when there is a reorg, you do not have the muscle. You have a spasm.

The second is moving individuals rather than squads. It feels more precise. It is not. It destroys the working system that made the squad productive and leaves both products with a fragment of a team.

The third is moving teams before building the paved road. The move takes months, everybody concludes that moving teams is impossible, and the organisation never tries again. Build the road first; then the moves are cheap, and then the numbers can decide.

The fourth is protecting the thing left behind: promising the old roadmap will still be delivered, keeping a token engineer on the old product “for continuity”, letting the old backlog stay open. Close the problem. Either it was delivered or it was learned from. Anything else breeds zombies. And the fifth is doing any of this without the numbers. Tagging, business cases and a ranked list of bets turn “we should move some people to Product B” from an argument into a decision. Without them the loudest sponsor wins, and the allocation reflects the org chart rather than the value.

Sign up (free) to run the Tetris game across your products with RoadmapOne

Frequently asked questions

How do you balance multiple product roadmaps with one engineering team?

Treat engineering capacity as a single pool and the products as competing claims on it. Tag every initiative by product and value type, put a defensible number on each, and rank them across the whole portfolio rather than within each product. Allocate whole squads to the highest-value problems, hold those allocations stable within a quarter, and revisit them at every quarter boundary as the numbers change.

Should each product have its own roadmap, or one roadmap for all products?

Both. Each product needs a roadmap its team can execute against, but the allocation of capacity across products has to be decided in one place, in the same units. In practice that means a portfolio roadmap showing every squad and every sprint, with product roadmaps as filtered views of it. Separate product roadmaps that are never reconciled against a shared capacity pool are how organisations end up over-committed on every product at once.

How often should you move teams between products?

Rarely, and on a rhythm. Targets can change monthly, because changing what a team is aiming at is cheap when the team owns an outcome. Teams should stay with a product for at least a quarter, and moves should happen at quarter boundaries with a quarter’s notice. Whole products or components should move only when the portfolio numbers clearly justify it. Moving teams every few weeks destroys the productivity you were trying to redeploy.

Will engineers leave if you move them off their product?

In my experience, no, provided you explain why. People are happy to move when they can see that the new problem is worth more to the business than the remaining opportunity on the old one, and they are most receptive when they already own a business metric rather than a feature list . What drives people out is being redirected without explanation, or being left on a product everybody knows is going nowhere.

What is a multi-product roadmap?

A multi-product roadmap shows the initiatives for several products against a single, shared view of engineering capacity, so leadership can see what share of the organisation each product is getting and decide whether that matches where the value is. It differs from a set of independent product roadmaps in that the allocation across products is an explicit decision rather than an accident of the org chart.

What has to be standardised before you can move teams between products?

The engineering practices that make one product feel like another to an incoming team: a consistent technology stack, shared CI and deploy pipelines, common repo and service conventions, observability, on-call arrangements and runbooks, and a shared way of writing objectives and backlogs. Shared pipelines matter most, because a standard that enforces itself beats a standard that lives on a wiki.

Conclusion

Balancing multiple product roadmaps against one pool of engineering capacity is not a template problem, and no tooling will solve it for an organisation that cannot move a team without a six-month reorganisation. It is a muscle, built in two places at once: a paved road of standard practices, pipelines and technology choices that makes moving a squad cheap, and the discipline to categorise the bets, put numbers on them, and play the Tetris game honestly against the capacity you actually have.

The first time you do it, it is painful and everybody hates it. Do it anyway, at the quarter boundary, with whole squads, with the numbers on the table. The second time is easier. By the fifth time nobody notices, and the grown-up question, “are we making the best use of all our resources?”, stops being one the board asks and becomes one the organisation answers every quarter without being asked.