#blog [https://www.svpg.com/empowered-product-teams/](https://www.svpg.com/empowered-product-teams/) ↑ のブログをさらに補足したもの [https://www.svpg.com/product-vs-feature-teams/](https://www.svpg.com/product-vs-feature-teams/) # 何が書かれているか 背景として、Discovery に関するリスク (value, usability, feasibility, and viability) に対してテクニックはある程度増えてきている。 が依然としてそれを使いこなしているプロダクトチームは少なく、Amazon、Google、Apple、Netflix などがそれぞれ異なった企業文化を持ちながらもプロダクトチームとしてうまくやれている理由を整理してみるというもの。 # メモ [https://www.svpg.com/empowered-product-teams/](https://www.svpg.com/empowered-product-teams/) > In most companies, technology teams exist "to serve the business." That is very often the literal phrase you will hear. But even if they aren't explicit about it, the different parts of the business end up driving what is actually built by the technology teams. > > However, in contrast, in strong product organizations, teams exist for a very different purpose. They exist "to serve the customers, in ways that meet the needs of the business." "to serve the business. " ではなく、 "to serve the customers, in ways that meet the needs of the business." であるべきというのがプロダクトチームの目的の大きな違い > The leaders don't trust the teams. Specifically, they don't believe they have the level of people on their teams they need in order to truly empower them. So they, along with the other key business leaders from across the company, believe they need to very explicitly direct the teams. This is also known as the "command and control" model of management. > > When I ask these leaders why they don't put people in place that they do trust, they usually argue that they either can't find, can't afford or can't attract the level of people that Google, Amazon, Apple and Netflix hire. これが実現できていない多くの組織では、Command and Control スタイルのマネジメントを自ら選択して実施していることが多く、優秀な人材を採用できないということを免罪符にしているが実は他の企業で働いている多くの人と大差はないことが多い。 > I realize this is counter-intuitive to many people, but moving to truly empowered teams does require moving away from the command and control model of management, but this does not mean you need fewer leaders and managers, it means you need stronger leaders and managers. 真に Empowered な Product Team を作るには Command and Control をやめていく必要がある。 これはマネージャーやリーダーの数を少なくするという意味ではなく、より強固なマネージャーやリーダーが必要だということ。 > The purpose of strong leadership is to inspire and motivate the organization. This involves five major responsibilities: > * Product Vision > * Product Strategy > * Product Principles > * Product Priorities > * Product Evangelism 記事には詳細な説明があるが簡略化する ### Product Vision : 関わる全ての人間が目指すべき方向。これがないと同じ方向に向かっていけない。 ### Product Strategy : Vision だけではなく具体的なマイルストーンも必要になる。これがないと目指すべき Vision への方向が見えなかったり、1つのプロダクトで必要以上に広いユーザーを救おうとして結果として誰も救うことができないプロダクトを作ってしまう ### Product Principles : 難しいトレードオフを判断するときの指針となるような価値観 ### Product Priorities : 言わずもがな ### Product Evangelism : 組織全体がこのプロダクトが目指すべき世界観に共感している必要がある。 > It is important that these managers understand, and can effectively communicate, the vision, strategy, principles and priorities from the senior leaders, but beyond that, these managers have three critically important responsibilities: > * Staffing > * Coaching > * Objectives 上記のリーダーシップについては語れている必要があるのと同時にマネージャーはさらに3つ重要 ### Staffing : 人を採用し、オンボードし、効果的にプロダクトにアサインすること ### Coaching : 言わずもがな (というか語り尽くせないので [[Resilient Management]] をおすすめ) ### Objectives : チームがある一定の期間で解決するべき問いの設定とその結果の測定 > First, when I say "ordinary people" I'm not suggesting that you can hire anyone off the street and turn them into members of extraordinary teams. They do need to have the necessary skills to succeed. > > However, I am suggesting that rather than obsessing over "cultural-fit," or finding so-called "10X" employees, or thinking you need to hire people with a deep knowledge of your domain, focus instead on what I'm about to describe. ordinary people は当然持つべきスキルを持ってる人のことを指していて、10X エンジニアとかではないことを意味している。 その上で以下の2つの要素が大事 Competence : まず何を以てもスキルが大事。マネージャーがコーチングを通して業務で必要なスキルを身につけることができると判断した場合に限ってはポテンシャルでの雇用もする。 Character : Culture Fit と呼んだりもするが、著者は性悪説に基づくのではなく性善説に基づいた上で絶対に組織を悪くしてしまう人の採用だけを避けるという考え方を主張している。 [https://www.svpg.com/product-vs-feature-teams/](https://www.svpg.com/product-vs-feature-teams/) > I'm sorry for that, but the degree of ongoing noise and confusion surrounding the role of product at tech companies is only getting worse. Moreover, I see the issues and problematic behaviors getting institutionalized in conference talks, training programs and so-called certification programs for product people. > > I have talked about this issue several times in the past, most specifically in the article and keynote on Empowered Product Teams. However, so many people hear only what they want to in that, and it has become clear to me that I need to be more explicit. > > So while this article might be painful to read, if you've been frustrated with the contradictory and confusing messaging from people in the product world, if you bear with me here, I am hopeful that this will provide some much needed clarity. ↑ の記事が良いようにしか伝わらなかったケースが散見されたため、改めて補足記事を書くことにしたらしい Product Teams は大きく分けると3つのタイプがある - Delivery Teams : PO がバックログ管理者になっていて、機能を作っていくだけのチームを指す。著者からするとこれはウォーターフォールを別のパッケージにしただけで本質は変わってないとしている - Feature Teams : 後述の Value と Bussiness がステークホルダーに委ねられてしまっているチーム - Product Teams : Empowered されていて、与えられた問題をカスタマーがもっとも良いという方法で自ら解を見つけデリバリーするチームのことを指す。 プロダクトにおける 4つのリスク (= 不確実性) - Value risk (will people buy it, or choose to use it?) - Usability risk (can users figure out how to use it?) - Feasibility risk (can we build it with the time, skills, and technology we have?) - Business Viability risk (will this solution work for the various dimensions of our business?) > In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us. それぞれのリスクに対して、プロダクトマネージャー、デザイナー、テックリードが協力関係にあるべきだが、 特に Feature Team では、 Value と Bussiness の部分を主導している人がステークホルダーにいる。 > The job of the product manager on a feature team is most commonly described as a form of facilitator, "herding the cats" in order to get the feature designed and delivered, or some nebulous and weak form of cross-functional leader that's not really responsible for anything specific. These feature teams will often think they are doing product discovery, but really it's just design and maybe a little usability testing. > The result is that in feature teams, the product manager role is mainly project manager, and partly (unskilled) designer. ### Product Team vs Feature Team Indicators - Are you provided roadmaps with prioritized features and dates, or are you assigned problems to solve with business outcomes? - Is there role confusion between you and your designer? - Is there role confusion between you and your delivery manager? - Do you spend most of your day doing project management? - Did you try using OKR's and was it a mess, either ending up being rejected, or some contrived mashup of outcomes and features delivered? - Do you have a team of missionaries or mercenaries? - missionaries : 宣教師 - mercenaries : 傭兵 - What is the level of accountability? > I can tell you that with few exceptions, the best product teams at the best companies are all about the empowered product team model. However, I will admit that even in what I consider the best product companies, not every product team is empowered. In truth, some are feature teams. Usually that's because the leadership does not yet trust that particular team. Sometimes that trust needs to first be earned. And sometimes the issue is with the leader wanting to dictate solutions. この記事に対する FAQ [https://www.svpg.com/product-team-faq/](https://www.svpg.com/product-team-faq/) このような質問が寄せられている - You said that the designer is responsible for usability, and the engineers are responsible for feasibility, but is that all they are really there for? - Can you summarize the differences between delivery, feature and product teams? - Can we have an empowered product team without a competent product manager? - I'm still uncomfortable with the concept of the product manager as CEO of the product. - Why would people be upset? - Is there any way to have true empowered product teams with SAFe? - Why don't you like to engage on Social Media/Twitter? # 感想