Scaling Product Organizations with Portfolio Agility

You’ve set out to create empowered product teams that are aligned towards outcomes, can deliver increments of product value independently, and steer with evidence. You’ve implemented a “Product Operating Model”. But the reality is different. You’re seeing: Decision Paralysis: Uncertainty and complexity bring your business to a standstill. Teams operate in silos, unable to adapt or innovate. Missed Opportunities: You see competitors pivot and innovate while your organization struggles to maintain the status quo. Your cross-product process is intended to bring order and discipline and reduce risk – but it doesn’t prevent the wrong things from being built; it just slows the process down. Cross-functional Hell: Despite creating “Agile / Product” teams, every meaningful innovation/transformation requires heavy collaboration – becoming a “project” or “program”. This is the portfolio challenge - managing your growing set of technology/product assets and investments. Portfolio management is an established practice that often relies on traditional project/program management practices, which clash with agile/product operating models prevalent in product/tech organizations. This book introduces a portfolio management approach that is better aligned with agile/product operating models. While we will explore portfolio agility frameworks/processes, we will focus more on the portfolio behaviors we want to see. This is one of the key differences between frameworks such as SAFe Lean Portfolio Management and the approach we will explore here. Before launching new structures and processes, we will focus on defining the behaviors and thought processes we want to see among all the players involved in portfolio-level conversations. Then, as we introduce new practices, we will refer back to this behavioral framework to ensure they align with the desired behaviors. For example, we will care about having conversations like “Should we start this initiative? Do we really have the capacity and attention span for it? Or should we focus on what’s already in flight, finish some stuff, and then reconsider?”. These conversations can happen through a Portfolio Kanban, PI Planning, or another periodic planning session. The format of the conversations doesn’t matter much. What we do care about is that the conversations take place, that the desired thought process is applied, and the decisions made are impactful. We don’t want to overburden ourselves with sticking to a proscripted process to drive these behaviors. Instead, we are constantly looking for the Minimally Viable Process that will be enough to drive meaningful improvement in the behaviors we care about.

The Portfolio Agility Trailmap is a practical, no-fluff minibook for leaders of growing organizations and practicing portfolio leaders who want to use the foundational practices of multiple-product/portfolio agility to evolve their organization from a feature factory managing scattered investments to creating a product-oriented mega-lab that drives growth, value, and resilience. This is a trail map, not a roadmap (or a blueprint). That means there are multiple paths to get from where you are now to where you want to go. A trail map will not tell you which route to take. The purpose of any trail map is simply to familiarize yourself with the terrain.

Why Read this Minibook?

This isn’t a dense, jargon-filled book. It’s a straightforward introduction to portfolio agility that you can adapt to your scale-up or mid-sized tech/IT context. You’ll benefit from:

• No Overwhelm: Bite-sized lessons designed for busy leaders.
• Real-World Insight: Proven techniques and examples drawn from actual tech and product organizations.
• Immediate Practical Application: Implement new tools from day 1—no massive reorg required.

What You’ll Learn (Portfolio Agility Overview)

This minibook will help you clarify your approach to increasing portfolio agility in your multi-product organization. Starting in the right direction avoids costly mistakes. You’ll discover how to:

• Determine Whether You Need a Portfolio Operating Model - Examine a few scenarios/use cases and decide whether a defined operating model is useful in your context
• Start where you are: Introduce the concepts of Visibility, Focus, and Flow as a low-risk initial intervention.
• Descale Your Portfolio By Organizing Around Products - Learn how to minimize dependencies and coordination overhead in a multi-product portfolio.
• Reduce Risk and Improve Outcomes – Use alignment, move from outputs to outcomes, and use an evidence-driven empirical product approach to execute on your most strategic organizational initiatives
• Develop and Evolve your Portfolio Operating Model: Apply product-oriented thinking to build your operating model. Treat the model as a product in its own right, with its own defined outcomes, roadmap, reviews, and iterations.
• Show Up As a Product-Oriented Portfolio Leader - Adopt a behavioral framework to use when talking about your operating model and your portfolios. Incorporate Product and Agility principles into your team interactions and model the behavior you want others to emulate.

What You’ll Get (Value and Benefits)

By the end of this minibook, you’ll:

• Understand the Core Concepts of portfolio agility—and how they can stabilize fast growth or reignite innovation in a multi-product organization.
• Gain Practical Tools to visualize work, align, and organize around outcomes, and steer by leveraging evidence and empiricism.
• Build Confidence to start small, achieve quick wins, and scale sustainably over time.
• Walk away with an Action Plan tailor-made for your organization’s growth trajectory.

How to Use The Portfolio Agility Trailmap

