🔮 Transformation as BAU

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.

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”.