- The Uncertainty Project
- Posts
- đź Transformation as BAU
đź Transformation as BAU
Harnessing the power of portfolios in the Product Operating Model
Good morning!
At the Uncertainty Project, we explore models and techniques for managing uncertainty, decision making, and strategy. Every week we package up our learnings and share them with the 2,000+ leaders like you that read this newsletter!

Iâm going to go out on a limb here, and assume that many of the models and practices weâve described here in The Uncertainty Project are not part of your established ways of working. They are not âbusiness as usualâ (BAU). Theyâre aspirational. And thatâs okay!
Last week, we talked about how you could get started on some local experimentation around some practices. This week, weâll rethink the idea of transformation as a whole.
Whatâs the best way to drive improvement in strategic decision-making and uncertainty management in your organization?
The concept of running a high-profile âtransformationâ to pursue big new ideas has been the default way for large organizations to secure the right amount of sponsorship from the top, attention across the front-lines, and budget to support the changes. But these âbig bangâ change initiatives are exhausting, and since they are usually run âas projectsâ, they are subject to the same challenges that any large program- or project-funded change effort will face:
Over-design up-front
Little room for local adaptation to context
Vanity metrics to measure progress
Slipping end dates
Weak discovery or learning environments
And perhaps the biggest issue is that, like any massive project effort, youâll be waiting a long time before you start to see the realization of the value promised by the change. Years, even.
These large transformational change efforts take shape as programs to bring new skills into the existing organization. There is an emphasis on training, certifications, upskilling, and piloting new practices. Itâs a strong âpushâ motion, with a weaker âpullâ motion by the people being coerced into change. The desired impact of the change can get lost in all the discussion around âwhatâs newâ and whether âwhatâs newâ is actually âbetterâ in the local context.
What if large change (i.e. transformations) became more of an all-the-time, continuous sort of thing? What if the re-inventing, re-imagining, transforming, and continuous improvement was just part of âbusiness as usualâ?
Could that work?
If you are an operations leader today, you might already feel like this is your reality.
What would it take?
Who decides if itâs even a good idea to change (at any point in time)...?
As we explore this path, then there are a couple things we are seeking (relative to the current âbig transformationâ approach):
More local decisions on how to (and whether to) change
More local accountability for achieving better results (i.e. impact of change)
The argument you hear for transformation (in general) is that the pace of change in our competitive or technology landscapes is so high, that we must keep up, or fall down. So the place to start (locally, of course), is with that question:
In your local context, how fast is the rate of change?
Youâll want to take an outside-in angle on this question. You might even be in the dark on whatâs happening in your domain! (Hopefully not). But put yourself in the shows of your customers or end-users, and think about how they might answer the question, too.
If you decide the pace of change is significant, and affects your competitive environment, then youâre in a strategic space. Itâs time to explore the possibilities, for new strategic directions, and make some investments in learning about that new path.
Then what? Imagine a dramatically different future state, and design a big project to execute the change? Thatâs the transformation model.
But if weâre honest at this stage, there is much we donât yet know about that imagined world in our anticipated future. The uncertainty is high, across many dimensions. Project-based models of change are doomed to fail.
What if there was an alternative model, that could emphasize continuous learning, while delivering on those two things we mentioned earlier (local decisions on change, and local accountability for outcomes)?
This is the big idea behind the Product Operating Model (POM), which positions itself as a .durable foundation for continuous adaptation. In fact, the principle of supporting constant adaptation is so strong, that advocates apply it on a âmeta levelâ: the POM itself should be locally owned and adapted, based on tangible results from its use.
There is lots of great content out there on the principles of the Product Operating Model, so here weâll zero-in on how it could provide a useful frame for driving change to improve strategy, decision-making, or handling uncertainty in your organization.
The good news is that a lot of this is baked right into the model from the start.
Itâs worth pausing for a moment, because - if youâre like me - then youâre bringing a lot of pre-conceived ideas on what a âproductâ is, into this conversation. Product is a loaded word, but itâs used here quite generally - almost vaguely. The term is used to connote that weâre finding a âthingâ that can deliver value, to a âcustomerâ (someone who consumes that value weâre delivering), and the decision-making on that âthingâ? Well, weâre gonna decentralize that aggressively. Once we choose, define, and name the âthingâ, weâll fund it (i.e. put some people on it) for a durable amount of time, then let them figure it all out. How will we know whether the âthingâ is delivering value? Weâll measure it from the perspective of that âcustomerâ.
Weâll describe some examples of âthingsâ in a bit, but for now, just open up your concept of âproductâ beyond something on a shelf with a price tag on it.
When we look at the Product Operating Model through the lens of The Uncertainty Project, we notice that some things about POM feel different:
Strategic decisions often yield new âproductsâ
Strategic funding lands in these product teams (not in programs or projects)
Some of the strategic decision making has decentralized into these smaller products and teams (deliberately, to move faster)
Impact of strategic change is (locally) measurable, via âcustomerâ outcomes
And this is expected to be happening continuously:
Continuous learning, or discovery, via conversations with those âcustomersâ
Continuous measurement of impact of the work, of the changes made
Continuous evaluation of decisions and hypotheses, folding in recent learning
Which sounds great! But it does put a burden on the leaders of these products. They will need to grow capabilities in a lot of the things weâve talked about here at The Uncertainty Project:
Decision-making: to avoid analysis paralysis, and start âthinking in betsâ
Managing uncertainty and risk: to drive discovery and strategic choice
Creating short feedback loops: enabling experimentation on the strategic path
Hereâs one area of overlap between the POM and the ideas covered in The Uncertainty Project:
For any given âproductâ, continuous learning (or discovery) is driven simultaneously across four dimensions:
Feasibility Risk: Can we build it?
Value Risk: Does the âcustomerâ want it?
Usability Risk: Can the âcustomerâ effectively use it?
Viability Risk: Does it make sense for our âbusinessâ to build it?
There will always be open questions, or uncertainty, in each of these areas. Pursuing answers, based on relative need, is the challenge of continuous discovery. And this really is continuous! It happens - not just up front - but while chunks of the value proposition are built, delivered, and consumed.
Monitoring the learning, in terms of subjective probabilities - is something we explored previously here in an application of Bayesian networks.
The POM offers subtle ways to support a better mindset for managing uncertainty, like using the term âopportunityâ (describing problems with uncertain solutions) instead of âfeatureâ. The emphasis on feedback (and shorter feedback loops) is daring leaders to change their minds more often, as they learn.
Much of the literature on the Product Operating Model (rightly) focuses on the behaviors and operations of a single product team. But is that a transformation? Itâs a great way to explore change in a smaller setting, but what if real impact would only surface if you successfully launched 100âs of product teams? Thatâs more like the scale of what weâve traditionally called âtransformationsâ in large organizations.
âCompanies are moving beyond local, team-level agility and realizing that the entire organization needs to be wired for learning, responsiveness, and change.â
Itâs this challenge of scaling the POM that poses the hardest questions, I feel.
âWhat should the products be?â is arguably the set of the most critical decisions.
The success of the POM depends on the independence of the product teams. They each need to find a way to deliver value, without (or with minimal) dependencies on other product teams. They are each aiming for a distinct view of a âcustomerâ as well. One that they can refine and explore on their own.
But many organizations will have many âproductsâ that end up serving the same set of people, just in different ways, and possibly at different points in time. Keeping this value delivery strategically coordinated might be desired, to keep teams from delivering confusing or conflicting sets of value to the same customers.
So when a Product Operating Model âprovides a structure for continuous alignment around customer outcomesâ, this implies a need to get a deeper understanding of the âcustomerâ. When this understanding should be shared across product teams, they will collaborate in ways resembling a value stream (which coordinates activity in service of a âcustomerâ).
So this set of âproductsâ will often have to coordinate (a bit) to deliver meaningful value to a âcustomerâ. The set of products can be thought of as a portfolio. Weâre investing in these products (these durable product teams) to pursue our desired outcomes.
A lot hangs in the balance of selecting the ârightâ products to drive across the product portfolio. How is this done? How do these choices support adaptation, at the higher altitudes of the organization (e.g. job of Head of Product, or CPO)? How can they support the strategic aims, and the perceived strategic risks of the organization?
This is where thinking about the set of products as a portfolio can be useful.
Product Portfolios
To build a product portfolio, letâs start by building a meaningful description of our context, driven by current strategic dialogs.
If your strategic conversations are around the need to improve the customer experience, then build a view of the context in the form of a customer journey.
If your strategic conversations are around the need for growth, then build a view of the context highlighting adjacent market opportunities, customer segments, or emerging needs.
If your strategic conversations are around the need to compete more effectively, or improve competitive advantage in your core areas, then build a view of the context in the form of a jobs-to-be-done (JTBD) jobs map.
If your strategic conversations are around the need to expand into new global markets, then build a view of the context referencing geographies, with cultural differences and partner opportunities.
If your strategic conversations are around the need to cut costs, gain efficiency, or streamline operations, then build a view of the context that is more internal, like a view of teams using Team Topologies, or a view of supported solutions using Value Streams.
With a strategically-aligned context view, your leadership team can then discuss âwhat success look likeâ, referencing metrics (e.g. KPIs) that form a foundation for goal-setting, and for defining accountability for new (outcome-driven) product teams. Notice how different the choice of key metrics would be, for the different context views mentioned above. All should be grounded in the customer perspective, but they would emphasize different customer behaviors.
With a relevant context in place, itâs time to build out the product portfolio. We will want to optimize the portfolio to drive the biggest impact across the context, in terms of the core metrics we want to influence.
And this is another point where we can âgo metaâ with the Product Operating Model - letâs treat the Product Portfolio itself âas a productâ.
Whoa. What does that even mean?
It means that:
We can describe a âcustomerâ
the business unit or part of the organization funding the portfolio
We can drive continuous discovery and delivery
By revisiting the composition of the portfolio and making changes based on new information about the context or the effectiveness of some products
We can make decisions to optimize value delivery
By understanding business expectations of return on investments, acceptable levels of risk, and the balance between long-term and short-term strategies
We can independently deliver value
If the org design was successfully built independent business units (or functional departments), then weâll assume that their product portfolios will have minimal dependencies outside their boundaries.
We are accountable for results
By âmoving the needleâ on key metrics from the context
We have decision authority
By choosing what products are funded in the product portfolio, year over year
This, then, is what âtransformation as BAUâ (business-as-usual) looks like: a dynamic, optimized product portfolio (driven by a portfolio leadership team), that funds the high-performing product teams executing the product operating model.
The portfolio leadership team should take their initial view of their context, then write a reference narrative that communicates the strategic direction (that led them to the choice of a context view) and highlights prioritized opportunities for the portfolio to pursue (via product teams).
This âportfolio as a productâ can even create a release schedule - where strategic and tactical changes to the composition of the portfolio (i.e. adaptation) is made visible to the rest of the organization. PIvoting. Persevering. Sunsetting. Incubating. Scaling. They should see it.
Releases should signal the strategic decisions that have been made, that take the status quo (from last quarter or last year) and re-spin things based on insights gained over the interim period. These changes should be expected. Maintaining the status quo should be the exception, not the rule (though, again, check your context first).
The âreleaseâ by a portfolio can reference a set of adjustments in:
Composition (new products, retired products, combining products)
Investment levels (in products)
Product Charter refinements
Updates in the core metrics (i.e. KPIs for the portfolio)
Updates in the understanding of the context (that drives the charters)
This can be a valuable way to communicate the decisions resulting from the continuous sense-making happening at the higher altitudes of the organization.
How to Get Started
Changing to the Product Operating Model is hard. Most organizations start with a pilot. When is the right time to build a product portfolio capability in your organization?
Well, you probably already have a portfolio function or leadership team right now. Transitioning them from a portfolio of projects to a portfolio of products wonât happen overnight. In fact, itâs better to maintain both in parallel for a while, and shift the relative funding âfrom project to productâ over time.
Itâs also helpful to approach changes to the portfolio capability as a set of enabling constraints. Change the easier stuff first. Over time, the harder stuff might look a bit less difficult to change.
Pull the portfolio leadership team together and build a constraint map. Identify the most important âconstraintsâ that shape the portfolio experience. For example, think of a current process, report, or ritual that is part of your current ways of working in portfolio management. Discuss with the team how hard it might be to change it, both in terms of effort (y-axis) and duration (x-axis). Plot the constraint on the map. Try to highlight 10-12 key things that collectively shape the current experience, good or bad. [Note: you will put real names of real constraints on the map, replacing the category names shown below, which are just promptsâŠ]

Now focus on the lower left part of the map. Which item in that quadrant could be changed, such that it helps nudge towards a product-based foundation for the organization?
After each change, observe how the organization is responding to the change. Revisit the relative costs of change in your map (some constraints might have become more expensive to change, some might have become easier to change). Itâs a complex adaptive system youâre in, and now youâre driving change appropriately.
Which can make it easier to see organizational change as âbusiness-as-usualâ.

How was this week's post?We'd love to know what you think! (click one) |
Reply