One option is to review the entire book cover-to-cover. This will give you the lay of the land. The other option is to choose your own adventure. After all, It is a trail map, not a roadmap. Make sure to stop and reflect every once in a while. Are you seeing something new? Is there a fork in the road you hadn’t thought about before? Here are some examples of how other leaders made their way through the portfolio agility path:

• When Mark sought to improve empiricism and reduce investment risk, they refined their definition of workflow to encourage better product-discovery behaviors. They also introduced a key decision conversation: Do we go through Discovery, or skip it and go straight into Delivery?
• When Susan, a product leader at a midmarket company, sought to empower product teams working on their most significant initiatives, she emphasized structuring those initiatives around Outcomes, using OKR language rather than classic PRDs and business cases.
• When Ed realized his enterprise is struggling to maintain an unsustainable pace, a key intervention was to introduce a portfolio-level planning exercise inspired by agile planning techniques. The result was that all the different groups involved collaborated to create a realistic roadmap using pull mode.
• When Emily, the COO of a pharma company, realized they were scrambling to tackle too many organizational transformations at once (trying to implement recommendations from a top consulting firm), it was time for a tough conversation about organizational focus. Key players were stretched too thin between their ongoing work and multiple transformation “Sprints”. The conversation led to empowering a larger group of people to focus on a specific mission. This then led to the introduction of a language of discovery and empiricism into the management of the initiatives. Ultimately, they enabled real agility in the trenches, leading to quicker adoption of the recommendations.

Are You Ready to Evolve Your Multi-Product Operating System?

My name is Yuval Yeret. I’m a coach helping companies scale with agility by focusing on principles, intent, and context to decide which frameworks and practices make sense. I find this approach drives more sustainable and successful change and enables continuous improvement. I’ve been using it to help company and portfolio leaders upgrade their operating systems and their capabilities to continue developing their company/organization. And now, I want to share everything I know about driving multi-product/portfolio agility with you.

What People Are Saying

I have had the great pleasure of working with Yuval over the last few years as we were orienting our organization towards outcomes and Product Oriented Teams from a traditional Information Technology organization. Yuval has advised me personally through this path and has also helped our organization adopt agile in a pragmatic way with a focus on the outcomes for the enterprise. As we continue this path, we owe a debt of gratitude to Yuval for giving us the best training and start on this path. Yuval would be an asset to any C suite as they contemplate adapting their organization to a rapidly evolving technology environment that is likely to disrupt many businesses. Transformation is more about people and mindset. With the right leaders and the right mindset, organizations can deliver remarkable results. We have experienced this over the last two years.

Sunil Cutinho - CIO, CME Group

Without question, Yuval is the best Lean/Agile partner I have ever worked with. Over the 2+ years of our working relationship, he has consistently brought a pragmatic and refreshingly direct approach towards problem-solving, coaching, and training.

Steve Lizotte - Engineering Leadership - NEC

Yuval understands how organizations and people operate. During our work together, Yuval consistently provided original and thoughtful insights and perspectives on the challenges we faced.

Roy Emek - Ex-Tech Executive

Yuval helped me bring the science and mindset of agile into our world. He advised my team and me on operationalizing the best practices and applying them pragmatically and practically to our unique context – focusing on transparency, empiricism, shared understanding, and empowerment.

Vincenza Nigro - Global Franchise Lead - Hansa BioPharma

Yuval takes an incremental and highly collaborative approach to understanding the problems to be solved, and doesn’t push a cookie-cutter solution - instead, he provides insight from his deep experience across multiple methodologies and frameworks and coaches the business leaders to align on a path forward.

Rachel Grundy - Chief of Staff - ButcherBox

I’m thrilled you’re here and have taken the first steps to learn the foundational principles and practices of multiple-product/portfolio agility. I’ve seen how focusing on these techniques can drive a beautiful and sustainable evolution toward improved flow and product orientation, and I’m excited to share what I’ve learned with you and others in this minibook. Here are the topics we’ll cover:

Establishing a view of the terrain

Chapter 1: Why Is Your Organization Getting Slower/Stuck As You Scale? Chapter 2: Finding an Operating Model To Help You Gain Traction Towards Outcomes As You Scale

Specific paths/trails you can take

Chapter 3: Start Where You Are—Bringing Visibility, Focus, and Flow To Your Strategic Initiatives Chapter 4: Descale Your Portfolio by Organizing Around Products Chapter 5: Reduce Risk and Improve Outcomes

Stepping onto the trail

Chapter 6: Using a Trail Map To Evolve Towards Organizational Traction

