マーティ・ケイガンが製品オペレーティングモデルとスクラムの将来について語る

製品運用モデル: Marty Cagan インタビューの概要 製品運用モデルは Marty Cagan によって提案され、従来の企業に製品中心の変革への道を提供することを目的としています。このモデルは、製品チームに権限を与え、重大な問題の解決を担当する専門家に裁定権限を委任することに重点を置いています。 Cagan 氏は従来のスクラム設定に批判的で、予測可能性よりもイノベーションに焦点を当てた透明性と継続的デリバリー プロセスを提唱しています。製品の運用モデルでは、委任、部門を超えたチームワークが重視され、エンジニア、デザイナー、プロダクト マネージャーの役​​割が連携されています。このアプローチは、通常開発者のみで構成されるスクラム チームとは異なります。

TL; DR: 製品運用モデル: Marty Cagan インタビュー

製品管理革命に関する Marty Cagan の見解について話しましょう、最新の著書『Transformation』で説明されている製品オペレーティング モデルを採用することで、イノベーションを推進する権限を与えられたチームと洞察を受け入れます。製品中心のアプローチへの変革パスを効果的にナビゲートする方法と、マーティがこの文脈でスクラムをどのように見ているかを明らかにします。

「変革」本の表紙

製品運用モデル インタビューの質問セット 1: 一般モデル

マーティ キーガンの「変革」の強調重要だが実行可能な変化製品の運用モデルに焦点を当て、変革の最初のステップ、信頼の重要な役割、結果への焦点を強調します。同氏は業界の例を用いて疑念に反論し、製品オペレーティングモデルの適応性と拡張性について議論しました。 Marty Cagan はまた、プロダクト マネージャーの役​​割の変化、スピードと品質のバランス、継続的な顧客エンゲージメントについても語ります。最初の質問セットは、製品のオペレーティング モデル自体に関するものです:

1. 変革について理解する

マーティ、著書『変革』の中で、移行の鍵は何だと思いますか。製品の運用モデルにどう影響するでしょうか? 従来の企業にとってはそれが必要であり、可能です。この変革を開始するために貴社が取るべき最初のステップについて詳しく教えてください。

Marty Cagan: 組織の評価から始めることをお勧めします。第 29 章で使用したものを提供します。

2. 成功事例

本書では、変革の成功に関する詳細な事例を紹介します。変革の過程で重大な障害を克服した企業の書籍には載っていない例を教えていただけますか?

マーティ・キーガン: それがこの本を書く目的です。それぞれのケースは、企業が重大な障害を克服した例を表しています。各ケーススタディは重要な作業を表しています。

3. 製品チームに権限を与える

製品チームに権限を与えることの重要性を強調しました。あなたの経験の中で、組織におけるエンパワーメントに対する最も一般的な障壁は何ですか?どうすればこれらの障壁を取り除くことができるでしょうか?

マーティ・キーガン: 最大の障害は信頼です。重要な問題を解決する責任を他者に与えるには、経営陣や関係者からの真の信頼が必要です。そのため、変革では時間をかけてその信頼を獲得することが重要です。

4. 変革におけるリーダーの役割

製品モデルへの移行を成功させるために、CEO や上級リーダーは考え方や運営方法をどのように変えるべきでしょうか?

Marty Cagan: 主に、上級リーダーは製品モデルとそれが何を意味するかを理解する必要があります。次に、製品チームが信頼できることを証明する機会を喜んで提供する必要があります。

5. 変革後のイノベーション

企業が変革に成功した後、古いモデルに陥らずに革新を継続するにはどのような実践が必要でしょうか?

マーティ・キーガン: 会話が実際に結果に向けられ、チームが結果を達成する方法を知っていることを実証すると、企業が単なる成果を出すことだけに戻るのは非常に困難です。したがって、重要なのは一貫した結果に焦点を当てることです。

6. 変革を成功させるための指標

製品主導型組織への変革の有効性を測定するために、企業が追跡することを推奨する指標は何ですか?

