失敗からの学び：プロダクトマネージャー(PdM)の最も重要な役割の一つ「課題仮説の質を高め、良いプロダクトを生む」ためのポイント
■はじめに＆自己紹介
この記事は "プロダクトマネージャー Advent Calendar 2020" の 3日目の記事です。
こんにちは！まっちゃん（@mas1s2）です。
まずは自己紹介です。
新卒でゲーム会社に入社。
そこから1年経たず事業部M&Aがあり、すぐに退職。
その後、人事関連のコンサルティング営業を経て、独学でエンジニアとして起業。現在は主に toCビジネスのプロダクトマネジャーをしています。
✔ プロダクトマネージャーとして、好きなこと/得意なこと
・プロダクトの成長戦略を思考して、事業成長させる
・データ分析を主軸に仮説精度をあげ、価値ある機能を生み出す
・エンジニアやデザイナーなどのチームでわいわい楽しく仕事する
今回は、僕が2020年に苦労し、成長できた点について、1年前の自分に向けて、「こんなことを学んだよ！」とメッセージを送りたいなと思います。
✔１年前の状態
・自分なりの「課題仮説」はあるが、効果ある施策が生み出せていない
・チームに課題仮説を伝えると「わかるような、わからないような」「本当に取り組むべきものなの？」と、共感が薄いまま開発を推進
■プロダクトマネジャーとして、まずは課題仮説を持つこと
このnoteが神なので、是非。
プロダクトマネジメントについて体系化されていて、課題仮説の重要性も非常に共感です。
~~~~以下記事から引用~~~~
「プロダクトを作ることは仮説検証だ」と言っても過言ではありません。1つ機能を作るときには、それは「どんなユーザー」の「どんな課題」を解決するのかという仮説や、「課題」を「その解決策」で解決できるに違いないという仮説がなければいけません。つまり、当たり前のことですが、なんとなく競合で人気になった機能を取り入れることは避けなければなりません。
チェックリスト③
✔ 自分の仮説を持っているか？
✔ 今検証しようとしている仮説は何か、全員が言えるか？
✔ 検証できている仮説・できていない仮説が管理されているか？
~~~~~~~~~~~~~~~~
とあるように、まずは自分で仮説を持ち、常に検証していく姿勢が重要です。
まずは、課題仮説を持つことから始めましょう。
ただ、仮説にも「良い仮説」と「悪い仮説」があります。
悪い仮説を排除し、良い仮説へ昇華させることがプロダクトマネジャーの大きな役割ですが、それが掴みきれず苦しんだ1年でもありました。
■良い課題仮説を持てずに、うまくいかない日々
実例：仮説なくデータ分析し、データの海に溺れ時間だけ経過する日々
・いきなりSQLを書き始めて、結局何を検証したいんだっけ？がわからなくなる
・あれも！これも！と調べてる中で、仮説をどんどん追加し。。。気づけば、仮説がないデータを見てしまっている
良い課題仮説なくデータ分析をすすめるとデータ量が多すぎて、もう何をやっているのか、自分でもわからなくなってしまいました。
学びは、まずは仮説を持つこと。
仮説なしには、クエリ書かない、データを見ない。
データを見るときは、明確な目的/仮説を持って、その目的のみデータを見るようになりました。
実例：データを見ても、「で、その結果どうするの？」状態
・仮説をたてて、データを見たが「で、それはどうすればよいの？何に生かすの？」という状態
・分析結果を共有すると、「ふーん」と言われる
例えばECで言えば
・xxという属性の人は、購入率が高いことがわかりました
・カートで離脱していることがわりました
とか。
これらの仮説って、わかったところで「じゃあ、どうやって解決するの？」まで繋がりません。
検証してから、「本来検証に至らない荒い仮説であるが」気づくことが多かったです。
学びは、施策につながるまで仮説課題を詳細化した上で、仮説検証することが重要だと学びました。
実例：課題仮説をチームに話しても、共感が得られない
・仮説を話すと「言ってることはわかる」と言われる
・ペルソナが定まっていないため、ターゲットがバラバラ
・カスタマージャーニーが想像できていないため、利用前後を踏まえて課題を抽出できていない
課題仮説を理解はしてもらえるが、リアリティがない状態。
言っていることは間違っていないが、そんな薄っぺらいユーザーが全くいないという仮説でした。
自己流で深堀りをしていましたが、ユーザーデザインの手法を学び、深堀りをすることで、ユーザー像をありありと描くことができました。
大事なのは自分自身が「このユーザー絶対にいる！！」と言い切れるくらいリアリティ/生々しさをもって考え抜くことが重要だと学びました。
■よい課題/仮説の３つのポイント
■■ポイント１：「誰の」「何の課題か」を生々しく描く
僕たちが普段対峙しているユーザー１人１人の声は、とても生々しいものです。
ユーザーからのお問い合わせやTwitterなど、できる限りユーザーの声を拾ってみてください。
例えば、単なる１つの購入出会っても様々なストーリーがあり、思いがあり、とても魅了されます。
そんな１人１人の生々しい声を積み重ねたときの共通項が課題として抽出されているはずです。
課題の後ろには、たくさんの生々しい体験があります。
その体験を紡ぐことで、その共通項である課題のリアリティーがまし、その結果チームにも共感される課題と昇華されます。
「こんな課題あるのかな？この課題は正しいか？」と思っているうちは、まだまだ生々しさが不足している証拠です。
自分が「これは真に課題だ」「こういうユーザーは絶対にいる」と自信が持つことができるレベルまで高めることが一つの指標になります。
✔実際にやったこと
・UXデザインの手法を改めて学び、実践してみる
UXリサーチ/UXデザインは非常に体系化されています。
ちゃんと取り組んだことがなかったですが、まずは学び＆実践してみることでユーザーのイメージが深まりました。
・ユーザーの声に触れれる機会を作る/増やす
実際に体験する/ユーザーのリアルな声を拾うこと。
手間ですが、これを地道に積み上げることが課題を見つける近道でした。
・自分は100%腹落ちするまで考える
なかなか自分が納得する/絶対にこれだ！と思うまで腹落ちするには時間がかかりました。
が、自分が納得しないことは周りを巻き込むことができません。
■■ポイント２：仮説を本当に取り組むべき課題に変換する
この記事も神なので、ぜひ。
※画像は記事から引用
プロダクトマネージャーは、チーム全員のリソースを本当に必要な箇所に投下、効果を最大化する責任があります。
上記の引用画像のように課題仮説を並列に取り扱い
優先度をつけて、優先度順にアプローチしてはいけません。
あまりに効果が限定的です。
・課題の中で、根本となる課題はなにか？
・大きなインパクトを生む課題はなにか？
を意識して、課題を捉えるようにしてました。
本当に取り組むべき課題に変換する３つのポイント
A:課題の抽象度を上げ下げをして深ぼる
課題をカテゴライズして、抽象と具体化を行き来きすることでで、本当の課題が見えてきます。
B:課題の因果を見つける
課題は因果関係となっていることが多いです。
なので、根本的な課題を見つけてアプローチすることが必要です。
C:AとBを自分で壊して、再度考える
AとBを繰り返しながら、いきなり良い仮説や良い課題構造にはなりませんでした。
なので、自分で作った課題構造を自分で壊す。
これを繰り返すことが最初はとても大事にしていました。
そして、もう一つ。
再構築する上で今もっている「当たり前を疑う」ということも効果的でした。
今当たり前と思っている点を見直すことで、大きな課題に気づくポイントです。
最後に、課題の見つけ方に正解はありません。
あくまで仮説なので、自分で仮説立てて、立てた仮説を自分で壊して再構築することで良い仮説を生み出していけるように少しずつなりました。
✔実際にやったこと
A: 課題の抽象度を上げ下げをして深ぼる
B: 課題の因果を見つける
C: AとBを自分で壊して、再度考える
■■ポイント３：ワクワクする大きな課題を設定し、最小限の検証をする。次はどうするか？を明確にして、伝える
プロダクトマネージャーは、できるだけインパクトの大きな課題に取り組むべきです。
できることなら、チームがワクワクできるような課題を設定することが重要です。
ただ、あれもこれも仮説を検証しようとすると、どんどんスコープが広がり、検証ポイントも曖昧になります。
なので、課題を最大に捉え、最小限で検証し、最終的にどんな世界がまってるのか？を伝えることです。
✔実際にやったこと
・インパクトの大きな課題を設定し、最小限の検証をする
・検証ステップを明確に示し、今の検証が最終的にどうなるのかを伝える
■最後に
プロダクトマネージャーとして、1年間苦労した「課題仮説の質を高める」方法でした。
ぜひ、参考になれば嬉しいです。
来年ももっとよいプロダクトを作りたいです。
■課題仮説を深堀る上で、参考になった書籍
・図示して、課題を捉える力
・UXデザインの方法論
・仮説の探し方/見つけ方