【第3回】 誰のどんな問題を解くのか言語化する – PdMの仕事はつくる前に8割決まる
- はじめに
- よくある失敗 – 機能から考えてしまう
- PdMは問題を扱う仕事
- 「誰の」をどう扱うかが重要
- 次に「どんな問題か」を掘り下げる
- 重要な問題と声が大きい問題は違う
- ペルソナに頼りすぎない
- 問題定義は仮説でいい
- PdMが最初につくるべき一文
- まとめ
はじめに
多くのプロダクトで、後からこんな会話が起きます。
「これ、誰のための機能だっけ？」「結局、何を解決したかったんだっけ？」このような疑問がでてくるときは、プロダクトは迷子になっているかもしれません。
PdMの最初で最大の仕事は、「誰の、どんな問題を解くのか」を曖昧にしないことです。
今回は、そのための考え方を整理します。
よくある失敗 – 機能から考えてしまう
「こんな機能が欲しい」「競合もやっている」「じゃあつくろう」というのは、現場で非常によく見るながれです。
この時点で、”誰のどんな問題なのか” は、ほぼ語られていません。
結果として、つくったけれど使われない、改善の方向性が定まらない、議論が好みの話になる、という状態に陥りやすいです。
PdMは問題を扱う仕事
PdMは、機能をつくる人ではなく、問題を定義する人です。
機能は手段であって、PdMの責任範囲はその一段上にあります。
「誰の」をどう扱うかが重要
誰の問題なのか？これが曖昧だと、後続の議論がうまくいきません。
「ユーザー全体」「みんなが困っている」「現場の声」。これらは一見それっぽいですが、意思決定には使えません。
最低限、言語化すべき「誰」
以下が言えない場合は、注意が必要です。職種や年齢よりも、状況と役割が重要です。
■ どんな立場の人か
■ どんな状況で使っているか
■ 何に責任を持っている人か
次に「どんな問題か」を掘り下げる
「誰」が定まったら、次は「問題」です。その人は、何に困っているのでしょうか？
ここでありがちな間違いは、解決策を問題だと思ってしまうことです。
「◯◯ができない」「△△機能がない」これはすでに解決策に近いです。
「問題」は、困りごと + 文脈
良い問題定義は、次のような形です。
「〇〇な状況で、△△しなければならないけれど、それがうまくできずに困っている」
この形に落とせると、解決策の幅が一気に広がります。
重要な問題と声が大きい問題は違う
声の大きさは、PdMを悩ませるポイントです。
営業が困っている。上司が気にしている。一部ユーザーが強く要望している。これらは無視できませんが、そのまま優先してよいとは限りません。
PdMが見るべき3つの観点
問題を評価する際、最低限見るべきは次の3つです。
| 頻度 | 深刻度 | 影響範囲 |
|---|---|---|
| どれくらい多く起きているか | 放置するとどれくらい困るか | 誰にどれくらい影響するか |
この整理があるだけで、感情的な議論から抜けることができます。
ペルソナに頼りすぎない
ペルソナは便利ですが、それ自体が目的になると危険です。
よくあるのは、詳細なペルソナがあるけれど意思決定は感覚、という状態です。これは、ペルソナが生きていない状態です。
ペルソナより大事な問い
PdMが繰り返し問うべきなのは、「この人は、今何を達成しようとしているのか？」ということです。
人の属性より、目的と制約に目を向けるようにします。
問題定義は仮説でいい
問題定義は、最初から正解である必要はありません。
むしろ、仮説として定義する → 検証する → 修正する、という前提がないと前に進みません。
PdMが最初につくるべき一文
実務でおすすめなのは、次の一文を必ず書くことです。
「〇〇なユーザーが、△△という状況で、□□に困っている」
これが書けない状態で、仕様を決めたり優先順位をつけるのは、かなり危険です。
まとめ
✦ PdMは機能ではなく問題を見る
✦「誰の」を具体化する
✦ 問題は文脈込みで定義する
✦ 声の大きさと重要度を分ける
✦ 問題定義は仮説でよい
【第1回】PdMとは？ プロジェクトマネージャーとの決定的な違い
【第2回】PdMの責任範囲と権限の考え方 – 権限がなくてもPdMはできる？
【第3回】 誰のどんな問題を解くのか言語化する – PdMの仕事はつくる前に8割決まる
【第4回】ユーザーインタビューの実践 – 「聞いたのに何も分からなかった」を避けるために
【第5回】数字が苦手なPdMのためのデータ思考 – KPIは管理ではなく仮説検証の道具
