What is next for agile in 2025 and beyond? We have all heard the excitement around AI and the increasing adoption of OKRs, but one thing that is starting to come up in conversations with our customers is the Product Operating Model.
What is the Product Operating Model?
The Product Operating Model is a conceptual framework that came to prominence in the 2024 book Transformed by Marty Cagan. The approach is aimed at “companies who believe that they should be powering their business with technology” and enabled by empowered Product Teams that are accountable for delivering results.
The Product Operating Model enables companies to:
- Change how they build products – moving from delivering against a list of features or requirements, to innovating and experimenting against a set of customer/user problems.
- Change how they solve problems – moving from directed teams focused on task completion, delivering minimal value slowly and infrequently in long cycles with limited learning opportunities, to empowered teams focused on outcomes, delivering value early and often in short timeboxes with frequent integration and learning cycles.
- Change how they decide which problems to solve – moving from opinions-based priorities instead of data (e.g HiPPO), to priorities based on the Product Vision and product-driven insights.
In essence, the Product Operating Model is a framework that helps organizations build better products faster by focusing on customer needs, empowering teams, and adopting agile practices.
There is no way that a single blog post can do full justice to the whole model or explain every facet in detail (and we’ve deliberately left some out of this post), so if you’re desperate to know more, we highly recommend taking a deep dive into the book yourself – we’d love to hear your thoughts and discuss with you.
Product Operating Model Concepts and Principles
To be successful with the Product Operating Model, companies must master the 5 Product Model Concepts of; Product Teams, Product Strategy, Product Discovery and Product Delivery, underpinned by a strong Product Culture. Each concept is based on a set of product model first principles:
Product Teams
- Empowered with problems to solve
- Outcomes over output
- Sense of ownership
- Collaboration
Product Strategy
- Focus
- Powered by insights
- Transparency
- Placing bets
Product Discovery
- Minimize waste
- Assess product risks
- Embrace rapid experimentation
- Test ideas responsibly
Product Delivery
- Small, frequent, uncoupled releases
- Instrumentation
- Monitoring
- Deployment infrastructure
Product Culture
- Principles over process
- Trust over control
- Innovation over predictability
- Learning over failure
Applying the Product Operating Model to Your Context
If you are intrigued by some of the concepts and principles mentioned, but unsure how you can incrementally weave some of these into how you deliver, here are some practical tips to consider:
Moving From Feature-Based Roadmaps, To Outcome-Based Roadmaps
A roadmap is an essential artefact for any product role, team, department or organisation. Without a roadmap in place, where are you heading? Ordinarily, product roadmaps will show the intended delivery of outputs; Features/Epics/Requirements, over a defined period. This is an excellent way of showing how busy you plan to be in the coming year, but what it fails to articulate is the value that you intend to deliver.
If you use Objectives and Key Results, consider replacing the outputs on your roadmaps with what you intend to achieve in the form of your Key Results. By communicating the Key Results, you are not restricting yourself and your team to deliver a set of Features that, in some cases, were defined months ago and often by someone else – you are igniting innovation and allowing the team to be adaptive and agile.
Agility and adaptability are the secrets to sustainable success according Carol McEwan >>
Making Your Features the Problem
This isn’t suggesting that your features are a problem, this is suggesting that your features should be the problem. Many features are written with a benefit hypothesis, “If we implement this feature, then we will receive this benefit”, coupled with some acceptance criteria and a set of associated user stories.
The good news is that you can keep having features but adapt how you define them. Instead of focusing on the solution, focus on defining the problem that the feature is solving.
There are many useful templates for crafting problem statements from the 5 Ws (Who? What? When? Where? Why?) to the one excellently described in the book Lean UX:
“Our [service/product] is intended to achieve [these goals]…
We have observed that the [product/service] isn’t meeting [these goals] which is causing [this adverse effect] to our business.
How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?”
Once you’re clear on the problem, you need to empower the team to run experiments to see how they could solve them.
Running Product Delivery Using Scrum, Kanban, SAFe, Or Any Other Agile Framework
Once your features are defined as problems, you can use your existing agile ways of working to support the delivery. If you’re using Scrum, consider challenging the team to come up with 2 prototypes by the end of the sprint to test against the problem. If you’re using Kanban, create classes of service for the problems that you’re solving and set work-in-process (WIP) limits to the number of prototype ideas being worked on. Both approaches can help you instil some of the concepts and practices of the Product Delivery principle.
Despite the book stating that “the most egregious example of what is known as fake agile is SAFe”, we believe that companies who are benefitting from a well-coached, high performing SAFe transformation (believe it or not, there are some out there if you look!), can also implement some Product Operating Model concepts to their benefit.
First and foremost, any successful SAFe implementation is rooted in Lean-Agile principles (Product Culture – Principles over Process) and not in blindly following the process, tracking only feature delivery, predictability and “carryover”.
But where we see having the most potential to see elements of the Product Operating Model come alive is through the experience of PI Planning. Every PI Planning event that we coach at is unique, evolving as our clients learn and adapt. We see the Product Operating Model concepts such as collaboration, transparency, outcomes over outputs, sense of ownership, placing bets and powered by insights all come to the fore.
Our recommendation would be to be brave with your PI Planning agendas and open to the idea of experimenting with how your teams are planning. Other recommendations are to;
- Use Lean UX tools such as story mapping to visualise the PI
- Invite real users and customers to provide input into planning
- Prioritise and encourage learning over failure at every opportunity.
Learn how we streamlined PI Planning for our client in FMCG manufacturing >>
Getting Started with the Product Operating Model
Any organisation looking to get started with the Product Operating Model should be aware that realising the full benefits of such a transformative approach will require a full cultural reset. If you believe that you’re ready for this, here are the steps for you to consider as you plan your journey.
1. Identify a Pilot
As the book suggests, start small and grow incrementally. Even if that means just implementing some of the principles and concepts to plant the seeds of transformation, then that is progress.
2. Transformation Assessment
Once you feel that you’re ready to take a bigger step, assess the area that you’d like to transform to a) see if the area has the foundations to be successful and b) benchmark where it is today to show real, tangible results. Consider assessing vision and strategy, team autonomy and empowerment, current roles and competencies, outcomes over outputs, customer centricity, product delivery, customer and stakeholder engagement, metrics and monitoring, and culture.
3. Change Management Plan
To increase the chances of success, ensure that you have a thoughtful change management plan that covers training, coaching and support, implementation strategies and resistance management. Don’t forget the human side of change too, understanding the “what’s in it for me?” from a team member perspective too.
4. Coaching Support
A great way to speed up adoption is to seek guidance from people who’ve been through product transformations before. Whether you need a Product Coach, Delivery Coach, Product Leadership Coach or a Transformation Coach, McKenna Agile Consultants can help you empower your people and teams.
Get in touch with our expert team to explore the support we can offer.
This blog includes a high-level overview and practical application of concepts from the Product Operating Model described in the book Transformed (Cagan, M. (2024). Transformed: Moving to the product operating model. John Wiley & Sons, Inc. https://www.svpg.com/books/transformed-moving-to-the-product-operating-model/)
