Descale Your Portfolio By Organizing Around Products

Is your Portfolio Kanban Board Busy? Do almost all meaningful outcomes need to be managed at the portfolio level because they involve several product or development groups? If so, the answer is probably not more portfolio management.

One solution is to invest in better coordination mechanisms. Sometimes you need some of that. But the better solution is usually to descale: organize around outcomes so less work needs portfolio-level intervention in the first place.

The goal is to minimize the number of outcomes spanning product and development groups. That is the whole idea of empowered product teams, or stream-aligned teams in Team Topologies language. Empowered means having the decision rights, resources, and skills needed to discover and deliver product outcomes with minimal dependencies.

Decision rights are meaningless without the resources and skills. You can empower Product Managers on paper, but if the Product Team is heavily dependent on other teams, you have mostly empowered them to negotiate. That coordination pain often flows back up to the cross-product layer, also known as the portfolio, for resolution.

When portfolio leadership teams approach me with this challenge, I guide them through a few moves. First, identify the constraints — the usual suspects involved in everything. In many cases, 80% of the dependencies map to 20% of the teams. Then look for product topology options that might work better. Sometimes the answer is architectural, such as introducing a self-service platform to melt some of the iron spaghetti. Sometimes it is organizational, such as aggressive cross-product T-shaping so people and teams can do work currently limited to specific constrained teams.

We then compare the design options, including the current state, against practical criteria. How much of the portfolio’s work will be localized using this option? Aim for the majority of the work to be localized; if possible, 80% would be even better. How much change does this option require from the current state? What product, technology, or people risks does it create, such as distributing a core capability with limited know-how? How future-proof is it, and how well does it fit the strategy and what is on the horizon?

When we find a significantly better alternative worth exploring, we evolve it like a product: clarify the desired outcomes and leading indicators, agree on a discovery approach, and tackle it incrementally if possible.

And yes, this is a fractal of how you could tackle a product group that is facing too many dependencies, which is a fractal of how you improve the resiliency and flow on an empowered product team.

Or, in other words: “Turtles all the way down”.