Meet Mary, a co-founder of FlowImpact Yoga (FIY) - a rising power in products serving the yoga and pilates industry. FIY’s successful initial product enabled it to invest in extending its product suite - offering more capabilities to its core client - Yoga Studios, and branching out to Pilates studios as well as gyms with a yoga studio. FIY’s product/technology organization recently crossed the 200 person mark. With that size came the expectation for increased throughput, speed, and impact to support the continued growth of the company, while keeping existing customers happy. Mary has been FIY’s head of product and technology through this growth. Recently, Mary noticed an emerging problem. As her organization grew, it was able to work on more products and initiatives, but overall throughput has not grown at the pace of investment growth. It seems to be stuck and even regressing. Worse, even delivered features aren’t making the same impact anymore. Everything seems like it’s full gas in neutral. More time is spent in meetings and coordination. Managers have become the bottleneck as they’re trying to coordinate cross-functional dependencies and work through siloes and emerging fiefdoms. Instead of a lean, flexible startup, it seems FIY has become a slow, lethargic bureaucracy. There MUST be a better way.

Why Does Scaling Lead To Stalling?

So what’s going on here? FIY is representative of what we see in many scale-up organizations. Small companies are inherently agile in their path to discover, develop, and deliver their first products (also known as pre-Product Market Fit). As these companies scale up, however, several patterns emerge almost unavoidably. Let’s look a bit closer at FIY’s growth path:

• Once FIY’s initial product was successful, they launched a new product to increase their customers’ lifetime value. This meant scaling up the product organization to multiple teams. Without a strategy/operating model for managing those teams, the span of control and perceived need for involvement hampered decision-making. Leadership became a decision-making bottleneck.
• Extending FIY’s product line meant that each product now has its own goals and priorities, but they are all dependent on the same shared resources for delivery. Leadership oversight is required to foster collaboration across product teams and identify delivery synergies.
• FIY’s Leaders are now splitting their time between newly introduced growth initiatives while still being expected to provide high-quality oversight to their existing product lines. Growth and business dynamics necessitate transformation (e.g., adopting a different marketing/sales motion, adopting GenAI, moving to SaaS). These are often complex and require time-intensive collaboration across functions. Devoting the time and energy needed to work through cross-functional issues reduces the capacity of team members to stay on top of their other delivery work. At this point Mary is realizing that FIY needs to upgrade its operating model. What worked for a singularly focused small product team is not up to the scale of FIY’s current product organization’s size and complexity.

Does your technology/product organization need an operating model upgrade?

Over to you now. Ask yourself the following questions to uncover any issues with your current operating model:

• Are you managing multiple strategic initiatives that span multiple teams across the organization?
• Are you now developing/maintaining multiple products?
• Are the leaders becoming a bottleneck?
• Are you considering standing up a project/program management discipline? Answering “Yes” to these questions indicates that you might need to upgrade your operating model.

The Usual Suspects - Company-level Operating Systems for Scaleups Mary’s search for better ways to manage the growing complexity starts outside the product and technology organization. One of FIY’s board members, a partner at the VC firm who led their B round, suggested they use OKRs to create company-level clarity and alignment. OKR stands for Objectives and Key Results - a popular company-level operating system. Other examples of such operating systems that you mind find in companies like FIY are the Entrepreneurial Operating System (EOS), Scaling Up, or even 4 Disciplines of Execution (4DX). A common thread to all of these systems is that they all include Goals, whether they call them Goals, Rocks, OKRs, or WIGs. As part of FIY’s OKR implementation, Mary’s product/tech organization created objectives and key results for all of their teams and initiatives, but other than having one more management tool to pay attention to, nothing much is different. Across the organization and inside the product/tech org, the work towards these goals is still managed the same way. Goals are still set by department, and cross-functional dependencies are as painful as ever. Mary is still on the lookout for a way to scale her organization’s speed, throughput, and impact. In other words, Mary wants her organization to stay agile as it scales. Staying agile as you scale Agile ways of working are designed for single products. Even multi-team scaling patterns assume cohesion and unity of purpose. But let’s say we did want to use agile principles and techniques to align investments, priorities, and execution across multiple separate products and initiatives. What does that look like? A Scaling Company IS a Portfolio Mary isn’t running a classic IT shop. She’s not a PMO. But she’s starting to realize that she IS managing a portfolio of multiple products mixed with multiple organizational strategic initiatives. If you’re leading a growing/evolving company with hundreds of people / dozens of teams, more likely than not that’s your reality - you are managing a portfolio of investments/initiatives that map in a non-trivial way to teams and functions. Portfolio management is a layer that ensures strategic alignment and the effective execution of the organization’s top priorities.

Managing and Improving Portfolio Agility

Here’s a quick overview of what it means to manage a portfolio using an agile perspective:

