Marty Cagan on the Product Operating Model and Scrum’s Future
In this interview with Marty Cagan, author of the book "Transformed," explore insights on revolutionizing product management and embracing empowered teams.
Join the DZone community and get the full member experience.
Join For FreeTL; DR: The Product Operating Model: An Interview with Marty Cagan
Let’s explore Marty Cagan’s insights on revolutionizing product management, embracing empowered teams, and fostering innovation by employing the Product Operation Model described in his latest book “Transformed.” We will uncover how to effectively navigate the transformational path to a product-centric approach and how Marty sees Scrum in this context.
The Product Operating Model Interview Question Set 1: The Model in General
Marty Cagan’s “Transformed” underscores the critical yet feasible shift towards a product operating model, stressing the first steps for transformation, the pivotal role of trust, and the focus on outcomes. He combats skepticism with industry examples and discusses the product operating model’s adaptability and scalability. Marty Cagan also touches on the evolving role of product managers, balancing speed with quality and continuous customer engagement. This first set of questions addresses the Product Operating Model itself:
1. Understanding Transformation
Marty, in “Transformed,” you argue that transitioning to the product operating model is necessary and possible for traditional companies. Please elaborate on the first steps a company should take to initiate this transformation.
Marty Cagan: We recommend starting with an organizational assessment. We provide the one we use in Chapter 29.
2. Case Studies of Success
The book features detailed case studies of successful transformations. Can you share an example not included in the book that exemplifies a company overcoming significant hurdles during its transformation?
Marty Cagan: That was the purpose of writing the book. Each exemplifies a company overcoming significant hurdles. Each case study represents a significant body of work.
3. Empowering Product Teams
You emphasize the importance of empowering product teams. From your experience, what are the most common organizational barriers to empowerment, and how can they be dismantled?
Marty Cagan: The largest barrier is trust. It requires real trust for executives and stakeholders to empower others to take responsibility for solving critical problems, which is why transformation is about progressively earning that trust.
4. Leadership’s Role in Transformation
How should CEOs and senior leaders alter their mindset and operations to facilitate a successful transition to the product model?
Marty Cagan: Mainly, the senior leaders need to understand the product model and what it means. Then, they need to be willing to give product teams the chance to demonstrate they are worthy of that trust.
5. Innovation Post-Transformation
Once a company has successfully transformed, what practices ensure it continues to innovate and doesn’t fall back into old patterns?
Marty Cagan: Once the dialog has truly moved to outcomes, and once teams have demonstrated they know how to achieve outcomes, then it’s painful for a company to revert to just output. So, the key is to keep the focus on consistent outcomes.
6. Metrics for Transformation Success
What metrics or indicators do you recommend companies track to gauge the effectiveness of their transformation into a product-led organization?
Marty Cagan: While there are many indicators of progress, since the point of transformation is to deliver outcomes, until and unless the product teams start delivering outcomes, none of the other indicators are much more than measures of activity (aka vanity metrics). So again, the key is to consistently deliver outcomes. We recommend starting with specific pilot teams and then expanding from there.
7. Addressing Skepticism
How do you address skepticism within a company, particularly from those who believe the product operating model won’t work in their specific industry or market?
Marty Cagan: First, we should all acknowledge that skepticism is normal and justified, especially in organizations where so many promises have been made that fail to deliver results. Second, that’s why the examples in the book span so many different industries and regions in the world, from regulated financial services to regulated health care to regulated rail travel. But it’s important to point out that if someone wants to find a reason not to try to transform, it is not difficult to pick something and say, “This is why we can’t do that.” But this book is full of examples where companies ignored those people.
8. Product Strategy and Vision
How do you recommend companies develop a product strategy and vision that align with the product operating model while also being adaptable to market changes?
Marty Cagan: If they read the book EMPOWERED, they will learn how strong product visions and product strategies are created, and they will see that while the product vision is intended to span several years, the product strategy is updated quarterly in order to adapt to market changes (and ongoing learnings from the product teams).
9. Scaling Agile and Product Practices
What are the key considerations when scaling Agile and Product practices across multiple teams and geographies for larger organizations?
Marty Cagan: The product model is used by some of the largest tech-powered product organizations in the world, several factors larger than most. So, there should be no question as to whether the model scales. In fact, the model is all about consistent innovation and outcomes at scale.
10. The Future of Product Management
With rapid technological advancements, how do you see the role of the Product Manager evolving in the next decade?
Marty Cagan: This is a large topic. Please see "Preparing For The Future."
11. Balancing Speed and Quality
How can companies balance the need for speed in product development with maintaining high-quality standards?
Marty Cagan: The key is to realize that velocity and quality are not at odds, so long as the team uses the principles of the product model – in particular, small, frequent, uncoupled releases—aka continuous delivery. See the book Accelerate for the theoretical underpinnings of how the best organizations both move much faster and maintain higher product quality.
12. Customer-Centricity in Transformation
Could you discuss how companies can maintain a focus on customer-centricity during and after their transformation?
Marty Cagan: If the company follows the principles in the product model, this means they will be engaging with users and customers on an intense and continuous basis. This is, in fact, one of the major reasons to transform. The customer interaction is critical to the innovation process.
13. Learning From Failure
Can you share a personal or observed example where a transformation attempt failed, and what lessons were learned from that experience?
Marty Cagan: See "Transformation Fail."
14. Integrating New Technologies
How should companies integrate new technologies, such as AI and machine learning, into their product development processes as part of their transformation?
Marty Cagan: One of the defining characteristics of companies using the product model is the level of engagement of their engineers, especially as the source of new, enabling technology. Today, you can see the product model companies leading in applying AI and ML.
15. Maintaining Agility in a Changing Market
How can companies ensure their newly adopted product model remains flexible and responsive to unforeseen challenges?
Marty Cagan: This is a key reason why the product model is a set of principles rather than a process, framework, or methodology.
The Product Operating Model Interview Question Set 2: The Model and Scrum
The second set of questions explores the nuances of the Product Operating Model and Scrum. We dive into questions on empowered teams, role dynamics, and scaling in agile environments. Marty Cagan critiques traditional Scrum setups and highlights the distinction and depth of roles within empowered product teams, challenging conventional Scrum practices and advocating for innovation over predictability:
16. Empowered Product Teams vs. Scrum Teams
Marty, in your framework, you advocate for empowered product teams with the autonomy to solve problems creatively. Can you elaborate on how this concept differs from or aligns with the Scrum framework’s idea of self-managing teams? Are there aspects of Scrum teams that you think are underutilized in fostering empowerment?
Marty Cagan: Most “scrum teams” are just sets of developers with a backlog administrator product owner, also known as a “delivery team.” An empowered product team is a fully cross-functional set of professionals – developers, designer, and product manager; see "Product vs Feature Teams." More generally, Scrum is a particular delivery process. A product team is designed for both discovery and delivery, and the engineers can use whatever delivery process they consider most appropriate for the delivery task at hand.
17. Role Comparisons
In the product operating model, how do you see the roles of Product Manager, Product Designer, and Tech Lead aligning with or diverging from the Scrum roles of Product Owner, Scrum Master, and Developer? Do you think the Scrum roles sufficiently encapsulate the responsibilities needed for a truly empowered product team, or is there a gap that your model addresses?
Marty Cagan: A product owner is roughly 10% of a true product manager. Your “scrum team” is completely missing a professional product designer. A scrum master is a role normally played by the delivery manager, but in any case, in the product model, the product leaders – the managers of engineers, designers, and product managers – take primary responsibility for coaching and developing strong product managers, strong designers, and strong engineers. A tech lead is a senior developer that plays a central role in both discovery and delivery. To be blunt, a Scrum team is quite amateur compared to a professional product team. The top tech-powered product companies in the world are built on product teams.
18. Scrum Events and Artifacts
Scrum prescribes specific events and artifacts to guide the development process. How do these practices fit into the product operating model? Is there a place for these events and artifacts in the product operating model, or do you advocate for a different approach to align with the principles of empowered product teams?
Marty Cagan: If the engineers on a product team decide to use Scrum for their delivery work, they can run their sprints as formally or informally as they like. But in truth, most product teams moved beyond Scrum many years ago to something that aligns much more naturally with continuous deployment – usually Kanban or a streamlined derivative.
19. Balancing Agility With Product Strategy
A popular critique of Scrum is that it can become overly focused on short-term delivery goals at the expense of long-term product strategy. How does your product operating model ensure that teams remain agile and responsive to change while also staying aligned with a coherent, strategic vision for the product?
Marty Cagan: This is what the strategic context is all about, and this gets to the critical role of product leaders. In a product company, the advice of Agile / Scrum coaches, where each product team has its own product vision and product strategy, is a very clear indication of never having worked in a product company. The book EMPOWERED describes the strategic context necessary for empowered product teams to make good decisions.
20. Scaling Considerations
As organizations scale, they often turn to frameworks like SAFe or LeSS to manage multiple Scrum teams working on the same product. How does the concept of empowered product teams scale in larger organizations, and how does this compare with Scrum’s approach to scaling? Are there valuable lessons from Scrum’s scaling frameworks or areas where you think a different approach is needed?
Marty Cagan: See the answer to question #9 above, but more generally, processes like SAFe are all about optimizing for predictability rather than innovation, which is my theory as to why I have not found a single product model company in the world that uses SAFe or would use SAFe. Further, SAFe is in no sense Agile per the principles behind Agile. It is very obviously Waterfall, which, of course, makes sense for a process designed for predictability. In contrast, one of the product model’s first principles is innovation over predictability, and another is principles over process. So, it should not be hard to understand why the product model is incompatible with a Waterfall delivery process like SAFe. That said, I fully expect to see the words “product model” sprinkled on top of the next iteration of SAFe because that has long been their marketing strategy, and they count on people not understanding or not caring what they are doing.
Conclusion
In our exploration of the Product Operating Model with Marty Cagan, we unpack the transformative journey toward a product-centric approach and dissect the possible interplay between empowered product teams and Scrum dynamics. Cagan critiques the traditional Scrum framework, champions the nuanced roles within robust product teams, and underscores the necessity for innovation-driven, adaptable product management strategies.
What product model do you apply? More interestingly, does Scrum still have a seat at its table? Please share what you learn with us via the comments.
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments