The Product Operating Model, by the Silicon Valley Product Group, 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.

I have previously written about the Product Operating Model across five articles, including some details regarding my business transition.

In this article, I will share how my business has embedded the Product Operating Model.

All work, across all business functions, including foundational systems and platforms, are delivered and supported by a Product Team. 

Product Teams are ephemeral scaling up or down based on the business need. All Product Teams are logically grouped under a specific Product Group.

The diagram is an example of our Product Group/Team topology, with the blue boxes highlighting Product Groups and the white boxes highlighting Product Teams.

Practical Product Operating Model

The Product Group/Team topology will be different for every business, aligned to the value chain.

Every Product Team has a defined scope and focused problem statement (mission) that is measurable.

The primary goal of a Product Team is to discover and deliver a solution to the problem statement.

By default, a Product Team include a dedicated Product Manager, Product Designer and the associated technical resources. The technical resources are primarily allocated from the Engineering team.

The Product Team will have direct access to the relevant stakeholders, which could include Business Partners, Users, Customers, IT Leaders, etc.

A Product Team operates following the principles of DevSecOps. As a result, any solution discovered and/or delivered is supported by the Product Team.

The flow of work is standardised across all Product Teams, as outlined in the diagram below.

Practical Product Operating Model

To enable practical scale, Engineering will operate as a unified pool of technical resources, including internal employees and external contractors.

Specific technical expertise and experience will be required to support the depth and breadth of the Product Teams. This includes the following disciplines.

  • Software Engineering
  • Data Engineering
  • Platform Engineering
  • Site Reliability Engineering
  • System Administration
  • Technical Analysts

Regardless of the discipline, all technical resources reporting to the Engineering team are titled “Engineer”, with different levels (e.g., Associate, Senior, Principal) differentiating seniority.

As highlighted in the diagram below, engineers will be allocated to a Product Team based on the needs of the Product Team, as defined by the Product Manager. 

Practical Product Operating Model

Engineers can be durable (persistent), living with the Product Team for the duration of the Product Team lifecycle or dynamically assigned (short-lived) based on a specific time-bound need, providing a “boost” to the team.

Internal employees and external contractors will be treated equally, following the same allocation process, with the same expectations.

External partners are leveraged as part of the Engineering team to support scale and to provide access to the required expertise and experience.

A default external partner (managed service) provides economies of scale and consistency, with boutique partners providing access to specialist expertise and/or experience.

Practical Product Operating Model

A primary goal of the Engineering team is to discover and deliver feasible solutions, ensuring they meet expectations across the following areas.

  • Architecture Alignment (Avoiding Technical Debt)
  • Operational Readiness
  • Availability
  • Integrity
  • Performance
  • Scale
  • Efficiency
  • Security, Quality Assurance, Legal and Privacy
  • Regulatory Compliance

By default, a Product Team must follow the principles of DevSecOps.

With that said, every system that enters production is classified (Platinum, Gold, Silver, Bronze). Specific systems (e.g., Platinum) may require dedicated support teams and processes to ensure the resolution of issues and incidents are appropriately prioritised.

As previously stated, the Product Operating Model is a conceptual model, not a methodology, process or framework. Therefore, every business looking to embrace the product-first principles will need to carefully consider how they embed the concepts.

Our approach aims to ensure standardisation, focus and discipline, which unlocks speed and quality at scale. It also ensures every team has a clear understanding of the problem they are trying to solve and how that is connected to the overall business outcomes.

This connection between the work of an individual within a Product Team and business outcome drives purpose, which is motivating and promotes clear prioritisation.

strategy product_operating_model silicon_valley_product_group svpg marty_cagan inspired empowered transformed linear lifeinwork