Product Operating Model Masterclass
In previous articles, I have shared my team’s journey towards the Product Operating Model, as defined by the Silicon Valley Product Group (SVPG).
- Product Operating Model
- Product Operating Model Principles
- Product Operating Model Roles
- Product Operating Model Transiiton
- Practical Product Operating Model
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, which act as a great reference. Specifically, INSPIRED, EMPOWERED, and TRANSFORMED.
Over the past couple of weeks, Christian Idiodi has been running a masterclass with my team across the US, UK and India. This includes an intense three-day workshop (UK photo below) where every member of the team was immersed in the product-first principles.
Outlined below are a few of my favourite statements that highlight key aspects of the product operating model.
-
The Product Operating Model is a conceptual model, not a methodology, process or framework. Therefore, it must be adapted to suit the specific business context.
-
The product-first principles are highly applicable to a wide range of businesses, teams and circumstances. They provide a consistent foundation to establish trust through common beliefs and behaviours.
-
At its core, the Product Operating Model helps businesses identify and solve their biggest problems through discovery and delivery.
-
Discovery and delivery are team activities that require input from cross-functional experts, including Product Management, Product Design, and Technologists (Engineers).
-
Focus is critical, it is not about what you choose to do. It is about what you choose not to do. Product Leaders must be willing to say “no” frequently, even if the ideas are compelling. To avoid demotivation, ideas should not be forgotten and can be reassessed at the appropriate time.
-
Teams must learn to love the problem. They must become experts in the problem, with deep research to ensure context and credibility.
-
Teams must be empowered and provided the environment to operate with autonomy. Empowerment is about providing a team with the opportunity to discover “how” a problem should be solved. Autonomy aims to minimise the constraints/dependencies that incur friction.
-
Product Leaders must provide a product vision (a compelling narrative for the future), alongside the strategic priorities that support a common outcome. They must ensure appropriate context is shared and understood by all teams.
-
Product Managers must prioritise discovery over delivery. If they are overly involved in delivery, it is a signal that the right team members were not proactively engaged as part of discovery.
-
Engineers prioritise delivery over discovery but need to be proactively engaged in the discovery process to support ideation and rapid experimentation.
-
Discovery must include rapid iteration, exploring the problem from multiple perspectives. It should include low-cost, low-tech experimentation, delivered with the least amount of effort to help confirm assumptions and verify hypotheses.
-
Teams should gain insights from multiple data sources. Accepting just one data source opens the risk of unconscious bias.
-
Businesses can be opportunity-led or crisis-led, the goal is to become opportunity-led.
As Chief Technology Officer (CTO) and Chief Information Security Officer (CISO), I have a bias towards engineering. When I think about engineers who embody the product-first principles, I think of John Carmack.
John Carmack is a legendary engineer, with a resume that rivals the very best. He is also curious, humble, and relentlessly passionate about solving big problems. He also perfectly demonstrates principles of product discovery, demonstrating mastery of the topic and working through rapid, low-tech prototypes.
These behaviours are evident throughout his career, most notably his time at Oculus, where he would frequently run experiments using any available parts (low-tech, low-effort).
I look to these examples for inspiration, hopefully helping me to become a more effective leader.