Product Operating Model Transition
In my previous three articles, I outlined the Product Operating Model, as defined by the Silicon Valley Product Group (SVPG).
As a reminder, the Product Operating Model is a conceptual model, not a methodology, process or framework. It is about moving from output to achieving outcomes, following a set of product-first principles. These principles focus on ensuring any product is valuable, viable, usable, and feasible.
The Silicon Valley Product Group (SVPG) has published three books on the Product Operating Model. Specificlly, INSPIRED, EMPOWERED, and TRANSFORMED.
These books are an incredible resource. However, the case studies referenced focus on digital-first / technology-first companies, specifically Netflix, Spotify, etc. These are certainly fascinating examples but do not represent the majority of businesses.
For example, Spotify is a 19-year-old company born in the Internet era. It predominantly produces digital (software) products and has minimal regulatory oversight.
I have spent my career working at two life science companies, one that is 150 years old and another that is 70 years old. These companies have a complex value chain, predominately producing drug products (not digital products), and operating within a highly regulated industry with strict compliance controls.
In addition, the years of heritage and legacy create inertia, incurring human and technical debt that can act as a barrier to change.
Therefore, the comparisons with Netflix and/or Spotify lack credibility.
With this in mind, it would be easy to dismiss the Product Operating Model as not relevant for any business that is not “digital native”. However, in my opinion, the product-first principles are highly applicable, helping any business (regardless of industry) to focus on what matters most, the outcome and customer value.
In 2020, we started our journey towards the Product Operating Model. Therefore, I thought I would share more detail regarding our transition approach.
Product Operating Model Transition
In a perfect world, any transition to a Product Operating Model would be sponsored by the CEO and include active engagement from the Executive Committee.
Unfortunately, convincing a CEO to transition the business operating model is no easy feat, usually requiring an intervention that forces the change. For example, a change in leadership or a market disruption.
As a result, our approach was to initiate the change from IT. There is logic starting with IT, acknowledging that almost every industry and business is increasingly reliant on technology and data to differentiate and drive value.
It should be noted, that this approach is most viable when IT is already established as a trusted partner with a focus on value generation. In some businesses, IT is exclusively positioned as a support function, which would likely act as a barrier when attempting to transition to the Product Operating Model.
A core aspect of the Product Operating Model is the product-first principles. These twenty principles place an emphasis on value, viability, usability, and feasibility, which are highly relevant to ensure a successful outcome.
The Product Operating Model and the product-first principles are best positioned when there is a “greenfield” problem to be solved. This means there is no predetermined solution defined and the outcome is within the control of the product team (minimal restrictive dependencies). For example, within my industry, a big “problem” is how to accelerate the drug discovery process.
In this scenario, a Product Team, consisting of a Product Manager, Product Designer and Technical Lead (backed by engineers) are empowered to solve the problem, starting with Product Discovery, before transitioning to Product Delivery. This team is durable and therefore persists through the duration of the product lifecycle.
This scenario follows the exact approach as defined by the Product Operating Model. I have also written about the specific roles/responsibilities in the article “Product Operating Model Roles”.
The challenge is that not every problem is “greenfield”. For example, some problems have predetermined solutions (maybe due to existing investments) or the product team do not have complete control to shape/influence the outcome (maybe due to a regulatory constraint).
In addition, recognising the wider role of IT, there are many scenarios where the problem has already been solved and therefore, there is no value in discovering a new solution. For example, commodity capabilities (e.g., Hosting, Telephony) and/or highly industrialised processes (e.g., Human Resource Planning).
These scenarios are classified as “enablement”, where a product team is still assigned, however, the primary mission of the team is to deliver a solution that is scalable, secure, reliable and efficient. As a result, the Product Designer, Technical Lead and Engineers are dynamically assigned (not durable), based on corporate priorities and/or capacity. This helps to manage total headcount and capacity planning.
The Silicon Valley Product Group (SVPG) refer to this type of team as “maintenance”. However, in my opinion, the word “maintenance” undervalues the teams, as their contributions are critical, commonly providing the foundation for other product teams to build upon. Hence, I prefer the word “enablement”, which more accurately describes the value proposition.
Regardless of the team outcome, they all follow the product-first principles, promoting consistent solutions. This approach recognises that every team has a problem to solve, customers to understand/delight, and risks and constraints to manage.
The key is to avoid bifurcation (bi-modal) operation, which can unintentionally relegate the value of certain teams, whilst also creating confusion and friction.
With this context, IT is organised into product teams, logically grouped under Product Leaders (that focus on people enablement and provide strategic context). Many of these product teams are durable (persistent) and focused on the “big problems”, aligned with the business strategy. The product team topology will be different for every business and it is not fixed, dynamically evolving based on the business priorities.
It is my belief that this model, adapted from the Product Operating Model, following the product-first principles, provides a versatile foundation that promotes continuous innovation and delivery excellence, helping to ensure that every solution achieves the desired outcome.