[和訳・要約] The Essential Guide to Prioritization

はじめまして、こんにちは。

ちょうど先日にProductboard社のサイトから『The Essential Guide to Prioritization』をDLして、自分なりに和訳・要約したので記録として残しておきます。

どのような資料かというと、プロダクト開発における優先順位付けのガイドラインとなります。

INTRO

プロダクトの成功における３つの領域

• 深いユーザーインサイト
• 明確なプロダクト戦略
  • 優先順位付けは、プロダクト戦略に該当する
• 感動・興奮するロードマップ

プロダクト戦略における５段階の成熟度

直感を信じる

• 優先順位付けのフレームワークがない
  • PO/PdMの頭の中で行われる

シンプルな優先順位付けのフレームワークに従っている

• フレームワークに従っているが、目的が定義されていない

目標で優先順位付けされているが、戦略的な明確さに欠ける

• 目標に基づいているが、定義が大雑把であったり、実行可能指標でなく遅行指標（収益、解約など）に基づいている
• 包括的な戦略が不健全

明確な戦略と優先順位付けフレームワークを持っている

• 顧客セグメンテーションと主要なユーザーニーズを理解し、明確に定義された目標に基づいている
• 進捗が設定した時間軸と実行可能指標で追跡できている

全社でプロダクト戦略と目標を完全に理解している

• 会社の全員がプロダクト戦略、目的、実行可能な指標、達成すべき目標を完全に理解している

第1章

優先順位付けの一般的な課題

プロダクト開発の優先順位付けアンチパターン

自分（あるいは他の人）の直感を信じること

• 分析する
• 解決策の前に問題を深ぼる
  • 解決する価値がある？自社の戦略に合致してる？
• 解決策と、その理由は正しいか？

アナリストの意見に過大な権限を与える

• どの程度考慮するかは、業界や分野によって異なる
• 優先順位は、ユーザーの洞察と会話に基づいて行う

営業からのリクエストにロードマップを左右させる

• 戦略・目標をサポートするものであるか？
• 短期的な利益は見込めるが、ターゲット・セグメントや戦略のニーズから外れていないか？

イエスと言いすぎる

• 処理しきれない要望やアイデアが常に存在する
• PdMは「ノー」ということに抵抗がないことが必要になる
• 明確な優先順位付プロセスを持つことで、「ノー」の理由を理解してもらえる

サポートリクエストをロードマップに反映させる

• UXのペインポイントやユーザーの混乱など小さいものになりがち
• 戦略全体でリクエストを評価する必要がある
• 開発リソースを費やすと、本来の価値提供ができなくなる可能性がある

競合他社に遅れをとるプレッシャーを感じている

• 機能競争を避ける。
  -競合を深く理解して、差別化できる機会を探る
  -解決策にこだわらず、問題に引き戻す。

顧客インサイトや要望の誤処理

• ユーザーから洞察を得るのは開発プロセスでは不可欠
• 戦略をユーザーにアウトソーシングすることは避ける
• ユーザーのFBは常に自社の戦略・目標に紐づけて考える

声の大きい人に任せる

• 大きい影響力を持ちながらビジョンが揺らぐ場合もある
  • 顧客からの圧が強い場合など
• 戦略・目標を定め、すべての仕事が相互に関連付ける

プロダクトマネジメントでの危険な動物たち

HIPPO（カバ）「高給取りの意見」

• すべての決断を下したがるHIPPOに舵を切らせたり、流されてはならない
• ビジョンや目標がHIPPOと一致ない場合は危険な海域に流されている

ZEBRA（シマウマ）「根拠はないが、実に傲慢」

• すべて知っていると思っている
• 根拠がなく直感に頼っている
• 自分の中かのZEBRAを食い止めるには...
  • 決断を裏付けるデータがあるか確認する
  • 検証し、証拠を集めるために、実行できる実験を考える

WOLF（オオカミ）「最新の火災に飛び込む」

• 注意力が低く、一つの問題から次の問題に飛び付きたくなる
• チームの集中力と効率性を低下させる

RIHIO（サイ）「名だけの存在」

• チームに貢献できていない
• 意思決定を阻害することもない
• 優先順位付けのプロセスを定義して、チームメンバーが意思決定を理解することで、積極的に参加する自信につなげられる。

第2章

優先順位付けプロセスの標準化

STEP1：本質的な質問を自分に問う

どんな優先順位を付けているか見直す

• 過去半年をリリースを振り返って、正しい優先順位を付けていると自信を持てるか？
  • 定性的なフィードバック、定量的なデータなどに基づいて優先順位を設定できているか？
• 優先的に取り組んでいる機能が1年半後にビジョンに向けた原動力になっているか？

優先順位付けのフレームワークを決定する前に投げかける質問

