Have you ever wondered why companies like Netflix, Amazon, and Apple consistently deliver breakthrough products while others struggle to keep up?
Marty Cagan, partner at Silicon Valley Product Group (SVPG) and author of Transformed, believes the driving forces behind their success aren’t big budgets or trendy frameworks but the principles they embrace. He encapsulates these principles in what he calls the product operating model.
At this year’s Product Drive summit, hosted by Userpilot, Marty broke down the product operating model in detail, explained its core components, cleared up common misconceptions, and showed how companies could apply it in real life.
You can watch it right away here:
Or if you prefer reading, here comes the key takeaway!
What is the product operating model?
The product operating model is a set of timeless principles that top-performing companies follow when creating products.
As Marty Cagan notes, these principles are consistent across industries, company sizes, and product types:
“There are 20 product model principles that we’ve identified. It’s interesting because they’re the same principles we see whether it’s a device company, an enterprise SaaS company, a consumer internet services company, or a startup,” says Marty.
It’s important to note though, that this model is conceptual, meaning it doesn’t dictate specific methodologies (e.g., Scrum, Kanban) but provides the flexibility to choose the right approach for the problem at hand.
The only non-negotiable principle is to focus on delivering meaningful outcomes rather than producing outputs.
What the product model isn’t?
This concept has become a bit of an industry buzzword and as a result, people have been coming up with their own interpretations, sometimes shifting away from its original meaning.
So let’s get this straight and clarify what this model isn’t:
- It’s not a product management model. While the model includes some frameworks for PMs, it’s not exclusive to product management. The model encompasses the entire product ecosystem, including engineering, design, leadership, and stakeholders.
- It’s not the same as product operations. The abbreviation of the word ‘product operations’ is ‘product ops’, which people often confuse with the product operating model. It’s a support role focusing on research, data analytics, and enabling cross-functional teams, which can exist even in organizations that aren’t aligned with the product model.
- It’s not product-led growth. PLG is a go-to-market strategy where the product itself drives acquisition, retention, and expansion. To put it simply, the product model focuses on how products are developed and delivered, whereas PLG dictates how they grow in the market.
- It’s not about having a product team. Many companies have product managers, product owners, and product leaders. These roles don’t automatically imply that you’re following the product model. In the product model, these roles are more related to skills rather than titles.
What does it really mean to transform?
Now, we’ve talked about some high-level concepts, but how does transformation happen in practice?
To help you get started, let’s look at what is actually changing:
- How you decide which problem to solve.
- How you solve problems.
- How you build and deploy the product.
1. Changing how you decide which problems to solve
According to Marty Cagan, most traditional companies today rely on annual or quarterly planning processes, where executive leadership allocates engineering resources across business units based on high-level priorities (which are often driven by immediate competitive pressures or operational needs).
While this system isn’t inherently flawed, it’s not innovative.
In a product-led model, the focus moves toward solving problems with the highest strategic impact. Product leaders take responsibility for identifying these problems by collaborating with stakeholders across the organization.
Instead of merely delivering features, the conversation shifts to outcomes: what problem are we solving, and how will we measure success?
However, we will admit that this approach isn’t always easy to implement as it disrupts the power dynamic within the company, and not all stakeholders can accept that.
2. Changing how you solve problems
Most teams are stuck building features that are handed to them.
Shifting to an empowered team model means you stop taking orders and start finding solutions.
Let us illustrate this differentiation with an example. Imagine you need to set your product apart from competitors to maintain your pricing.
In this example, the product leader asks the team to build an analytics dashboard for the tool. The product manager then adds this task to the roadmap, oversees the collaboration between designers and developers, and aligns expectations with stakeholders to reach the desired output.
Empowered teams, on the other hand, follow a different approach. In this case, the product leader presents the team with the problem, not the solution. They say: “We need to differentiate our product from others to maintain pricing.”
Product managers take the lead and become the face of the business in empowered teams. Instead of being merely project managers, they become creators in charge of building a product from the ground up—one that’s viable, feasible, usable, and valuable.
3. Changing how you build and deploy the product
Even after years of Agile, many companies are still tied to quarterly—or worse—big-bang releases. The spread of “fake Agile” allows them to assume they’re improving, while in reality, their development practices remain stagnant.
If you’re going to adopt a product operating model, you need to have CI/CD pipelines in place to make fast releases—ideally a couple of times every 2 weeks. This allows you to:
- Address customer needs promptly.
- Catch technical problems before users do.
- Ensure that the new releases add value for the customer and business alike.
Companies with legacy or tightly coupled systems will likely need to refactor their code before adopting this model.
The 5 Product concepts of the product operating model
We’ve already briefly touched upon some of the building blocks of the product model, but in this section, we’ll do it in a more structured way to ensure we don’t overlook anything and give you all the nitty-gritty details.
Product culture
The product culture is the way your employees approach product development. As mentioned throughout this article, the biggest shift when moving to the product operating model is about changing output for outcome.
But this change isn’t as easy as it sounds. Stakeholders need to be okay with delegating the lead regarding product features. Also, your product teams need to have the right competencies to adapt to this new approach and responsibilities.
Product strategy
According to the product operating model, the product strategy needs to be holistic and contextual. Marty Cagan refers to it as a strategic context.
This means that the strategy needs to take into account the team’s competencies, product vision, and business objectives to be realistic.
It also should allow each team to use the strategy to define individual objectives that feed into those bigger company goals.
Product teams
In the product operating model, product teams need to be fully cross-functional and accountable for results. This empowers them to take higher ownership and make decisions that benefit the business and the customers without waiting for stakeholders to okay them.
This can only happen if cross-functional teams have clear objectives and resources to conduct solution discovery and gather customer insights.
Product discovery
In the product model, product discovery is more about solution discovery. The idea behind this is that product teams are always in close contact with customers. Therefore, they already know what the problems are, but they need to research to determine how to solve them.
Through product discovery, developers can tell if a solution is feasible, designers say if it’s usable, and product managers (not stakeholders) determine if it’s viable and valuable.
Product delivery
The product model companies follow processes to quickly build robust, high-performing, uncoupled, and scalable solutions that solve users’ problems AND add value to the business.
These are usually truly agile businesses.
Essential product operating model competencies
Companies that follow a product model see roles as a mix of competencies. Feature teams work to solve business problems. However, empowered teams “exist to solve hard problems for your customers and for your business, in ways your customers love, yet work for your business,” writes Marty Cagan.
Here are the skills your team should adopt to take on these roles:
- Product managers: This person understands business and user needs and is responsible for guiding cross-functional teams to develop outcomes that add value and are viable.
- Product designers: This professional needs to have the skills to work in cross-functional product teams, design user-friendly solutions, and experiment to iterate on the solution. They’re responsible for making the product usable and the overall product experience.
- Tech leads: This person should be the most experienced engineer or developer in the team. They need to know how to work in teams, test and iterate solutions, and be accountable for the feasibility of the delivery.
- Product leaders: These are all team leaders and group managers of designers, engineers, and product managers. They need to have the right skills to hire a team, create a product vision, and design a product strategy that helps reach business goals. They should also become servant leaders and coach teams to reach goals.
Conclusion
Transformation starts with rethinking how your business identifies and solves problems. Instead of building the features that were handed to them, teams following the product model engage in continuous discovery to identify the best outcome both for the business and users.
If you’d like to learn how Userpilot can help your product teams gather customer data and conduct experiments, book the demo!