• Start by recognizing that you already have a portfolio of investments, even if it’s not formalized.
• Start to understand your portfolio and the flow (or lack thereof) of your significant investments.
• Begin to actively manage the flow and shape demand. This includes the brave action of saying “No” or “Not yet”.
• Turn the collection of projects into cohesive products—creating an intentional balance between technology and business investments.
• Decide which decisions to manage at the portfolio level, and which decision-making authority you empower the teams to have. A key enabler for this is deciding what is the threshold at which work will be managed at which level.
• Improve alignment AND autonomy. Teams are free to innovate, while strategic goals keep everyone focused on the outcomes that matter. Eventually, over several quarters if not years, you’ll be operating in full agility mode—treating your entire business like a product. This will not happen overnight! Be patient. This approach isn’t for everyone. It’s not a cookie-cutter process. It doesn’t have a certification training. There aren’t hordes of coaches who can claim they know it. And there’s no framework to parrot. But if you’re interested in adopting a principle-based, evolutionary, light-weight, focused intervention approach to improving the speed, throughput, and outcomes of your product/technology organization, you’re in the right place.

What about SAFe Lean Portfolio Management? If your organization is already invested in the Scaled Agile Framework (SAFe) you’re probably familiar with SAFe Lean Portfolio Management (LPM) - a framework geared toward improving portfolio-level agility, with a special focus on the context of enterprise-scale IT. I find the full LPM to be a bit much for scaleups and mid-market organizations. However, some of the concepts of SAFe LPM are aligned with the approach to portfolio agility described here, and are applicable to any organization that’s tackling multiple initiatives, products, and dozens of teams. I find it useful to complement SAFe LPM with a focus on outcomes and evidence-informed steering, so even if you’re already familiar with LPM, I invite you to keep reading.

As we discussed earlier, companies often struggle to drive strategic cross-functional initiatives, especially as they scale and the work spans more and more teams and leaders.

Companies know cross-functional initiatives are tough, so they try to avoid them, preferring to divide and conquer. However, running them siloed doesn’t make the challenges disappear. It just hides them. Strategic, deep transformations DO require collaboration across multiple functions/disciplines. It’s time to shine a light on what’s really going on in your organization.

You can’t improve what you can’t see.

The first step to improving the flow of work across the organization is to make the big picture visible. Without visibility, improvement isn’t possible.

So, how do you start ‘seeing’ flow (or the lack of it)?

A Kanban board is a simple, effective tool for mapping your organization’s most significant initiatives. Think of it as a visual snapshot of what’s happening across your teams. Your Kanban might include a long list - or just a few work items - either one is perfectly fine. Don’t worry about defining ‘significant’ right now either. You’ll have time to refine and prioritize later. Start with what you have. Here’s a high-level view of what it takes to start to see flow using a portfolio kanban board:

• Figure out the boundaries of your workflow - where are we starting to track initiatives? When do we finish tracking them?
• What is the workflow for these initiatives? What stages do they go through? These turn into columns on the board.
• Create a sticky note, box, or card for every initiative. Place the card in the appropriate column based on the stage its currently in.
• Look for implicit connections. Are there multiple initiatives that are tightly dependent on each other - that should be managed as one unit?

Defining the start and finish boundaries. It might look obvious, but there are some interesting questions to explore here: When do you start managing initiatives? When the initiative is still just an idea? (a twinkle in a business stakeholder’s eye…) Or when the “business” is ready to ask technology to support it? The earlier you intercept an initiative, the more opportunities to improve speed and impact you can identify. For now, it might make sense to start with work that is already in flight and be ready to evolve towards Idea management later as you get buy-in.

When do you stop managing initiatives? Remember, Agility is about execution. We are not managing everything. We are responsible for taking Ideas aligned to strategy and transforming them into deliverable outcomes. Once the outcome has been achieved, the maintenance and measurement of that outcome moves off the Portfolio Kanban and onto the Operational roadmap. So it’s critical to define when is the right time to move to “business as usual”? Again, start with where you are right now and discuss whether to make a change to this flow boundary now or consider it later. Identifying What Should be on the Board

Which investments SHOULD be managed at the Portfolio level?

Here’s a simple technique you can use to answer this question. Analyze the cards on your portfolio kanban according to the three criteria below:

• Investment size
• Strategic opportunity/risk
• Level of cross-product collaboration needed

Duration vs Size - a common guidance you might encounter is to consider investments that might span multiple quarters as worthy of portfolio consideration. On paper, this could be a good proxy for size. In reality, many organizations spread their capacity and attention too thin across too many investments - meaning that initiatives might span multiple quarters even though they’re not that big - because only a few people are working on them, and they’re also multi-tasking. This is why size is a better criteria.

