Projects and initiatives are second-grade 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 mechanism, which can work when focusing on individual Product Goals but can lead to disaster 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.
- Discretionary approaches—you don't have to deal with all cross-product initiatives using the same approach. Have a set of heuristics (e.g., complexity, 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 parts (Products in this case)
- Outcome-oriented Goals, Evidence-informed - Ultimately - Don't let the fact that we are calling this a 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 inspecting working integrated increments as frequently as makes sense).
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 of the interesting questions I didn't cover today is what are the accountabilities involved in such a cross-product initiative/project (especially who should be leading). I'll talk about that some other time. In the meantime, maybe you can already see what might make sense if we look at it from the first principles of agility and leverage agility patterns.