Marty Cagan: 多くの進捗指標がありますが、変革の焦点は結果の提供にあるため、製品チームが結果の提供を開始しない限り、他の指標はアクティビティの指標 (別名バニティ指標) にすぎません。繰り返しますが、重要なのは一貫して結果を提供することです。特定のパイロット チームから始めて、そこから拡張することをお勧めします。

7. 懐疑論に対処する

社内の懐疑論、特に製品の運用モデルが特定の業界や市場に適していないと考える人々にどのように対処しますか?

マーティ・キーガン: まず、私たちは皆、特に多くの約束をしているにもかかわらず結果を出していない組織では、懐疑的になるのは正常で合理的であることを認識する必要があります。第二に、本書の例が、規制された金融サービスから規制された医療、規制された鉄道旅行に至るまで、世界の非常に多くのさまざまな業界や地域をカバーしているのはこのためです。しかし、誰かが移行しようとしない理由を見つけたい場合、何かを選んで「これが私たちにはできない理由です」と言うのはそれほど難しいことではないということを指摘することが重要です。しかしこの本には、企業がこうした人々を無視している例がたくさん出てくる。

8. 製品戦略とビジョン

製品のオペレーティング モデルと一致し、市場の変化に適応する製品戦略とビジョンを開発することを企業にどのように推奨しますか?

Marty Cagan: If they read the book EMPOWERED, they would understand how to create a strong product vision and product strategy, and they would see that while the product vision is designed to span several years, the product strategy is designed to span quarterly Update it once to adapt to market changes (and the product team’s ongoing learning).

9. Scaling Agile and Product Practices

What are the key factors to consider when scaling Agile and Product practices across multiple teams and regions in a large organization?

Marty Cagan: This product model is used by some of the largest technology-driven product organizations in the world, larger than most by several factors. Therefore, there should be no doubt whether the model is scalable. In fact, at the heart of the model is continuous innovation and results at scale.

10. The future of product management

With the rapid advancement of technology, how do you see the role of product managers evolving in the next ten years?

Marty Kegan: This is a huge topic. See "Preparing for the Future."

11. Balancing Speed ​​and Quality

How does a company balance the speed of product development with the need to maintain high quality standards?

Marty Cagan: The key is to realize that speed and quality are not mutually exclusive as long as the team uses the principles of the product model, especially small, frequent, uncoupled releases, that is, continuous delivery. Check out the book Accelerate to learn the rationale behind how the best organizations move faster and maintain higher product quality.

12. Customer-centricity during transformation

Can you discuss how the company remains customer-centric during and after transformation?

Marty Cagan: If companies follow the principles in the product model, it means they will have close and ongoing contact with their users and customers. In fact, this is one of the main reasons for transformation. Customer interaction is critical to the innovation process.

13. Learn from Failure

Can you share a personal or observed example of a failed transformation attempt and what lessons were learned from the experience? ?

Marty Kegan: See "Transition Failure."

14. Integrating New Technologies

How should companies integrate new technologies such as artificial intelligence and machine learning into product development processes as part of their transformation?

Marty Cagan: One of the defining characteristics of companies using product models is the level of involvement of engineers, particularly as a source of new enabling technology. Today, you can see product model companies that are leading the way in applying artificial intelligence and machine learning.

15. Maintaining agility in a changing market

How can companies ensure that their newly adopted product models remain nimble and able to respond to unforeseen challenges?

Marty Cagan: This is a key reason why a product model is a set of principles rather than a process, framework, or methodology.

Product Operating Model Interview Question Set 2: Model and Scrum

The second set of questions explores the nuances of the Product Operating Model and Scrum. We dive into issues surrounding empowered teams, role dynamics, and scaling in agile environments. Marty Cagan critiques traditional Scrum setups and highlights the differentiation and depth of roles in empowered product teams, challenging traditional Scrum practices and championing innovation over predictability:

16. Empower Product Teams vs. Scrum Teams

