【第6回】解決策はどうやって生まれるのか – 仮説ドリブンな考え方
- はじめに
- 解決策はひらめきだけではない
- 解決策とは因果の仮説
- よくある失敗 – 解決策が問題を飛び越える
- 仮説ドリブンの基本形
- MVPの誤解
- 全部つくらない
- 解決策は複数あっていい
- 解決策を決断に変える
- 解決策を出すときのチェックリスト
- PdMの仕事は仮説を当てることではない
- まとめ
はじめに
ディスカバリーフェーズでは、必ずこの瞬間がやってきます。
「で、結局何をつくるんですか？」
ここで焦ってアイデアを出すながれになると、それまで丁寧に積み上げた理解が崩れてしまうことがあります。
PdMの仕事は、良さそうなアイデアを出すことではありません。検証可能な仮説として解決策を定義することです。
解決策はひらめきだけではない
PdMは正解の機能を思いつく人だと思われることもあります。
ですが実際は、良い解決策というのは、問題理解の延長線上に生まれます。
解決策とは因果の仮説
PdMが扱う解決策は、こう定義できます。
「もし〇〇をすれば、△△なユーザーの□□という問題が、××な理由で改善するはずだ」
ここには、次の内容が含まれています。
- 行動（何をするか）
- 対象（誰に）
- 変化（何がどう変わるか）
- 理由（なぜそうなるか）
よくある失敗 – 解決策が問題を飛び越える
「この画面を追加する」「ワンクリックにする」「AIで自動化する」。
これらは手段であって、仮説になっていません。
それはどの問題に効くのか？を考える必要があります。
仮説ドリブンの基本形
仮説
「〇〇なユーザーは、△△な状況で□□に困っている。そのため、××を提供すれば、◇◇という行動変化が起きるはずだ」
この形で書けない解決策は、まだ考えきれていません。
MVPの誤解
MVPは、「最小の機能セット」「とりあえず出すもの」だと思われやすいです。
本来のMVP
MVPとは、仮説を検証するための、最小限の実験です。
はやくつくるためではなく、学ぶために小さくするという考え方です。
全部つくらない
仮説ドリブンで考えると、自然とこうなります。
まず一部だけつくる。完璧を目指さず、結果を見て次を決める。
これは、妥協するということではなく、不確実性に対する最も合理的な態度です。
解決策は複数あっていい
解決策は一つに絞らなくていいし、最初から正解を選ばなくても問題ありません。
PdMがやるべきなのは、選択肢を出すこと、比較できる形にすることです。
比較の軸
最低限、次の軸で見るようにします。
- 問題に効きそうか
- 検証しやすいか
- コストはどれくらいか
- 失敗した時に学びがあるか
解決策を決断に変える
仮説が明確で、比較軸も明確。リスクが言語化されている。この状態をつくれば、意思決定に大きく貢献できます。
解決策を出すときのチェックリスト
実務で使える簡単なチェックです。
⬜︎ どの問題に効くか言えるか？
⬜︎ なぜ効くと思うか説明できるか？
⬜︎ 効いたかどうか、どう測るか？
⬜︎ 失敗したら何を学ぶか？
一つでも曖昧なら、まだ仮説になっていません。
PdMの仕事は仮説を当てることではない
PdMの仕事は仮説を当てることではありません。学習速度を最大化することです。
そのために、小さくつくってはやく出す。正直に振り返る。これが価値になります。
まとめ
✦ 学習を前提に決断する
✦ 解決策は仮説である
✦ 問題理解から飛ばない
✦ MVPは実験
✦ 解決策は複数持つ
【第1回】PdMとは？ プロジェクトマネージャーとの決定的な違い
【第2回】PdMの責任範囲と権限の考え方 – 権限がなくてもPdMはできる？
【第3回】 誰のどんな問題を解くのか言語化する – PdMの仕事はつくる前に8割決まる
【第4回】ユーザーインタビューの実践 – 「聞いたのに何も分からなかった」を避けるために
【第5回】数字が苦手なPdMのためのデータ思考 – KPIは管理ではなく仮説検証の道具
【第6回】解決策はどうやって生まれるのか – 仮説ドリブンな考え方