Use 1 for low/small, 2 for medium, 3 for high. Add up the numbers for the 3 criteria:

• 3-4 This should probably NOT be a portfolio-level card.
• 5-6 Let’s have a conversation about whether we want to manage these
• 7-9 This SHOULD be a portfolio-level card. Why? We want the portfolio conversations to focus on investments/initiatives with more significant, higher opportunity/risk, high cross-product collaboration. For all other investments, decision-making should be decentralized to empowered product teams. This doesn’t mean portfolio leaders don’t care about these other investments. However, they trust their product teams and maintain a lighter touch interface compared to those investments the portfolio leaders want to focus on. We managed these non-portfolio initiatives by including an “Awareness” slide in the monthly Portfolio review meetings. Smaller projects being worked on by the Teams that were also doing “portfolio” work were shown on a slide “For Awareness Only” so that leaders knew the work was being done, but they were not expected to “manage” it. Over time, you’ll want to sense whether you’re managing the right altitude at the portfolio level:
• Altitude Too Low: Conversations become tactical, lengthy, business leaders start to lose interest.
• Altitude Too High: Strategic work isn’t discussed, side channels are used where the key behaviors aren’t reinforced
• Cruising Altitude: Conversations are engaging, appropriate, steering at just the right level.

There’s a reasonable likelihood that the Portfolio Kanban Board you created is Busy. There is a mix of reasons for this:

• The organization is working on too many things at the same time.
• The organization is too centralized - a core group wants to see everything and wants to actively manage too much.
• The organization is tangled among different factions - Instead of collaborating, multiple groups are establishing their own agendas and their own kanban boards. Representing each group’s work on the Portfolio Kanban, while busy, will reveal redundancies and duplicative efforts. Once you establish a Portfolio Kanban board to see all the work you’re managing, you should consider whether you NEED to manage this work at the portfolio level. It may be time to review and refine the definition of the portfolio workflow, focusing on which items should be processed at the Portfolio level, and what work should be managed at the initiative or team level.

Descale Your Portfolio By Organizing Around Outcomes

If this exercise points to many cards that need to be managed at the Portfolio level, one conclusion would be that you indeed need to invest in better portfolio management, coordination mechanisms, etc. “Level of cross-product collaboration needed” is a factor for managing an investment initiative at the portfolio level because the higher the number of collaborators required, the more effort is needed to align priorities and focus execution. But what if we found a way to reduce that level of effort?

This is what is meant by descaling. Descaling means:

Minimizing the number of in-flight outcomes spanning teams/groups/functions.

• Limit the work-in-progress to fewer multi-functional, cross-portfolio outcomes being worked on simultaneously.
• Prioritize the outcomes to make it clear where Resources should be dedicated first.

Minimizing the number teams/groups/functions that an outcome requires for delivery.

• Create stable “broader-perspective” teams or transient “strategically focused” teams aligned around prioritized focus areas
• Evolve the product/business architecture to support self-service, reduce coupling, and minimize the need for coordination/collaboration Here are some ways to think about descaling:
• Identify the constraints – the usual suspects involved in everything. In many cases, 80% of the dependencies map to 20% of the teams…
• Look for topology options that might work better.
• Consider whether architectural interventions such as introducing a self-service platform can help melt some of the iron spaghetti.
• Consider aggressive cross-team/function T-shaping – enabling people/teams to do work currently limited to specific, constrained teams. Come up with several design options and compare them (as well as the current state) based on:
• 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 of a change from the current state is this option? Change is hard…?
• How much product/technology/people risk does this option entail (e.g., distributing a core capability with limited know-how)?
• How future-proof is this option? How aligned is it with our strategy? What’s on the horizon? When we find a significantly better alternative worth exploring, we evolve it like a product – we clarify the desired outcomes and leading indicators, agree on a discovery approach, and tackle it incrementally if possible. To sum up, Reorganizing around outcomes could lead to better Flow and effectiveness. A Flow perspective can catalyze such conversations.

Actively Managing Portfolio Flow

If your Portfolio Kanban still looks like a traffic jam in rush hour - full of cards, without much movement - don’t despair. Seeing the swamp is the first step in shaping it into a river. No New Work. Freeze. Differentiated Service. Applying WIP Limits. Those are patterns you can apply to start shaping the flow. Here are a few of my favorites:

1. Right To Left Kanban Reviews

It might be as simple as reviewing the board and discussing the work right to left (instead of left to right – the way work flows). By using this “Hebrew mode,” you are focusing on finishing work already in progress and only getting to discuss starting new work after the weight of all the investments already in progress, which is essentially demotivating you from even considering it. You can use this nifty “system” to nurture a habit of stop starting, start finishing.

2. Look for Flow Constraints