Marty, in your framework you argue for giving product teams autonomy to creatively solve problems. Could you elaborate on how this concept differs from or aligns with the Scrum framework's idea of ​​self-managing teams? What aspects of Scrum teams do you think are underutilized in promoting empowerment?

Marty Cagan: Most "scrum teams" are just a group of developers and a backlog manager product owner, also known as the "delivery team". An empowered product team is made up of fully cross-functional professionals—developers, designers, and product managers; see “Product vs. Feature Teams.” More generally, Scrum is a specific delivery process. Product teams are designed for discovery and delivery, and engineers can use whatever delivery process they feel is best for the delivery task at hand.

17. Role Comparison

In the Product Operations Model, how do you view the roles of Product Manager, Product Designer and Tech Lead compared to Product Owner, Scrum Master and Agreement or disagreement among Scrum roles such as Developer? Do you think Scrum roles adequately outline the responsibilities needed for a truly empowered product team, or are there gaps in your model?

Marty Cagan: A product owner is about 10% of what a true product manager is. Your “scrum team” completely lacks professional product designers. Scrum Master is typically a role played by a delivery manager, but regardless, in the product model, product leaders—managers of engineers, designers, and product managers—are tasked with coaching and developing strong product managers, strong product managers main responsibility. Designer and strong engineer. Technical leads are senior developers who play a central role in discovery and delivery. To be honest, Scrum teams are quite amateur compared to professional product teams. The world's top technology-driven product companies are built on product teams.

18. Scrum Events and Artifacts

Scrum specifies specific events and artifacts to guide the development process. How do these practices fit into the product operating model? Do these events and artifacts have a place in the product operating model, or are you advocating for a different approach that aligns with the principles of empowering product teams?

Marty Cagan: If engineers on a product team decide to use Scrum for delivery work, they can run sprints as formally or informally as they wish. But the reality is that most product teams moved beyond Scrum years ago to something that more naturally integrates with continuous deployment—usually Kanban boards or a simplified derivative.

19. Balancing Agility with Product Strategy

A popular criticism of Scrum is that it can focus too much on short-term delivery goals at the expense of long-term product strategy. How does your product operating model ensure that the team remains agile and responsive to change, while staying aligned with the product’s coherent strategic vision?

Marty Cagan: That’s what the strategic context is all about, and that’s about the critical role of the product leader. In product companies, Agile/Scrum coaches advise that each product team has its own product vision and product strategy, which is a very clear sign of never working in a product company. EMPOWERED describes the strategic context needed to empower product teams to make the right decisions.

20. Scaling Considerations

As organizations grow in size, 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 large organizations? How does this compare to Scrum’s scaling approach? Are there valuable lessons learned from the extended Scrum framework or areas where you feel a different approach is needed?

Marty Cagan: See answer to question #9 above, but more generally, processes like SAFe are all about optimizing for predictability rather than innovation, and here’s my theory explaining why I There is not a single company in the world that uses SAFe or uses SAFe as a single product model. Furthermore, according to the principles behind Agile, SAFe is anything but Agile. Obviously this is waterfall, which certainly makes sense for a process designed for predictability. In contrast, one of the first principles of the product model is innovation over predictability, and another is principles over process. Therefore, it should be easy to understand why this product model is incompatible with waterfall delivery processes like SAFe. That said, I fully expect to see the term "product model" appear above the next iteration of SAFe, as this has been their marketing strategy for a long time and they're banking on people not understanding or caring about what they're doing.

Conclusion

In exploring the product operating model with Marty Cagan, we embarked on a transformational journey toward a product-centric approach and dissected Possible interactions between empowered product teams and Scrum dynamics. Cagan critiques the traditional Scrum framework, which favors nuanced roles within strong product teams, and highlights the need for an innovation-driven, adaptable product management strategy.

What model of product do you use? More interestingly, does Scrum still have a place? Please share what you learned with us in the comments.

以上がマーティ・ケイガンが製品オペレーティングモデルとスクラムの将来について語るの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。