プロダクトマネージャーが責任を持つのはアウトプットではなく、アウトカムです。機能（アウトプット）を作って終わりではありません。「インタビューでユーザーが言っていたから」という理由だけでプロダクトに機能を付け加えるのもいけません。ユーザーの言いなりになるのではなく、ユーザーの期待を超えていく姿勢を持ちましょう！

このnoteの結論

このnoteは、アウトカムとアウトプットの紐付けが難しいのであれば、OKRとNSMを活用してアウトカムを定義して、間にIssue Listを挟んでアウトプットの検討をするのがいかがでしょうか？という提案をするnoteです。

■ このnoteで解決できるかもしれない課題
・プロダクトが解決すべきIssueが多すぎて優先順位付がむずかしい
・PBL(=プロダクトバックログ)の優先順位に納得感がない、または、PBLに入っているアイテムに納得感がない
・抽象的なプロダクトのアウトカムを、どのように具体的な施策に反映させていけばいいか分からない、OKRが形骸化したお気持ち表明になっている

アウトカムを行動に落とし込む

アウトカムとは、結果です。アウトプットをつくるのは、すべてアウトカムのためです。プロダクトのアウトカムを定義して計測するツールとなるのはOKRとNorth Star Metric（NSM）です。NSMの詳細は別noteとしますが、NSMとはプロダクトのNorth Star（= 北極星）となる指標を定め、この数値を向上させることを目的にプロダクトを改善する手法です。このNSMを頂点にKPIツリーを組み立てて、目標に対してどれくらいの進捗を達成しているのかを測定します。

OKRとKPI(NSM)の関係について

OKRとKPI(NSM)は、どちらも目標を設定し達成度合いを計測するツールであり、目的に重複するところはあります。しかし、そのどちらか単体だけで機能するものではないと考えています。明日何をするかを発想するためのOKRと、その結果を測定し目標との差分とその原因を知り、次のOKRを検討するツールとしてのKPI(NSM)という、鶏と卵の関係であるとも言えます。

また、各KRは必ずNorth Starとして設定した数値を向上させるような施策でなければいけません。

KRsとIssue List

本来、OKRがうまく仕事をしていれば、このIssue Listは不要であるのかもしれません。しかし、私はIssue Listをつくります。Issue Listとは、各KRに紐づく（ときに紐付かない場合はきっとOKRの設計が誤っている）Objectiveの達成の障害となっている要因です。

Issue Listの例
・オンボーディング時にユーザーがプロダクトのルールを理解できるようにする
・LTVがXXXを上回る
・チームの中で、お互いの責任範囲がわかるようにする

これは、プロダクトマネージャーのバックログと言い換えてもいいかもしれません。このリストはPBL(=プロダクトバックログ)と同様に上から優先順位がついており、上にあるものほど粒度が小さくなっていると理想です。OKRのアップデートのタイミングでは、このリストの優先順位を変更します。

ところで、Issue Listという名前をつけながら、ネガティブな表現よりポジティブな表現で書く方が私は好みです。ネガティブなリストを見るのは心が辛くなります。

🙅 ネガティブ
→ オンボーディング時にユーザーがプロダクトのルールを理解できていない
🙆 ポジティブ
→ オンボーディング時にユーザーがプロダクトのルールを理解できるようにする

なぜ、私がOKRとは別にIssueを管理するかというと、このリストは四半期ごとどころか日々追加、優先順位変更、削除があるからです。プロダクトをつくることは仮説検証であり、KRを達成するために本当にそのIssueが根源であるのかどうかはやってみなければわかりません。KRを見失わず、KRの達成に最も貢献するIssueを選び解決する作業を大切にします。

Issue ListとPBL(=プロダクトバックログ)

このIssue Listに紐付いてPBLを発想します。つまり、OKRが変更になって、Issue Listの優先順位が変わったときにはPBL内の順番も大きく変更になります。

また、Issueの解決策はコードを書くことだけではないので、IssueによってはPBLに紐付かずにマーケティング施策を実施して解決することもあるでしょう。Issue Listを作っておけば、何でもかんでもコードを書いて解決しようとしてしまう発想から抜け出すこともできます。

「インタビューでユーザーが言っていた」その機能をPBLにいれるかどうかもこの図で判断しましょう。それは、今抱えているどのIssueに対する対応策でしょうか？優先順位は本当に高いでしょうか？KRやNSMの達成に貢献しますか？もっと貢献する自社の強みを活用した別の解決策はないでしょうか？

いつのまにか、プロダクトに足を生やして以下の絵のようにならないように、プロダクトのWhyをつくっていきましょう💪

(図)プロダクトのCoreやWhyがない例: 蛇足のダソくん

あとがき

「仮説のミルフィーユ（下図）は分かったけれど、具体的にどうやって管理すれば良いですか？」という質問をよく頂くのでその回答として書きました。しかしながら、私自身もこの座組で多くのプロダクトを育てた経験がなく、まだ実験中でもあるのでぜひみなさんの仮説の管理方法も教えていただけたら幸いです。