As you start focusing on flow, you’ll begin to see constraints:

• The one team/group involved in everything (maybe it makes sense to be even more careful when introducing new investments involving them)
• The investments that are so big that they occupy their “lane” much more than others (maybe it makes sense to break them into independent investments each worthwhile on their own and accelerate time to market? )
• Investments where you feel like you’re running blind – with no transparency about what’s going on & no leading indicators for months about whether this investment will be worthwhile. (Which can be an excellent opening for exploring outcome-oriented, evidence-informed portfolio management)

There’s so much that actively managing portfolio investments using a flow perspective can tell you. And so many opportunities for further improvement emerge organically. That’s the beauty of using Kanban. It catalyzes dialogues about improvement rather than telling people how to improve. Actively managing flow on a Portfolio Kanban won’t magically turn a project-oriented organization into a product-oriented portfolio. But it is one of the most effective ways to start the path.

Work will expand to fill the time you give it - In order to accelerate flow, you need to measure and manage flow

Kanban/Flow Metrics can help sharpen your flow focus even further. The four flow metrics described in the Kanban Guide for Scrum Teams / Kanban Guide are Work in Process (WIP), Cycle Time, Throughput, Work Item Age (WIA).

How can these metrics help us at the Portfolio level?

Work In Process (WIP)

While we can see the current WIP just by looking at the Portfolio Kanban, explicitly measuring the WIP level and seeing it trend over time can provide deeper insights into opportunities for waste reduction and flow acceleration.

Cycle Time

Portfolio-level investments will take months to finish - not weeks, and hopefully not years. Cycle Time measures exactly how long and gives us key information about our time to learn and time to market. Over time, we can hopefully establish a Service Level Expectation (SLE) that will help us manage our expectations around investment workflow.

Throughput

How many investment initiatives are we delivering every quarter? Year? Throughput doesn’t care about the size of the investments. It counts investments “finished” in a unit of time. Remember – in most portfolio workflows finished means “we’re done treating this as a high profile investment – it’s now back to business as usual”. With information about the overall throughput, we can have some interesting conversations about the funnel leading into the workflow. For example – if we learn that our throughput is 3 investments a quarter (I know multiple portfolio teams who would love to have that) – how many investments does it make sense to consider each quarter? What’s the proper shape of the consideration funnel? Where are our bottlenecks/constraints?

Work Item Age

What if we had an early warning system alerting us to specific initiatives that aren’t flowing as well as the others? This is what Work Item Age does. It shows us the age of active initiatives and highlights those that have been active the longest, especially considering where they currently are in the workflow.

Now what? Start measuring flow metrics for your Portfolio Kanban.

Do that as soon as possible because it will take time to see meaningful data. You can wait a bit with analyzing and discussing the data, but once you get to it, you’ll have some interesting baseline and trend data to look at. If you do have some historical data from the current project/program management system, you can try reverse engineering flow metrics to accelerate establishing a baseline. This data can also help you decide whether you want to invest in portfolio-level flow. Finally, a warning. It’s essential to focus on flow. And it is the right place to start. But it’s far from enough.

Let’s say we meet 2 months from now, and you have implemented everything we covered so far. There’s much better traction; execution is streamlined. You might be more efficient at doing strategic cross-functional work, but…

• Does that work result in the outcomes and impact we had in mind?
• Do we even know what outcomes we’re aiming at? What real success (not checking the box) looks like?
• Are we managing the risk of missing the mark (even though we’ve done the work we planned to)?
• Would we change direction if we weren’t on the right track? Would we even know we need to?

Project to Product

These are all shortfalls of the classic project-oriented mindset. Product Operating Models address these issues by:

• Aligning around outcomes
• Providing flexibility in advancing towards these outcomes
• Using leading indicators and frequent feedback loops to steer. Scrum and Lean Startup are examples of frameworks that help instantiate a product mindset. But how do we apply these ideas to strategic initiatives that span the organization and aren’t necessarily product-related?

Back to FlowImpact Yoga

Remember FIY? They started managing their business initiatives in a high-level Kanban board. They plugged in all of their in-flight initiatives and got going on seeing and improving flow. They got to the point of more efficient strategic execution. Like us, they realized they needed to move from project to product thinking to become effective. Jim, the CPO, brings up the language of “Bets,” which he learned in a Product Leadership Slack Forum. They decide to apply the concept of outcome hypothesis with leading indicators to the cards on their kanban board, even though those cards don’t always reflect products. When they get together, they review these leading indicators to decide whether to continue investing, pivot, or stop altogether. They also decided to change their workflow to separate “Discovery/Exploration” and “Execution” to reflect the concept of the truth curve - where you aim to learn as efficiently as possible, whether you’re on the right track before you fully commit. (aka Fire Tracer Bullets, Then Cannonballs). This clear distinction on their Kanban board ensures they have the right conversations about which initiative is a bet that requires discovery and when it is ok to skip to execution. They also introduce a policy of integrating “measure and learn” into their Kanban workflow. They agree on a set of questions they will consider for initiatives in flight:

