Scaling Product Orgs with Portfolio Agility

You built empowered product teams. You wrote down a product operating model. And somehow decisions still stall, competitors still pivot faster than you do, and every initiative that actually matters turns into a program with a coordination tax attached. The cross-product process you added to bring order and reduce risk doesn’t stop the wrong things from getting built; it just makes building anything slower. That gap between the operating model on paper and the one people work in every day is the portfolio problem, and most of the standard answers to it are borrowed from project and program management, which is exactly why they grind against the way product organizations want to work.

This minibook takes a different route. Instead of standing up structures and processes first, it starts with the portfolio behaviors you want (the conversations, the thought process, the decisions), and then asks what the minimum process is that would actually produce them. That is the main thing separating this from frameworks like SAFe Lean Portfolio Management. The test isn’t whether you ran the ceremony on schedule. It’s whether someone in the room was willing to ask “do we really have the capacity and the attention span for this, or should we finish what’s already in flight and reconsider?” — and whether the answer changed what you did next.

What this looks like from where you sit

Three symptoms show up together, and leaders usually name at least two of them before they name the portfolio:

• Decision paralysis. Uncertainty and complexity bring things to a standstill. Teams operate in silos and can’t adapt without a meeting to authorize it.
• Missed opportunities. You watch competitors pivot while your organization works hard to hold the status quo in place.
• Cross-functional hell. You created agile and product teams, and yet every meaningful change still requires so much collaboration that it becomes a project or a program.

That is the portfolio challenge: managing a growing set of technology and product investments well enough that the ones you picked actually land. It is an established practice, which is part of the trouble. The established version of it leans on traditional project and program management, and those habits clash with the product operating model you are trying to run underneath.

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.

What you’ll walk away with

This is a straightforward introduction you can adapt to a scale-up or mid-sized tech and product context, not a dense reference. By the end you should be able to:

• Decide whether you need a defined portfolio operating model at all, or whether your context doesn’t warrant one yet.
• Start where you are, using visibility, focus, and flow as a low-risk first intervention rather than a reorg.
• Descale the portfolio by organizing around outcomes and products, so there are fewer dependencies to coordinate in the first place.
• Reduce risk on your most strategic initiatives by moving from outputs to outcomes and steering on evidence instead of on reported progress.
• Treat the operating model itself as a product, with its own outcomes, reviews, and iterations.
• Show up as a portfolio leader whose language and behavior model what you’re asking of everyone else.

How to read it

You can go cover to cover for the lay of the land, or pick your own route, since it’s a trail map rather than a roadmap. Either way, stop and reflect occasionally: are you seeing something new? Is there a fork here you hadn’t considered? Here is how four leaders actually made their way through:

• Mark wanted better empiricism and less investment risk, so he refined the definition of workflow to encourage product-discovery behaviors, and introduced one explicit decision: do we go through discovery, or skip it and go straight to delivery?
• Susan, a product leader at a midmarket company, wanted her teams empowered even on the biggest initiatives, so she structured those initiatives around outcomes and used OKR language instead of classic PRDs and business cases.
• Ed’s enterprise was running at an unsustainable pace. The intervention was a portfolio-level planning exercise borrowed from agile planning, where the groups involved built a realistic roadmap in pull mode rather than having one handed to them.
• Emily, a COO in pharma, was trying to run several organizational transformations at once from a top consulting firm’s recommendations. Key people were stretched thin across their day jobs and multiple transformation “Sprints”. That forced a hard conversation about focus, which led to empowering a bigger group to own one specific mission, and to bringing discovery and empiricism language into how the initiatives were run. Adoption got faster once the work got narrower.

If you have been near a portfolio before, the behaviors-first framing should make you suspicious. Process discipline is what portfolio management is for. Frameworks like SAFe Lean Portfolio Management specify the cadence, the roles, and the artifacts precisely because leaving those to good intentions is how organizations end up with a spreadsheet nobody trusts and a quarterly meeting nobody prepares for. Say “we care about behaviors, not process” out loud in a room of experienced portfolio people and at least one of them will hear “we’re not going to hold anyone to anything.”

That objection is fair, and the answer is not that process doesn’t matter. It’s that process is the dependent variable. Pick the behavior you want first — someone willing to say “we don’t have the attention span for this right now” — then install the smallest process that reliably produces it, and keep checking that it still does. A Portfolio Kanban, a PI Planning event, or a monthly review can all carry that conversation; the format matters much less than whether the conversation happens, whether the thought process gets applied, and whether decisions change as a result. What this approach rejects is the reverse move: adopting a full ceremony set on the theory that the behaviors will follow. They usually don’t, and then you are stuck defending the process instead of the outcomes. So the standard here is a Minimally Viable Process — enough structure to move the behaviors you care about, and no more than you can honestly sustain.

Meet Mary, a co-founder of FlowImpact Yoga (FIY), a rising power in products serving the yoga and pilates industry. A successful initial product let FIY invest in extending the suite — more capabilities for their core client, Yoga Studios, plus a branch out to Pilates studios and gyms with a yoga studio. The product and technology organization recently crossed 200 people, and with that size came the expectation of more throughput, more speed, and more impact to support the company’s growth while keeping existing customers happy. Mary has run product and technology through all of it.

Recently she noticed a problem she can’t explain away. As the organization grew, it could work on more products and initiatives — but overall throughput hasn’t grown at the pace of the investment. It’s stuck, and arguably regressing. Worse, the features that do ship aren’t landing the way they used to. It’s full gas in neutral. More time goes to meetings and coordination, and managers have become the bottleneck as they try to broker cross-functional dependencies across silos and emerging fiefdoms. Instead of a lean, flexible startup, FIY has quietly become a slow 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 that led their B round, suggested OKRs to create company-level clarity and alignment. Other systems you might find in companies like FIY are the Entrepreneurial Operating System (EOS), Scaling Up, or 4 Disciplines of Execution (4DX). The common thread is that they all include goals, whether they call them Goals, Rocks, OKRs, or WIGs.

