「施策の優先順位づけ、完全に理解した」 ~ICEスコア・狩野モデルなどを掛け合わせた、プロダクト開発施策優先順位づけ
本記事は、プロダクトマネージャー Advent Calendar 2022 の5日目の記事です🎄
プロダクト開発における施策の優先順位づけ、みなさんどうやってますか？
会社の状況・事業目標・プロダクトのミッション・市場・競合他社・VoC・投資対効果・関わるメンバーのモチベーションなど、様々な変数を踏まえて優先順位を決め、プロダクトを非連続に成長させるのが、プロダクトマネージャーの仕事の1つです。
優先順位の決め方は、会社・事業・プロダクト・フェーズ感などによってさまざまですが、さいきん試行錯誤していた優先順位付けの仕組みがいい感じにワークしたので、記事にまとめてみようと思います。
こんな人にオススメ
プロダクト開発の優先順位づけで困っているひと
他のPMがどう優先順位づけをしているか知りたいひと
プロダクト開発に限らず、優先順位づけで悩んでいるひと
この記事ではなすプロダクト・事業について
note上で月額制のサブスクリプションを作成し、ファンや仲間から支援をうけられる、noteメンバーシップというプロダクトをリリースし、現在はグロースをがんばっています。
もともとnoteにある収益化機能の有料記事・有料マガジン・定期購読マガジンに加え、クリエイターが普段の活動の延長線上で、継続的に収益を得るためのサポートをおこない、noteが掲げている「だれもが創作をはじめ、続けられるようにする」ことを目指すプロダクトです。
7月にリリースし、一定数のユーザーに利用いただいてはいるものの、市場に認知されPMFしているか？というとそこまではいけていない、0.1→1のフェーズにあるプロダクトの話をしていきます。
5ステップでできる！優先順位づけの実例
以下、実例を交えながら優先順位づけのステップを解説します。
1, 目標を定める
目標を定めることで、自分たちが向かう先や伸ばすべき数字がチーム内外の共通言語になります。
目標があったほうが目指している目標にたどり着くまでのスピードをはやめられるし、仮に目標設定が間違っていた場合でも、目標との差分を確認することで、「やっぱり違った」に気づきやすくなります。
個々の施策の優先順位づけにおいても、目標に影響するか否かという判断基準があると、驚くほどスムーズに議論が進むようになります（経験談）。
2, アイディアを出す
〇〇を達成するためのアイディアのように制約を設けて、まとまった時間をとってアイディア出しするのがオススメです。
また、日々アイディアの種を蓄積しておけるように仕組みをつくっておくことも強くオススメしています。いいアイディアが思い浮かんでも記録されていないと忘れられてしまいますし、取るに足らないと思っていたアイディアから、思いもよらぬ案が生まれたりするものです。
僕のチームではこんな感じでアイディアを蓄積・整理しています。
アイディアの出し方については世の中に様々なプラクティスがあるので割愛します。
3, 狩野モデル×目標達成影響度でマッピングする
冒頭で述べたように0.1→1フェーズのプロダクトゆえ、まだまだチャレンジャーの立場にあります。
大きくコストを掛けて、足の長い施策に投資しているとあっという間に先行している他社に引き離されたり、後発サービスに追い抜かれていくのが我々の業界の常、実施する施策が魅力的品質なのか・当たり前品質なのか、を把握し、適切に優先順位づけをすることが重要になります。
狩野モデルに加えて、どの施策が目標達成への影響度が高そうかを見極めて投資判断を行うことも等しく重要です。
①施策案が魅力的品質・当たり前品質どちらに当てはまるか？に加え、②目標達成への影響度がどの程度か？を二次元にマッピングします。
マッピングすることで、どの象限の施策が多いかがざっくりわかるようになり、もっと頭を捻ってアイディアを出す必要があるか、いま出ているアイディアで次のステップに進んでよいかが把握しやすくなります。
4, ICEスコアをつける
Impact・Confidence・Easeを考え、無慈悲にスコアを付けます。
・Impact: 重要指標にどれだけ影響を与えるか
・Confidence: 自信度、成功率
・Ease: どれだけ低リソースで実現できるのか
無スコアリングすることで、優先度が高い施策・低い施策が明確になり、「この領域に注力するのが筋がよさそう」という当たりがつけやすくなります。
僕のチームでは、単純にICEスコアをつけるだけでは、どの目標に影響するかがわかりにくい、また、ステップ3で行った狩野法 + 目標影響度も踏まえて優先順位を判断したいと考え、指標を増やしています。
各四半期のSnapshotを残すために、検討が一旦済んだらタブをコピーして、次の四半期では前四半期での検討結果も踏まえて再度スコアリング・優先順位の検討を行っています。
上記テンプレートで優先順位を検討しはじめて3四半期目に突入するところなのですが、過去の検討結果や、「〇〇の実装が完了したらやれそう」などのメモが残っていたことで、前四半期・前々四半期とひ比較してすばやくスコアリング・優先順位の議論が進められています。
ICEスコアリングについて、詳しく知るにはこちらの記事もオススメです。
5, スコアをもとにステークホルダー間で議論する
ステップ4で作成したスコアリングシートを土台に、事業責任者などステークホルダーと議論します。
「この施策良さそうだけど、なんでConfidence低いんだっけ？」
「この施策Impactが10だけど、根拠ってどんな感じ？」
「Easeが1になってるけど、こうやったら2週間くらいで実現できない？」
「この施策、不確実性高いからはやめに検証まで進めたいね。」
などなど、定量化された情報を眺めながら議論を進めることで、優先順位づけの議論が活発に、かつスムーズになります。
プロダクト開発チームとしての意志は示しつつ、事業全体の動きや会社の目標との整合性を確認しながら最終的な優先順位を決定します。
「四半期の最初に決めたことを必ずやりきることで、確実に目標達成に近づける」のであればそれでよいですが、期中に事業や市場の状況が変わったり、よりよいアイディアが出てくることも考えられます。
そのため、あくまで目標を達成するためにこの領域に注力するといったレベルで期待値を調整し、都度変更が入る場合に何とトレードオフとなるかの議論がしやすくなるよう他チームや経営陣と合意形成するのがオススメです。
やってみてよかったこと
コミュニーケーションツールとして大活躍した
ステップ5に書いたような議論をするためのベースとして、数値化・一覧化されたドキュメントがあることで、各所との合意形成が非常に進めやすく感じました。
また、優先順位づけだけでなく、日々のコミュニーケーションを円滑にするためのツールをしても活躍します。
他チームと会話していて、「この機能を追加してほしい」と言われた際に、数値化して根拠を示すことで納得してもらいやすくなります。
加えて、プロダクト開発チームがどういった根拠のもとで施策優先順位を決めているかが明らかになることで、他チームからの「なんで言ってもやってくれないのか」や、それに回答する開発チームの「なんで何度言っても理解してくれないのか」を減らすことができます。
ステップを進めるにつれて、課題や施策への理解が深まった
課題や施策を多角的に見ることで、何を、どういった優先順位で、どうしていくのがよさそうかの理解が深まりました。
素早く不確実性を解消できそうで、やって見る価値がありそう
インパクトは大きい可能性があるが、実装工数が膨大
すぐに試せるが、リーチできるユーザー数が少なすぎる
など、定量・定性データ・開発メンバーの経験知・世の中のスタンダードなどを下敷きに、短期間で一気に施策を分析できたのがよかったのではと思います。
これからの課題
ユーザーや課題の解像度を上げつづける必要性
この記事で紹介した優先順位づけでも、ユーザーインタビューやアンケート調査など、UXリサーチの結果も踏まえて意思決定を行っています。
ICEスコアリングなどをすることで、優先順位を決めることは容易になりますが、どの課題を解決するとよさそうか・ユーザーがどういった課題を抱えているかはリサーチを重ねないと理解できません。
まだまだユーザー・課題への理解が足りていないので、定常的にインタビューをしたり、様々な確度でデータ分析を行っていく必要性を感じています。
検討・議論のベースがあることで思考に制約が掛かるリスク
議論のベースがあることで、無意識に「このシートに書いてあることをベースに考えればよい」という思考の制約が発生する懸念があります。
アイディア出しをMiroなど別の場所で行う、四半期ごとに目標に沿ったアイディア出しをする、日々テーマを決めてアイディア出しをする等で回避しようとしていますが、拠り所としてのスコアリングシートがあることで思考にキャップが掛かってしまわないよう注意が必要だと認識しています。
PMに依存しない優先順位づけ
同僚のじつぞんさんの記事を読んで、チームで優先順位を決められるのもとてもよいなと思っています。
僕のチームでは、解くべき課題・実現したいことをどんな仕様で、どんなUIで実装するかはチームのみんなで会話しながら決めており、「PMいなくていいのでは？」と思う場面も多くあります。
他方、施策の優先順位づけにおいては、事業状況・他チームとの連携などインプット量に差異があり、PMが意思決定したほうが効率がよい状況です。
映画で観る特殊部隊やスパイ組織のように、「適切に役割分担して、予想外の事態が起きても都度自分たちで最善の判断をして前に進むことができる」ことこそがよいチームの条件であると信じているので、よりはやく・質の良い意思決定がチームでできるようにしていけると好ましいと思っています。
さいごに
今回は僕が関わったプロダクト・フェーズにおける優先順位づけの方法を共有しましたが、「プロダクトや事業のフェーズにあわせて、世の中に数多ある方法の中から自分たちにあう手法を選ぶ」のが定石だと思います。
他にもtoB or toC、チームの構成など各チームが抱える変数によって最適な方法は違うはず。都度自分たちにあったフレームワークを使ったり、多少カスタマイズしていくのがよいのですね。
以下記事でもたくさんのフレームワークが紹介されてます。
言うまでもない…とは思いますが、「完全に理解した」はインターネット？エンジニア界隈？のミームであって、この先も「なにもわからない」と「完全に理解した」を繰り返しながらプロダクト開発をするんだと思います。
こういう手法がよかったよ、こういうステークホルダーの巻き込み方をしたらうまくいった。など、他のPMがどんな取り組みをしているのか知りたいのでぜひ記事などを通して教えていただけると嬉しいです🙏
この記事が気に入ったらサポートをしてみませんか？