• Have we achieved our outcome hypothesis?
• What can we learn from the metrics?
• Are we still making progress, or are we seeing diminishing returns?
• Is this still a business constraint? Fast forward a few months - While fewer business initiatives are in motion, more initiatives impact the metrics that matter, and the business has improved traction overall. FlowImpact Yoga is now executing with better Flow and more substantial Impact.

Outcome-oriented Kanban Cards That Encourage Steering with Evidence

Since OKRs (Objectives and Key Results) are a common approach for setting goals in scaleups and midsized organizations, let’s use them as an example of how to orient around outcomes. While OKRs are very popular, a common anti-pattern is to use them in a traditional project mindset focused on outputs/activities. A good start is to use OKRs as your Kanban cards – meaning each card will include an Objective and a small set of Key Results - focusing on outcomes, providing leading indicators that enable steering. Make sure to consider an outcome hypothesis. What are we hoping to see? What’s going to look different for all the various stakeholders? And what is going to be the impact of this changed environment on our business? Describe some leading indicators – How will we know we are heading in the right direction? How will we know we’re not? OKRs as cards is just one idea. Here are some other options to consider:

• If you’re a serious Lean shop, Your cards might represent A3 canvases focused on a problem/opportunity.
• If you’re a Lean Startup fan, you might use Lean Canvas as your card format (yes - even for internal initiatives!). The Why Now Elevator Pitch format is a good way to structure a story based on your lean canvas.
• Inspired by the Spotify Model? Your cards can represent Bets based on DIBBs (Data, Insights, Beliefs, Bets)
• Interested to dive deeper into outcome orientation and managing risk by evidence-based steering? Check out Evidence-Based Management. If this is all a bit daunting, you can start lightweight by just ensuring the card name is outcome-oriented instead of specifying the solution/activity.

Kanban Workflows that Encourage Evidence-based Steering

The card format isn’t enough. You also need to structure your Kanban flow to encourage outcome orientation and empiricism. Here’s an example:

By explicitly defining the Discover / Tracer Bullets as a step, we’re driving conversations about validation before proceeding to execution. Spotify’s Think It Build It Ship It Tweak It is another example. Find the flow and language that work for you. The key is to encourage the right conversations when considering and steering investments. One significant advantage of having these conversations at this level is that it provides a model for conversations throughout your organization.

All Together Now

At this point, you have a trail map that shows you a few paths you can take to improve traction towards outcomes on your strategic initiatives These paths guide you on:

• Encouraging strategic focus by seeing and limiting the number of strategic initiatives in motion
• Balancing effectively between alignment and autonomy
• Improving flow and traction by (re)organizing in ways that make it easier to collaborate around multi-disciplinary cross-portfolio cutting initiatives
• Improving value by providing clarity on what outcomes we are looking to achieve and giving execution flexibility

Now you know. And knowing is half the battle.

BUT We still need to discuss deploying this new operating system. That’s what we cover in the next chapter.

In this chapter, we won’t learn any new concepts or practices. Instead, we will discuss how to use the product-oriented thinking and practices we already established are worthwhile when pursuing strategic change/transformation, for our organizational operating system upgrade (which is strategic change/transformation itself!).

Product-oriented Change / Transformation

What does that look like? Pretty much like what we’ve learned so far in the course:

Actively manage the flow of your most significant investments

Therefore, make sure not to pile this operating system upgrade on top of everything else you’re doing in the organization. Consider it as part of your organizational WIP (work in progress).

Descale by organizing around outcomes

Determine who’s the team that would need to work on this and let them work directly together. Does creating a team in the organization that owns “operating systems” makes sense? Maybe, Maybe not. Like any other initiative, that’s a strategic question to consider.

Reduce risk through speed and evidence-based management

Use agile, product-oriented ways of working to manage and derisk this initiative. Determine a benefit hypothesis and define leading indicators. Agree on success and kill criteria. Discover/explore if its useful through a focused minimally viable change (tracer bullet). Validate/Invalidate and steer based on evidence.

Walk the talk

It’s tempting to say - it’s apparent that we need this operating system. To mandate rather than take the time to invite/figure out. And you’ll probably rely on SOME conviction, charisma, authority. But remember - you’re expecting people to approach initiatives this way as part of the new operating system. So, better try to walk the talk. And be open about how hard it is. And about learning. (It often helps to have an outsider to remind you and challenge your comfort zone…)