So FIY’s product and tech organization wrote objectives and key results for every team and initiative — and other than one more management tool to keep current, nothing much changed. The work toward those goals is still managed the way it always was, goals are still set by department, and cross-functional dependencies are as painful as ever. Mary is still looking for a way to scale her organization’s speed, throughput, and impact. In other words, she wants her organization to stay agile as it scales.

Staying agile as you scale

Agile ways of working are designed for single products. Even the multi-team scaling patterns assume cohesion and unity of purpose. But suppose we did want to use agile principles and techniques to align investments, priorities, and execution across multiple separate products and initiatives. What would that actually look like?

A scaling company IS a portfolio

Mary isn’t running a classic IT shop and she isn’t a PMO. But she is starting to realize that she is managing a portfolio — multiple products mixed with multiple organizational strategic initiatives. If you’re leading a growing company with hundreds of people and dozens of teams, that’s probably your reality too: a set of investments and initiatives that map to teams and functions in a non-trivial way. Portfolio management is the layer that keeps those aligned to strategy and actually executed.

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.

Why the hard initiatives get hidden rather than fixed

As we discussed earlier, companies struggle to drive strategic cross-functional initiatives, and it gets worse as they scale and the work spans more teams and more leaders. Companies know these initiatives are tough, so they try to avoid them and divide and conquer instead. Running them siloed doesn’t make the challenges disappear, though. It just hides them. Strategic, deep transformations do require collaboration across functions and 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 making 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.

Your new board is probably busy, and that’s information

There’s a reasonable likelihood that the Portfolio Kanban board you just created is busy. Usually it’s some mix of these:

• 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?

That is what descaling means, and it works on two fronts at once.

Minimize the number of in-flight outcomes that span teams, groups, and functions:

• Limit work in progress to fewer multi-functional, cross-portfolio outcomes running at the same time.
• Prioritize those outcomes so it’s clear where people should be dedicated first.

Minimize the number of teams, groups, and functions any one outcome needs in order to land:

• Create stable “broader-perspective” teams, or transient “strategically focused” teams, aligned around prioritized focus areas.
• Evolve the product and business architecture to support self-service, reduce coupling, and cut the need for coordination in the first place.

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 a self-service platform can melt some of the iron spaghetti.
• Consider aggressive cross-team and cross-function T-shaping, so people can do work that’s currently locked to specific constrained teams.

Come up with several design options and compare them — including the current state — on:

• How much of the portfolio’s work gets localized under this option? Aim for the majority; 80% would be better.
• How big a change from the current state is this? Change is hard.
• How much product, technology, and people risk does it carry (say, distributing a core capability to people with limited know-how)?
• How future-proof is it? How well does it fit the strategy, and what’s on the horizon?

When you find a significantly better alternative worth exploring, evolve it like a product: clarify the desired outcomes and leading indicators, agree on a discovery approach, and tackle it incrementally where you can. Reorganizing around outcomes leads to better flow and effectiveness, and a flow perspective is usually what gets that conversation started.

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

Knowing the paths isn’t the same as walking them

Which leaves the part everyone underestimates: actually deploying this operating system in a live organization. That’s 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

Stop and reflect every once in a while. Bookmark this, and come back to it in a month with the team working on the operating model upgrade: how are we doing? What evidence are we actually seeing? What’s next? If you feel good about where you are, turn some tracer bullets into a cannonball by committing to a real experiment. If you’re ready for the next improvement, re-read for ideas, or use a principle-based assessment to structure the conversation about where to go next. This is a trail map, not a roadmap. There are multiple paths and I don’t know which one is yours — I’m just trying to help you know 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…

You’ve covered a lot of ground. A quick recap of the trail:

• Chapter 1. Why your product/tech organization gets slower as it scales.
• Chapter 2. Finding an operating model that regains traction toward outcomes at scale.
• Chapter 3. Understanding your portfolio, and establishing flow boundaries you can see.
• Chapter 4. Establishing and accelerating flow on your most significant initiatives.
• Chapter 5. Reducing risk and improving outcomes by steering on evidence.
• Chapter 6. Using the trail map to evolve toward organizational traction.

Keep this as a reference to nudge you along your portfolio agility path. I’m genuinely interested in upstream interventions like this one. I like working with scaleups and larger organizations that are stuck at a scaling inflection point, and helping them use portfolio-level moves to get through it. If you want to work together on portfolio agility or another interesting challenge, let’s talk.

Workflow stages. You’ll have to define the states items flow through between your start and end boundaries. You might already have a workflow. Or you might want to take inspiration from SAFe’s LPM, Spotify’s Think it / Build it / Ship it / Tweak it, or another variant. Either way, have the dialogue about whether to start from what you have or leap to a new model — don’t let the choice happen by default.

It’s your portfolio workflow, so make it yours. The key point about every element of the definition of workflow is that you, as the portfolio team, should own it. What you have right now is a starting point. Commit to trying it, inspecting, and adapting based on whether it actually fits. Over time you’ll want to pull in better flow, outcome orientation, autonomy, and empiricism, and you’ll be able to see whether you’re genuinely product-oriented — with evidence that feeds your product topology decisions. You have to start somewhere, and it’s better to start seeing the flow now than to spend months settling your ways of working (never mind your product structure) before you begin.

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