[Tably] #pmconf2020 で頂いた質問の回答
こんにちは、Tablyの小城(@ozyozyo) です。
大変お待たせいたしました。プロダクトマネージャーカンファレンス2020で私のセッション後のAskTheSpeakerで頂いていた質問にお答えします。
仮説検証のご質問
Q. エンプラB2BSaaSやっています。仮説検証重要だと思ってかなり密にやっているのですが、仮説検証の管理（できたもの、まだできてないものなど）って、どのようにやっているとかありますか？Tipsあったら教えてください！
まず、「仮説の因果関係」を明らかにするために、セッションでもご説明した仮説のミルフィーユをぜひご活用ください。この仮説のミルフィーユの4階層で仮説を管理し、どの仮説がどの仮説に紐付いているのかを明らかにしておくことで1つの仮説検証の効果を最大化することができます。
そして、その仮説の関係を示し、プロダクトのCoreからWhatを俯瞰するためにはリーンキャンバスが便利です。リーンキャンバスにすべての仮説を書き出し、未検証の仮説には色を塗っておくなどで管理しておくと、プロダクトの全体像を把握することができます。
また、リーンキャンバスとプロダクトのCoreからWhatの関係は以下のような図に表されます。
リーンキャンバスのTipsはこちらも是非ご確認下さい。
優先度のご質問
Q. 本日は、ありがとうございました。優先度（指標とロードマップ）がWhatにありましたが、具体的に、指標やロードマップを検討・整合していくためのTipsなどあれば、教えていただきたいです。例えば、プロダクトマネージャとエンジニア側のリードと優先順位のチグハグがおきないようにするためのTipsなど。
Q. 優先度の指標をどう決めてチーム内でコンセンサスを取るのかが、知りたいです
チームで同じ方向を向くためには、共通の指標を持つことがまず大切だと思います。
そして、その指標はいわゆる「収益」のような最終的な遅行指標ではなく、プロダクトの成功の３要素すべての先行指標になるような指標がよりよいでしょう。このような指標をNorth Star Metricといいます。
North Star Metricの作り方は別のnoteにてご紹介しておりますので、もしよろしければこちらもご確認ください。
また、この指標の根拠となるプロダクトのCoreやWhyの認識を合わせて置くことも重要です。そのために有効なアクティビティとしては「インセプションデッキ」があります。インセプションデッキについてはこちらの書籍が丁寧に解説をされているので、ぜひご参考ください。
既存機能のCoreがない
Q. 既に作られたプロダクトを担当することになったがCoreの検討が不足している状態です。とはいえ、機能追加を止めては競合との勝負で投資回収が難しく。
ご質問ありがとうございます。少し厳しい回答をしてしまいます。
セッション中でもこの魚の絵を紹介しました。プロダクトのCoreがないままに機能追加をしていると、各機能が必要な理由があったとしても、プロダクトが一気通貫しなくなります。
はじめは魚のイラストだったものが、より素敵なプロダクトにしていくために機能追加していった結果、何者か分からないものになってしまい、この1年後の状態となってしまえば、このあと何を実施すればよいのかもうわからない状態になってしまっています。
「競合で人気の格好良いひれ」を取り入れる前に、まずはプロダクトのCore、Why、Whatの検討をしてみることをお勧めします。その際にいきなりCoreに向かうのは難しいかもしれません。いきなり「ビジョンは何か？」を議論して空中戦になってしまう場合はプロダクトのWhyを固めて、「誰」を「どんな状態にしたいのか」、そして、「なぜ自社が実施するのか」を検討することから始めるのが良いかもしれません。
pmconf2019の登壇にて魚については詳しく紹介しているので、よろしければ昨年の記事もご参考ください。
PMになるために
Q. PMを目指すために、まずはこれ読んどけ！ みたいな書籍などご紹介いただけると嬉しいです。
「まずはこれ読んどけ！」と言わせていただけるような書籍を目指して、ただいま執筆中になります。
そちらの書籍の原稿を先出しでProductZineさまに連載しておりますので、書籍の出版まではこちらをご参考いただけますと幸いです。
「プロダクトマネジメントの基本を学ぼう」連載一覧https://codezine.jp/article/corner/816
以上となります。
回答に時間がかかってしまい大変申し訳ありませんでした。
何かご不明点などございましたら、お気軽にご連絡をお待ちしております。
▼▼▼お気軽にご連絡ください▼▼▼
koshiro@tably.rocks