見出し画像

雑記:プロダクトロードマップのアウトカム、アンチパターン、理想 #productdd

はちさんと一緒に始めたPodcast「Product DeepDive」の第1回目を配信しました。

DeepDiveする方法を、僕が手探りすぎて、ただ話題をとっ散らかしただけになったので反省してます😇 まとめてくれた、はちさんのファシリテーションに感謝

せっかく話してみたので、収録後の頭のまとめ的に「アウトカム」「アンチパターン」「理想」をテキストでも書いてみます。
皆さんの現場での話、ぜひ教えてください!

プロダクトロードマップのアウトカム

  • 作成プロセスにおけるアウトカム

    • プロダクトの未来を大きく考え、関係者で議論する機会になる

    • 少し先の未来を具体的に描こうとすることで、自分たちは何がわかっていないのか(何を市場や顧客から学ぶべきか)がわかる

  • 成果物におけるアウトカム

    • 少し先の未来や目標、優先順位を、チームや組織のステークホルダーで共同所有できる

    • プロダクトチームにとっての良い目標となる

    • 社内で相互依存する仕事(他のプロダクト開発、営業戦略策定や仕込み、予算策定、人員計画)の、計画を同様に立てることができる

よくなさそうなプロダクトロードマップ

  • 「何を作るか」まで指定されたロードマップが、上の方から降ってきて、PMやプロダクトチームはそれに従うだけ

  • とにかくハイプレッシャーに働くことを押し付けたくて作らせる(チームを信頼できていないことに対して、相互対話的アプローチを放棄。期日のプレッシャーをかければ、良いものが早く作れると勘違いしている)

  • なんか知らないけど毎期ごとに作るルールになってるから、目的意識をもたずに作る

  • PMやプロダクトチームが、顧客価値を盾に、自分たちの思惑だけで作る。経営層や、ビジネスステークホルダーなどとコラボレーションしようとしない

  • PMやプロダクトチームが、トップダウンを過度に忌避して、上位戦略に理解を示そうとしない。

  • 絵に描いた餅:

    • スコープ x 時期:そんな量そこまでには無理

    • 内容:ディスカバリーもちゃんとやってなくて価値があるかわからないけど、とりあえず書いた。書いたからそれを作る。

  • その精度で作ってないのに、いつの間にか「強い約束」として、納期の遵守を迫る(e.g. リリース時期を顧客と約束してしまう)

  • いつの間にか、会社、市場、顧客の状況を無視して、「ロードマップに載せたから作る」という心持ちになっている

(地雷がたくさんありそうなので、プロダクトロードマップ不要論が世界中に起きる理由もちょっとわかる気もします)

プロダクトロードマップ、こうでありたい

  • そもそもなぜ作成するのか(目的、誰にどんなアウトカムや意思決定をもたらすためのものか)が、クリアに握れており、明記されている

    • 将来像を描いて、エンゲージメントを高めるため

    • 社内で相互依存する仕事(e.g. 他のプロダクト開発、営業戦略策定や仕込み、予算策定、人員計画)の計画を立てるため

    • チームのパフォーマンスが向上するような良い目標を設定するため

    • 経営層や投資家に説明するため(投資の意思決定に使うため)

    • etc…

  • 上記の目的に沿った項目が設計されている

    • 期間:短期視点(四半期〜半年)か中長期視点(半年〜3年)か

    • 項目:アウトカムベースのロードマップで十分か、具体的な開発内容まで必要か。

    • 期日:正確性が、なぜ、どの程度必要か。正確性が必要であれば、コストをかけて見積もる、期間バッファとスコープバッファを適切に積む、早く着手する、が必要。

    • 粒度:細かい改善事項まで書くのか

    • 見せ方や補足事項の必要性:どのくらいコンテキストを共有できている人が見るのか。

  • 会社、ビジネス、プロダクトのビジョン、目標、戦略と整合しており、そことの関連を読み解くことができる

    • 解くべき問題・フォーカスするテーマが記載されている

  • 一定地点での、期待するアウトカムや達成状態(定量 and/or 定性)が記載されている

  • PMを含んだプロダクトチーム主導で作成している。

    • ただしチームで合議するのではなく、適切なタイムボックス内で多面的に発散・議論し、PMが責任を持って収束・意思決定する。

    • e.g. PMがたたきを作る(最初は時期よりも項目にフォーカスする) → それをもとにプロダクトチーム、および必要なステークホルダーと議論・発散 → チームで、不足する情報を顧客やデータから収集 → PMが統合とブラッシュアップ → チームやステークホルダーと再議論 → (許容されるタイムボックス内で繰り返し) → 決定

  • 作成後も、特に具体的な機能などのWhatについては、状況に合わせて柔軟に変更する

残念ながら「このフレームワークに乗って作れば大丈夫!」という意味でのベストプラクティスはないと思いますが、観点などは広く考慮した上で目的に合ったものを作ることはできるのかなと思います。

今後もPodcast『Product DeepDive』は毎週水曜日に更新予定なので、ぜひお好きなプラットフォームでフォローをお願いします!

この記事が気に入ったらサポートをしてみませんか?