プロダクトマネージャーが施策を成功させる「10の質問」
こんにちは！ Pairsでプロダクトマネージャーを担当している金田です。
今回はプロダクトマネージャーが施策を成功に導くために利用している「10個の基本的な質問」というフレームワークについてご紹介します。
目次
- プロダクトマネージャーとは？
- 「10個の基本的な質問」とは？
- 「10個の基本的な質問」導入の背景
- 最後に
プロダクトマネージャーとは
そもそもプロダクトマネージャーという職種を聞き慣れない方もいると思うので簡単に説明します。
プロダクトマネージャーとは、プロダクト・施策を通してビジネスを成功に導く存在です。
具体的な業務は、「開発前の要件定義」、「開発中の要件調整・品質保証」、「開発後の効果測定」という3つの仕事に分けられます。
これらの業務を通して、本当に価値のあるプロダクト・施策だけを的確なタイミングでユーザーに届けるのが私たちの役割です。
これからご紹介するフレームワークは、最初のフェーズである開発前に、「本当にプロダクトを作るべきか？、施策を打つべきか？」を考えるために使います。
「10個の基本的な質問」とは？
「10個の基本的な質問」とは以下の質問のことです。
1. 製品化によって具体的にどんな問題を解決するのか？
2. 誰のためにこの問題を解決しようとしているのか？
3. 市場の大きさは？
4. 製品化の成功をどうやって評価するのか？
5. 現在、他に競合する製品はあるのか？
6. なぜ当社がこの製品化をやるのに最適なプレイヤーといえるのか？
7. なぜ今なのか？
8. どうやって製品を市場に送り出すのか？
9. 成功のために絶対必要な要素は何か？
10. これらを前提とした上で最終的な提案は何か？（やるかやらないか？）
このフレームワークはマーティ・ケイガン 『Inspired: 顧客の心を捉える製品の創り方』 で紹介されているものです。
プロダクトマネージャーが「そのプロダクトが本当にプロダクトを成長させるかどうか」問うために活用するとだけ説明されており、実際の活用イメージまでは載っていません。
ここでは実際に普段、私がどのように使っているか説明したいと思います。
「10個の基本的な質問」を使ってみる
利用目的
今、ある施策ないしはプロダクトを作って世に出したいと考えているとします。
- 要件はざっくりしていて、どう詰めたらいいか分からない
- ないしはすでに詰まっているがビジネスとして価値があるか頭の中が整理できていない
そのような際に、「この施策をやるべきかどうか」 と 「実際に進めるに当って考える必要がある部分はどこか」 を教えてくれます。
質問1と2：問題の明確化
プロダクトを作って世に出したり、既存のプロダクトで施策を打つ場合、
誰かが抱えてる問題を解決するという明確な目的がないと確実に失敗に終わります。
この２つの質問は、その解決したい問題を明らかにするために使う、最も重要な質問です。
1. 製品化によって具体的にどんな問題を解決するのか？
2. 誰のためにこの問題を解決しようとしているのか？
例えば、「早く移動できる馬が欲しい！」というユーザーの意見があったとします。
この際、「早く移動できる馬がない」ことが問題ではなくて「早く移動できない」ということが問題に見えます。
また、実際にスピードが問題なのか、それとも道路の混雑状況が問題なのかによって最適な解決方法は異なります。
この質問に対する回答をクリアにするために、最初に出てきた回答から更に2〜4回（全部で合計3〜5回）「なぜ？」を繰り返すことをオススメします。
「早く移動できる馬が欲しい！」
↓
「早く移動したい！」
↓
「仕事帰りに早く子供に会いに行きたい」
↓
「少しでも多くの時間、子供と会って話をしたい」
どうやらこの方は、早く移動できる手段や渋滞を回避できる手段を求めているのではなく、お子さんといつでもコミュニケーションが取れる手段を求めていたと分かりましたね。
このなぜ？の後の仮説は、時にユーザーに直接インタビューをしたり、データを元に検証していくことも重要です。
また、質問2の「誰のためにこの問題を解決しようとしているのか？」という質問ですが一見すると「性別や年代」といった属性と考えがちです。
私も最初はそのように考え利用していたのですが、実際はユーザーの置かれている「状況」や今まで取ってきた「行動」が重要だと分かりました。
例えば、あるECサイトにおいてユーザーが購入した商品を見返したいというニーズのために「購入履歴」という機能を導入したいと考えたとします。
この機能は、特定の年代、特定の性別の方が欲しているから導入するのでしょうか？
そうではなく、商品を購入したという「行動」と、商品の発送を待っているという「状況」で発生するニーズのはずです。
この質問は、「どんな行動を取った、あるいはどんな状況に置かれたユーザーに向けての問題解決か？」と解釈し直すことができます。
質問3と4：製品の市場性評価
3. 市場の大きさは？
4. 製品化の成功をどうやって評価するのか？
これらの質問は、そのプロダクト、あるいは施策が市場でどれくらいインパクトを発揮するのか図るための質問です。
質問3については、新規のプロダクトであれば狙っている市場の大きさと獲得できるユーザー規模から得られる収益になりますし、
先ほどのECサイトの「購入履歴」の例であれば、元々買ってくれているユーザーがまた購入してくれる割合がどれだけ増えるか、購入経験はないが続けて利用してくれているユーザーがどれだけ新規で購入をしてくれるか、あるいはこの機能の導入で競合他社のサービスからどれだけの割合乗り換えてくれるか、といった観点でインパクトを測定します。
質問4は3の効果を量るための具体的なKPIを設定します。
売上から分解し、どのKPIがどれだけ上がれば施策として成功なのかきっちり決めておくための質問です。
質問5と6：競合と自社
5. 現在、他に競合する製品はあるのか？
6. なぜ当社がこの製品化をやるのに最適なプレイヤーといえるのか？
これらの質問は競合の存在と、そこから明らかになる自社製品の戦略を明らかにするための質問です。
質問5は、いわゆる3C分析の「Competitor」の存在を規定するために利用しています。
特に新規のサービスの場合、参入市場に強力なプレイヤーがいれば、その存在は押さえておかなければ負ける可能性も存在します。
普段の施策レベルでも、競合他社製品がどんなソリューションを提供しているか確認しておくとよいでしょう。
先のECサイトの「購入履歴」の場合、他ECサイトの「購入履歴」を確認してどんなソリューションを提供しているかインプットしておくと、
その後の施策の質が上がるので押さえておく必要があります。
質問6は、3C分析の「Company」に関する質問です。
新規サービスの場合、自社の強みと勝算はどこにあるのか、それをいかに製品に落としこむのか答える必要があります。
施策レベルでは、サービスのブランディングの観点で投入することが相応しいのか、いわゆる「そのサービスらしさ」が消えないかを確認するための質問です。
質問7と8：リリース戦略
7. なぜ今なのか？
8. どうやって製品を市場に送り出すのか？
質問7と8はリリースにふさわしいタイミングと具体的戦略を明確にするための質問です。
質問7は文字通り見れば、なぜ、このタイミングで投入するのか答える質問に見えますが、私の中では「他の施策（やらない施策）と比較した際になぜこの施策の優先度が高いのか」答える質問と認識しています。
例えば、商品購入率よりサービス自体のアクティベーションが低く、購入までつながらない状況においては「購入した商品を見返すことができない」問題より、「サービスに高いモチベーションを持って続けてくれない」問題の方が重要であると思えます。
つまり、今この施策を検討するにあたって、「その前段階の問題がクリアできているのか」といった質問に答える必要があると考えています。
質問7はこれに対する質問と捉えています。
この問題に明確に答えるためには、常に施策のロードマップとバックログの優先度をきっちり管理するようにしましょう。
ロードマップやバックログの優先度管理については、また別途お話できればと思います。
質問8は、文字通りどうやってリリースするかです。
私が回答するときには、いつもリリースする際にA/Bテストを駆使するとしたらその方法と具体的スケジュールまで記入をするようにしています。
質問9：絶対譲れない最低限の要件を定義する
9. 成功のために絶対必要な要素は何か？
質問9は見かけだけ見ると非常に難しい質問です。
今の私の中では、「製品化するのにあたってMVP（＝Minimum Valuable Product)として譲れない要素は何か」という質問に置き換えて解釈しています。
MVPとは、ある要件を満たす必要最小限の商品と呼ばれるプロダクトというもので、施策を成功させる（あるいは失敗したとしても次に活かせる）絶対譲れない要素を規定するものと考えています。
つまり、どれだけ要件は削っても、これだけは達成したい要素をここでは答えるようにしています。
「購入履歴」の例で言えば、
A. 購入した商品を見返せること
B. 見返すニーズの根源は、到着前の商品の発送状況を知りたいため、発送状況が分かる状態にすること
という様に、質問1で上げた問題の解決のために絶対譲れない要素を記載します（必要最低限にするため最大でも3つまでが良いです）
逆に譲ってもいい要素としては以下のことが挙げられそうです。
A. 購入した商品の画像を大きく見せること
B. 再購入のボタンを押すこと
このように絶対譲れないポイントを明確化・最低限化しておくことで開発メンバーとの認識の齟齬も減る上に、
本来やるべきことに集中していいプロダクトを作ることができるといったメリットもあります。
質問10：最終ジャッジ
10. これらを前提とした上で最終的な提案は何か？（やるかやらないか？）
以上を加味した上で、今やるべき施策か、やらないでおくか判断します。
私が一番判断の拠り所としているのは、質問1の問題の深掘りができているかですが
質問3、4の市場性があるかどうかもそろばんを弾いて試算をした結果止めた方がよいと思うこともあります。
「10個の基本的な質問」導入の背景
冒頭でもこのフレームワークが開発前の要件定義に使うとお伝えしましたが、
せっかく作った機能が価値を発揮せず終わり、エンジニア/デザイナーの苦労が水の泡に消えることもあり得えます。
このフレームワークが力を発揮するのは、本来解決すべき問題を明らかにするだけでなく、
どれだけビジネスインパクトがあるかといった市場性まで綿密に計算させられる点にあります。
ここまで考えておくことで、エンジニアリングメンバーの努力を無駄にせず、彼らを迷わせず施策を成功へと導ける可能性が高まると考えています。
最後に
フレームワークは誰が書いても、ある程度同じ精度まで上がるというメリットがあります。
ですが、本当にいいプロダクト・施策を作るのはセンス、つまりプロダクトを届けたい相手の気持ちを掴む能力が重要です。
そのためには、サービスを触るのはもちろんのこと、どれだけ「人間」について考えているかが勝負だと思っています。
日頃多くのサービスを触ってセンスを養いながら、このフレームワークを使ってサービスを成長させていきましょう。
またこのフレームワーク自体、実用例が少なく、私もまだまだ実験導入中の段階です。
ぜひ色々な意見を聞かせていただけると幸いです！