• どのような要素を含めることが重要か？
• 既存の方法・フレームワークを使うか？独自で考えるか？
• すべてのPM・チームに共通するか？固有のものか？
• 誰がインプットを提供するか？
• 誰が意思決定するのか？
• 今のステップがプロダクト開発全体のどこに位置付けられているか？
• どう人を巻き込むか？

その他

• レトロスペクティブを行う。
  • 優先順位付けの振り返りを行う。
    • 優先順位付けプロセスを再構築するステップを形成できる。

STEP2：プロダクトのビジョン・戦略・目標を明確にする。

プロダクトビジョンは優先順位決定プロセスを標準化する上で重要

• どこに向かっているか？なぜそうするのか？を明確にする。
• ビジョンに沿わない機能は優先されるべきではない。

明確なビジョンを定めるには、ユーザーのアウトカムを考える。

• 1年半程度の中長期から長期的な視野を入れる。

ビジョンにはユーザーニーズと洞察を盛り込む。

ビジョンが明確になったら、戦略を定義する。

• 戦略が決まったら、目標を設定する。
  • すべての目標がイノベーションにつながるとは限りません。

優れたビジョン・ステートメントの4つの原則

• 顧客志向であること
  • 顧客はプロダクトビジョンの一部である。
• 非現実的ではなく、少し背伸びをすること
  • 達成可能であること。
  • 無理だと何から手をつければ良いか分からない。
• 差別化を図る
  • ビジョンでプロダクトを説明する
• X年後を見据える
  • 5年後に○○と言われるようにした

STEP3：優先順位付けで使用するフレームワークを決定する。

Value vs. Complexity（価値と複雑さの比較）

価値と複雑さをグラフ化したもの

• Y軸：Value（価値）
  A. ペルソナ・市場に対してもたらす価値（効率化、コスト削減など）
  B. あなたの会社が受け取る価値（新規顧客、アップセルなど）
• X軸：Complexity（複雑度）
  • 運用コスト
  • 顧客トレーニング、移行、照会対応のコスト
  • 開発リソースのスキル希少度
  • リスク（法規制変更、新技術による代替など）

価値が高く、複雑さが低いものを優先する。

• 優先順位
  1.High Value, Low Complexity:投資対効果が高い
  2.Low Value, Low Complexity:クイックに小さな効果
  3.High Value, High Complexity:効果は高いが慎重に対応する必要がある
  4.Low Value, High Complexity:基本対象外

参考）

RICEメソッド

以下の４つの要素でスコアリングする。

• Reach（到達度）
• Impact（インパクト）
• Confidence（信頼度）
• Effort（労力）

RiceScore=\frac{Reach * Impact * Confidence}{Effort}

参考）

KANOモデル

顧客の満足度と機能の充足度をグラフ化したもの

• Y軸：Satisfaction(満足・不満足)
  • 顧客の満足度（どのくらい満足してくれるか）
  • 5段階で評価する。
    • Delighted：大満足
    • Satisfied：満足
    • Neutral：普通
    • Dissatisfied：不満
    • Frustrated：大不満
• X軸：Funcionality（充足・不充足）
  • 機能の充足度（どのくらいリッチな機能か）
  • 5段階で評価する。
    • Best：可能な限りで最良
    • Good：使い勝手が良い
    • Basic：可もなく不可もなく
    • Some：使い勝手が悪い
    • None：機能が不在

その機能を4つのカテゴリーに分類する。

• Performance（パフォーマンス）：性能を向上させる機能
• Must be（必須）：必要な基本的な機能
• Attractive（魅力的）：意外性があるが、お客様に喜ばれる機能
• Indifferent（無関心）：ポジティブな影響を与えない機能

優先順位

Must be > Performance > Attractive > Indifferent

グラフ上では無関心は破棄する。

参考

STEP4：試す。

選択した優先順位付けフレームワークをバックログに適用する。

• フレームワークは方向性を示すもの、正解ではない。
• 自分の感覚とズレる場合は、重み付けを調整しても良い。
• 大事なのは、会話、意思決定、行動、学び・変更の反復

STEP5：チームのワークフローに組み込む

ワークフローに組み込み定期的に実施することが重要。

効果的な優先順位付けを行うための良い習慣

• 新しい機能のアイデアを収集するプロセスを確立する
  • 機能アイデアを一箇所に集める。
  • 要求の裏付けとなるデータを用意する。
  • 意思決定者を決める。
• 「ノー」と言うことを学ぶ
  • なぜ特定の要求をするのかを理解する。
  • ビジョンと合致しているか確認する。
  • 「ノー」の場合は、その理由を明らかにする。
• 優先順位をデータで裏付ける
  • 顧客からのフィードバックや調査などを、意思決定に役立てる。

まとめ

優先順位付けとは、意思決定に何らかの構造と厳密さを適用すること。
メンバーと定期的に会話をすることでもある。
提案が優先順位に合わない場合は、自信を持って断ること。