Build your House upon the Rock

Product Strategy as a Foundation for the Product Operating Model

In recent years, Product Operating Model (POM) transformations have become increasingly popular. Popularised by Marty Cagan’s book “Transformed”, they haven’t just stayed in Silicon Valley. We’ve seen organisations adopt them in the UK and achieve excellent results, e.g. Trainline’s recent success.

I've witnessed a few iterations of POM implementation, most recently at a large media organisation. In this article, I'm going to argue that product strategy is the most critical component for the successful rollout of a POM.

Let’s zoom out for a second, what even is a POM? We define it as: “a framework for maximising the impact of product teams through the consistent and scalable alignment of strategy, people and processes.”

No two models look the same, but in their broadest sense they break down into 3 major pillars. The What – defining your strategy, The Who – utilising your people, and The How – getting the work done. They tend to orientate towards empowered product teams led by Product Trios (Product, Design and Engineering).

Build your house on the sand: focus on velocity

The POM is a product like anything else (a chef is a product manager of food, right?). This means you can run a timeboxed discovery on the as-is state, design an MVP, and start to build a better model. While you’re building, you can simultaneously learn from what you implement and practice continuous discovery against the remaining components in the model.

The temptation to build something fast leads to an early focus on “The How”. It’s much easier to change up agile cadences than it is to question the direction of the organisation. And yes, improved velocity may be one success measure in a good POM, but this approach fails for a few reasons.

First, it doesn’t matter if you’re going faster if you’re going in the wrong direction. We shouldn’t celebrate driving into a wall at 80mph instead of 60mph.

Second, without a clear view of where you are going, improving “The How”, takes much more effort than it otherwise would. You end up fighting against org structure, team topology, and reporting processes, that aren’t aligned with the strategy of the organisation. You build workarounds to account for these things (e.g. mountains of dependencies, or unclear leading and lagging product metrics) that are time consuming, and you’ll likely have to remove later.

Third, if you do manage to improve “The How,” chances are you will have to tear stuff up and start again. This is fine when you’re experimenting with a new feature, but this is large scale organisational change! It comes with politics and only a certain amount of social capital to spend. Change fatigue is very real and you need to be cautious about instilling new anti-patterns that people will need to unlearn.

Build your house on the rock: focus on strategy

There is no perfect product strategy. But, a pretty good one aligns to the organisation's vision and direction, focuses on the problems it is worth solving, and the problems it is not worth solving. They are long lived, with clear measures of success. Sure, you should review them semi-regularly, but they shouldn’t be something that changes every 6 months.

Problems that appear to be operational (slow velocity, low release cadence, lack of collaboration, drowning in dependencies, low ownership), are often reflections of a poor strategy, or a poor communication of product strategy.

This makes product strategy one of the most important levers in your tool kit. Even without making other interventions, a clarified and opinionated product strategy can frame the key conversations that need to happen between teams, facilitate trade-offs, and clarify what is important to get in the hands of users.

A well-articulated, focused product strategy is also the foundation for other key components of your POM. You cannot effectively empower teams until you give guidance on the problems they are being empowered to solve. You cannot measure success and have data-driven decision making until you know what’s important to measure. You cannot structure your team topology and minimise dependencies until you understand your core customer and value proposition.

Also, getting your product strategy in place is politically useful. Crafting a good strategy requires Product, Design and Engineering leaders to come together, collaborate, and agree on their purpose. Misalignment is more effectively solved when you have a shared vision and a shared language.

The Balance

This is not to say that fixing your product strategy is the only thing you need to fix your POM. Or, that you must get a good product strategy in place before you can begin. But I recommend reviewing it or starting it early in the transformation process with your strongest Product, Design and Engineering leaders. Other low hanging fruit can be delivered in parallel e.g. clarifying your language, defining or refining your Product Development Lifecycle, and identifying skills and capability gaps. Use these things to prove the value of change while you build a solid foundation for more substantial improvements alongside your product strategy.