Tackling Projects in a Product Operating Model World

Projects and initiatives are second-class citizens in a Product Operating Model world.

The organization worked hard to organize around products, creating empowered product teams, each with its product manager/owner focused on a product goal that hopefully aligns with the organization’s larger strategy.

At scale, you might have Product Groups and even Product Portfolios, each empowered to drive outcomes in their area.

This is great because it localizes dependencies and makes collaboration easier between the different people involved in the product.

But what do we do when a “strategic cross-product project” shows up in our funnel, or more importantly, when we decide to explore/deliver it?

One of the behaviors I’ve seen repeatedly in organizations following a Product Operating Model is that while each Product operates in an iterative agile fashion, the integration across them looks more akin to the traditional big batch waterfall.

I’ve seen people interpret the Product Operating Model as a divide-and-conquer model. That can work when focusing on individual Product Goals, but it can lead to trouble when tackling integrative work.

There are several approaches to tackling these cross-product initiatives/projects in a Product Operating Model world, which I will explore in a future article.

For now, my suggestion to you is to make sure that you’re applying the first principles of agility to these cross-product initiatives/projects/programs as well:

• Avoid prioritization hell—Use a mix of strategic goals that cut across the portfolio of products, as well as a clear portfolio backlog and ownership, to provide clear guidance to the different products regarding the balance/priority of cross-product initiatives related to the individual products.

• Avoid integration hell - Maintain transparency based on integrated working products/solutions on an ongoing basis - which will mean slicing the cross-product initiative into small cross-product slices.

• Avoid getting surprised - Frequently Inspect and adapt based on transparency and feedback.

• Organize around value - Think of ways to facilitate effective collaboration among the people involved in the work. Remember that stable Product Teams are an optimization designed for a certain context—there are situations where it might not be optimal.

• Use discretionary approaches - You don’t have to deal with all cross-product initiatives using the same approach. Have a set of heuristics, such as complexity and coupling, for when to use more collaborative patterns.

• Inspect and adapt the model itself - If it’s not helping you drive strategic work, it’s time to tweak it. The model should be working for you, not you for it. Having said that, optimize for the whole, not for individual products.

• Use outcome-oriented goals and evidence-informed steering - Don’t let the word project or initiative take away from the value of treating it like a product, with an outcome-oriented goal and continuous adjustment based on evidence from working integrated increments.

The bottom line is to keep your thinking hat on! Reflect on why you’re using a Product Operating Model and its underlying principles, and apply principles and patterns in context rather than copying practices.

One interesting question I did not cover today is what accountabilities are involved in this kind of cross-product initiative, especially who should lead it. I will talk about that another time. For now, start from the first principles of agility and use the product operating model as a tool, not a constraint.

Watch the short video version.

Designing and evolving a product operating model is one of the highest-leverage things a product leader can do. Explore Product Operating Model advisory or let’s talk.