共通認識:優れたプロダクトチームを際立たせるもの
共通認識は、優れたプロダクトチームの主要なスキルです。これが良いチームと最高のチームを区別します。11 年の経験を持つ Atlassian のプロダクトマネージャーによると、最高のプロダクトマネージャーとは、すべての答えを知っている人ではありません。チームが何を行い、誰のために行い、なぜ行うのかを理解できるようにする人です。この記事では、hi.ducalis.io チームが共通認識を採用した経験を共有します。これは長く複雑なプロセスでしたが、素晴らしい結果をもたらしました。
優れたプロダクトマネージャーになる方法
Quora のディスカッションによると、主に 2 つのスキルリストがあります。
- 具体的なスキル: 分析、UX/UI、インタビュー、リサーチ、A/B テスト
- 一般的なスキル: 共感力、戦略的思考、主体性、適応力、意図しない結果を予測する能力
優れた PM のスキルセットを決定して学ぶことは難しくありません。
しかし、プロダクトマネジメントはスキルだけではありません。意思決定についてです。
意思決定の 2 つの方法
PM とのユーザーインタビューを 100 時間以上実施した結果、2 つのアプローチを発見しました。
- スーパーヒーロー — すべてを知り、すべてができる PM で、チームのすべての質問に答え、すべての意思決定を行います
- ファシリテーター — チームが問題を理解し、意思決定を行えるように支援する PM です
プロダクトコンサルタントの罠
Steve Jobs についての物語は、人々をスーパーヒーローになるよう鼓舞します。
スーパーヒーローになると、罠に陥ります。マネージャーではなく、コンサルタント、つまりプロダクトに関するあらゆる質問に答える人になってしまいます。
プロダクトスーパーヒーローであることは滑りやすい坂道
Atlassian の Distinguished Product Manager である Sherif Mansour は、貴重な経験談を共有しています。
「What is product management?」からのショット
キャリアの初期、彼は PM とはすべての質問に答えられるスーパーヒーローだと信じていました。最終的に、これは問題につながりました。プロダクトに関するあらゆる質問に答えなければならなくなったのです。「ボタンをここに配置する」「青色にする」「API リクエストをこの方法で行う」などの質問にまで。彼は日常業務で過負荷になりました。
マネージャーとの 1 対 1 のミーティングで、彼はチームが行っていることについて数十の詳細を説明しました。どのボタンを配置したか、どれほど圧倒されていると感じているか。しかし、彼が聞いたのは、より戦略的なことに集中すべきだということでした。
これはプロダクトマネジメントにおける最大の罠の 1 つです。
チームメイトからの質問にどんどん答え続けることで、プロダクトマネージャーからプロダクトコンサルタントに自らを格下げしてしまう。(Ivan Spasojevic の Quora スレッド からのアイデア)
プロダクトコンサルタントの問題
- 質問数が増える — スコープが減少する
- あなたがいないと作業が止まる
- チームが不要な作業を増やす
すべてをチェックして調査する必要があります。そうでなければ、誤って実装されます。おそらく明確な目的もなく。
ロードマップ計画、プロダクト要件ドキュメント、バックログの優先順位付けに助けを求めます。
しかし、チームがそれらすべてを読んだとしても、タスクを異なる方法で認識します。
アイデアや戦略を書き留めたり読んだりすることは、必ずしもそれらを理解することを意味しません。
プロダクトマネジメントはチームスポーツ
2019 年の Mind the Product からのショット
Mind The Product カンファレンスでのスピーチで、Sherif Mansour はキャリア全体における主な誤解を指摘しています。プロダクトマネージャーがすべての意思決定を行うという誤解です。
その考え方を切り替えて、チームに意思決定の権限を与える必要があります。
PM は意思決定の速度を所有します。使命は、チームの共通認識を構築することでそれを向上させることです。それが彼の最も貴重な教訓でした。
共通認識の 3 つの W
チームは以下を明確に理解する必要があります。
- Who (誰) — 誰のために解決しているかについて十分なコンテキストを持っている
- What (何) — どんな問題を解決しているかを理解している
- Why (なぜ) — それがより大きな全体像にどのように適合するかを理解している
共通認識のシグナルの 1 つは、バックログに触れなくてもチームがうまく機能していることです。顧客や戦略に適したタスクを選択するためにあなたを必要としません。彼らは常に、何を、どのように、なぜ行うのかを完全に認識しています。
デザイナー、エンジニア、アナリストは自分で解決策を決定できますか?
優れた共通認識のシグナル
- 数か月間バックログを見ていなくても、チームはうまく実行している
- チームは、ノーススターと整合していない作業について異議を唱える
- チームは顧客を名前で言及する
- チームはアウトプットよりもアウトカムに取り組みたいと考えている。「これによりリテンションが向上します」と言い、「ボーナスを受け取るためにエピックを完了する必要があります」とは言わない
- チームデモは、促されることなく「顧客の問題 Y を解決するために X を構築しています」という形式で行われる
- 彼らのサイドプロジェクトはすべてロードマップと整合している
考えてみてください。PM / CEO / オーナーとして、チームの計画に干渉せず、すべてのタスクを自分で割り当てないことができますか?
卓越したプロダクトマネージャーを作るもの
Sherif は、プロダクトマネジメントの 2 つの主要な技術を指摘しています。
- 共通認識の構築 — 顧客リサーチ、データインサイト、コレクション、調査、ラピッドプロトタイピングなどを行います。重要なのは、これらの活動をチームとして一緒に行うことです。これにより、顧客の問題と意図をよりよく理解し、共通認識を一緒に構築できます
- 共通認識のギャップを特定する — チームに What、Who、Why を明確に理解しているか尋ねます。チームと話すか、調査を実施します。ギャップを見つけたら、それを埋めるための活動を実施します
「3 つの W」調査の結果例
共通認識構築における個人的な経験
チームが hi.ducalis.io を使用する全体の物語は、hi.ducalis.io で共通認識を構築する試みです。
1. 顧客の感情をチーム全体で共有する
顧客インタビューには「The Mom Test」メソッドを使用しています。販売しようとせず、デモを行わず、ソリューションについて何も言いません。潜在顧客がワークフロー、問題、ペインポイントをどのように説明するかを聞くだけです。
チームの他のメンバーのために動画を録画する許可を求めます。ユーザーストーリーの最も鮮明な瞬間を、彼らの感情と言葉遣いで共有することが重要です。この演習は、顧客の問題を感じ取るのに役立ち、チームの時間をあまり取りません。
2. プロダクトの目標を評価基準で表現する
以前は会社の目標と目的を記載したドキュメントがありました。しかし、ヒントなしで主要な指標と目標を覚えることは困難でした。後に、それらを Ducalis のタスク評価基準に変換しました。
3 つの基準セットがあります。
- 共通基準 チーム全体が理解する必要があるもの: アクティベーション、リテンション、サービス速度、コラボレーション支援
- 開発者基準: 開発の複雑さ
- マネージャー基準: 販売ポテンシャル、機能需要
バックロググルーミングの基準セット
3. 金曜日に一緒にバックログを評価する
すべてのチームメンバーは、バックログのタスクとアイデアを見積もる必要があります。開発者とプロダクトマネージャーは、わずかに異なる基準を持っています。主観的にスコアを割り当てるため、簡単で高速です。重要なのは、これを定期的に行うことです。週次スプリントを使用しているため、毎週バックログをグルーミングします。
Ducalis での基準によるタスク評価
4. 月曜日にスプリントを計画する
グルーミング後、すべてのタスクが優先順位順にランク付けされます。最優先リストはアドバイザリーです。チームは独立してスプリントを構成します。計画では、What、Who、Why を説明します。週末にコンテキストが変更された場合、計画を調整できます。
優先順位で並べ替えられたバックログの課題
5. 共通認識のギャップを見つける
- 基準の評価方法がわからない場合は、ダッシュを入れます。その後、基準について一緒に議論し、その説明を書き直すことがあります。タスクを理解できない場合は、Jira にコメントを残します。これにより、報告者はアイデアの混乱やビジョンとの整合性の欠如を見つけることができます
- スコアは、タスクが評価されてから 30 日後に破棄されます。完了しなかった場合は、もう一度見積もりと再考を行います。多くの場合、タスクを削除することを決定します。再評価は重要です。これにより、新しい顧客コンテキストを定期的に受け取るため、バックログの関連性を理解できます
これらすべてが一緒になって、チームアライメントの全体像を提供します。チームが意見の相違を持っている場所や共通認識が欠けている場所がわかります。
hi.ducalis.io チームでの共通認識構築の結果
システムは数か月以内に成果を上げ始めました。以下はチームからのフィードバックです。
- ほとんどの場合、素晴らしいです。マネージャーと開発者の両方が、プロダクトをよりよく理解するようになりました。さまざまな角度から見るようにしています。議論がより理にかなったものになりました。
- 共通認識は高いレベルにあるようです。
- どこに向かっているかの指標が不足しています。たとえば、顧客数は X、収益は K などです。これは優先順位を調べるときに役立ちます。タスクは価値に貢献していますか?(これは修正しました)
- 多くのことが依然として Vit (CEO) に依存しています。彼はタスクの実装をあまり委任したり任せたりしません。
ご覧のとおり、すべてが素晴らしいとは言えません。しかし、毎週改善されています。共通認識の構築には多大な努力が必要です。しかし、それだけの価値があります。「説明するよりも実装する方が速い」と時々考えます。しかし、それは将来のために問題を箱詰めしているだけです。
hi.ducalis.io で私たちの方法を試してください
サインアップして課題の評価を試してください。プロダクト自体が方法論を案内します。
参考資料
P.S. Steve Jobs 症候群 — 未来を予見する孤独な天才であること。顧客や同僚の意見に興味がない人。次に何をすべきかを知っている人。しかし、それでも私たちは Steve が「賢い人を雇い、彼らに何をすべきかを教えてもらう」と言ったことを覚えています。