Now it’s up to you

You know enough to get started. It doesn’t have to be perfect. Just get going. The Product-oriented Portfolio Agility Trail Map describes a lightweight, easy path to get started with. (Like any trail map, you can always go with a double black diamond on your first run.) Within a few days/weeks, you could probably have a live portfolio Kanban board mapping your initiatives and where they are. You could start some conversations about using more outcome-oriented language. You could revisit your goal-setting processes to introduce some flow and focus. You could start having conversations about traction on leading indicators, not progress on scope. You could start an experiment with a virtual team working together towards a multi-disciplinary strategic goal. Even if it’s just changing the language you use in your existing conversations, documents, artifacts, or meetings, you’re getting somewhere.

Try, Inspect, and Adapt

Make sure to stop and reflect every once in a while. I recommend saving this email. Maybe snooze it for a month. Then open it, reread it, and reflect with the team working with you on the operating system upgrade - how are we doing? What evidence are we seeing? What’s next? If you feel good about where you are - maybe turn some tracer bullets into a cannonball (by instituting an experiment) If you feel ready to pursue additional improvement opportunities, you can re-read the minibook to find ideas. You can also use a principle-based assessment to help you assess your current situation and support a structured conversation about your next steps. This is a trail map, not a roadmap (or a blueprint). That means there are multiple paths, and I don’t know which one you should take. I’m just trying to help you familiarize yourself with the terrain. Here are some example paths –

• When leaders wanted to improve empiricism and reduce investment risk, we improved the definition of workflow to reflect better and encourage product discovery behaviors. We also introduced a key decision: whether to go through discovery or skip it straight to delivery.
• When a product leader wanted to empower product teams, even when working on the most significant initiatives, we emphasized structuring these initiatives around outcomes, using OKR language instead of classic PRDs and business cases.
• When an enterprise struggled with an unsustainable pace, a key intervention was a planning exercise inspired by agile planning techniques. The different groups involved collaborated to create a realistic roadmap using pull mode.
• When a pharma company was scrambling to tackle too many organizational transformations at one time (trying to implement recommendations by a top consulting firm), to the point where key players were stretched too thin between their ongoing work and multiple transformation “Sprints” it was time for a tough conversation about organizational focus, organizing focused teams by empowering a larger group of people that WOULD be able to focus on a specific mission, and introducing a language of discovery and empiricism to how the initiatives were managed, that enabled real agility in the trenches. What challenge will YOUR future self be working on? Who knows…

Wow! You’ve covered a lot of ground in the The Product-oriented Portfolio Agility Minibook Here’s a quick recap: Chapter 1: Why Is Your Organization Getting Slower/Stuck As You Scale? Chapter 2: Finding a Company Operating System To Help You Regain Traction Towards Outcomes As You Scale Chapter 3: Establishing and Accelerating Flow Of Your Most Significant Initiatives Chapter 4: Improving Traction by Organizing Around Outcomes Chapter 5: Reduce Risk and Improve Outcomes Chapter 6: Using the Trail Map To Evolve Towards Organizational Traction What’s next? First of all, keep the minibook as a reference to help nudge you on your portfolio agility path. (If you’d like, this trail map is also available as an email course) I’m passionate about the potential of upstream interventions such as portfolio agility. I love working with scaleups and larger organizations struggling with scaling/agility challenges and helping them use these upstream interventions to get through their scaling inflection points. I’m sharing my insights on portfolio agility, using agility principles, developing your company as a product, and other topics that come up during my work in the field in the Scaling w/ Agility Newsletter If you want to work with me on portfolio agility or some other interesting challenge - let’s discuss. Finally - Was this minibook useful? If so, would you be willing to leave me a review?

Additional portfolio workflow notes

2. Workflow Stages

Next, you’ll have to define the states that the items flow through in between. You might already have a workflow. Or maybe you will want to take inspiration from SAFe’s LPM, Spotify (Think it Build it Ship it Tweak it), or some other variant.

Again, be careful to have a dialogue about whether to start with what you have or leap into a new model.

3. It’s YOUR Portfolio Workflow - Make It Yours!

In any case, the key point about all elements of the definition of workflow is that you, as the portfolio team, should own it. What you have right now is just the starting point. Commit to trying it, inspecting, and adapting as needed based on whether it fits your needs well. Over time, you’ll want to bring in better flow, outcome orientation, empowerment/autonomy, and empiricism. You’ll be able to see if you’re product-oriented and have some evidence that will feed your product topology inspection and adaptation. You have to start somewhere. It’s better to start seeing the flow now, then spend weeks/months figuring out your ways of working (not to say product structure), and only then get going.