プロダクトマネージャーの思考整理術
この記事はProduct Manager Advent Calendar 2019の15日目の記事です。
久津（@Nunerm）です。CAMPFIREでプロダクトマネージャーをやっていて、CAMPFIRE Ownersという融資型クラウドファンディングのサービスを担当しています。
今日は自分が実践してる「プロダクトマネージャーの思考整理」に関する話を書きます。日々忙しいプロダクトマネージャーの頭の中のデフラグの手助けになれば幸いです。
プロダクトマネージャーには考えることがたくさん
このアドベントカレンダーでも度々引用されている「INSPIRED第２版」では、プロダクトマネージャーの責任を
可能性を評価し、何を作って顧客に届けるのかを判断することだ。
（INSPIRED第２版より引用）
と定義しています。
「可能性を評価する」「何を作って届けるか判断する」と簡単に書いてありますが、実際にこれをやるためには、マーケットの状況を見極めつつプロダクト開発の方針を決め、実際に数字を見ながら細かい機能改善に関する意思決定をしていく、といったような多様な活動が求められます。つまりマーケットのことを考えたりプロダクトのことを考えたり、また抽象的なことを考えたり具体的なことを考えたりと、プロダクトマネージャーは考えて判断する「対象」と「抽象度/具体度」の種類が多種多様なのです。
自分は新規事業を担当しており、今年の９月にローンチしたばかりなので、まだまだ検証し切れていない仮説だらけで具体的な課題が次から次へと生まれてきます。またチームメンバーもまだ少ないので、自ら手を動かすタスクがたくさんあります。そんな状況だとどうしても目の前の課題に集中してしまい、視野が狭くなってしまうことがあります。認知やCVRを上げるための打ち手を考えるとか、新機能のPRD書くとか「具体的なタスク」で頭の大半のリソースを使ってしまいます。
そんなタイミングで経営陣から「マーケットの様子が変わってきたけどどう考えてる？」と聞かれると、「へ？」と何も答えを用意できず「あ、ああ…もちろん良い感じに考えてますよ」と上擦った声で見栄を張り、直後に慌てて考え始めてみると、今の目の前の課題がそんなに重要でないと気づく始末。これはイケてない。
プロダクトマネージャーたるもの、常に思考を張り巡らせておかなければなりません。
続きを読む人は自分に必要なものが何だかわからない
iPhoneのケースが壊れたので新しいケースを買った。
自分に必要なケースの要件は以下２つ。ちなみに壊れたやつも同じ要件だった。
・手がそんなに大きくないのでリング必須
・片手でスッと出して使いたいので手帳型はNG
というわけでこれを買った。
ちなみに壊れたのはこれ。ほとんど同じ。
よっしゃー使うぜ…と思ったらなんか使いづらい。
前みたいにポケットからサッと出してスッと構えるエレガントが立ち振る舞いができず、モタモタしてしまう。
原因がわかった。
右手で持ってリングに指を入れる場合、一番ベストな角度は大体45度である。つまりリングを45度の角度に回さないといけない。
↓こんな感じ
新しいやつは
①起こす
②回す
この順番でしか45度の角度に回せない。
これやってみるとわかるが、片手ではなかなか難しい。つまりスマホをポケットから出す度に両手を使わないといけない。
まあまあめんどくさい…(´；ω；｀)
壊れたやつは起こす前に角度をつけられる仕様だった。
なので動作は「起こす」だけであり、片手で十分。
同じ機能のケースを買ったつもりでも、この微妙な違いがかなりのユーザビリティの差を生み出していた。
何が言いたいかというと、
人は自分に必要なものが何だかわからない
ということ。
毎日使っているiPhoneのケースでさえ、無くなってから初めて気づく「要件」がある。頭では要件を全て抑えているつもりでも、意識していない必要な機能がある。
プロダクトマネジメントをする際もユーザーにアンケートやインタビューで「どんな機能が欲しいですか？」「使いづらいところはどこですか？」とか聞いてしまいがちだが、それは暗黙のうちに「ユーザーは何が必要か理解している」という前提に立ってしまっている。
ユーザーに聞くのではなく、ユーザーがどういう使い方をしているのか、煩わしい手順は何か、解決したい問題の手段はこれが最適なのか、などをインタビューや観察によって見極めることが求められる。特に無意識に感じていることはインタビューで顕在化しないので注意が必要だ。じっくりユーザーと向き合って見極めないといけない。
今回のiPhoneケースの場合も自分で選ぶのではなく、誰かに自分の使い方をじっくり観察してもらって選んでもらうのがよかったかもしれない（そんなことしてくれる人いないけど）。
つまり「ユーザーが求めているもの」ではなく「ユーザーが解決したいこと」にフォーカスを当てて、プロダクトに反映していくべし。
そうです。ジョブ理論を読みましょう。
こちらは以前まとめたスライド（一部レイアウト崩れてます）
最後にフォード大先生の名言を。
引用元：http://blog.etn.co.jp/english-henryford/1429.html
「もし人々に何がほしいかと聞いていたら、彼らはもっと速い馬がほしいと答えていただろう。」
以上、日々の些細な出来事からの気づきでした。
プロダクトマネージャーに必要な３つのもの 〜Produce Manager Conference 2019より〜
今年もプロダクトマネージャーの祭典"Product Manager Conference 2019"が開催されました。
参加者としてはほぼ皆勤賞ではあるのですが、今回は初めて運営メンバーとして関わらせていただき、こちらのセッションではモデレーターも務めさせていただきました。
諸事情によりこちらのセッションの内容はSNSシェアNGなので「めっちゃ緊張した」「登壇者のお二人の熱量が凄くて時間が足りなかった」と振り返るだけに留めて、ここからは２日間のセッションから得た学びを振り返ります。
全てのセッションを聞いたわけではないですが、「PMに必要なもの」に共通点があるような気がしたので、「３つのポイント」としてまとめました。
- 1.突破力
- 2.信頼
- 3.考え抜く力
- 余談：初めて運営側に回ってみて
続きを読む
不確実性の高い変数が２つ以上あったら、数字のことを考えるのをやめる
プロダクトマネージャーたるもの、プロダクトロードマップやOKR、KPIツリーなど「目指すべき数字」を定義する（または修正する）時間はそれなりに多いと思います。
会社によってはゴリゴリに数字を定義して一心不乱にその数字の達成を追い求めるところもあるでしょうし、ある程度定性的な目標を定めるところもあるでしょう。それはプロダクトのフェーズや市場によって変わってきます。
私事ですが、先日CAMPFIREに転職して半年間手がけてプロダクトがついにリリースされました。
ついに手掛けてたプロダクトがリリースされました！
— 久津佑介(HisatsuYusuke)🔥プロダクトマネージャー (@Nunerm) September 11, 2019
ようやくスタートライン。これから磨いていきます！ https://t.co/mLW7O2eg4C
つまり今新規事業のプロダクトマネージャーをやっておるのです。
この新規事業における「目指すべき数字」の定義が非常に難しい…！
なぜなら数字の根拠となるデータが少ないので。
もちろん他サービスやユーザーインタビューなどからデータを得ることはできます。が、それが自分のプロダクトに適用した際に同じ結果になるとは限りません。
つまりそこに不確実性が存在しています。
その高い不確実性をどう評価するか、楽観的に考えるか悲観的に考えるかで数字は大きく変わってしまいます。その不確実な要素を不確実なまま立てた数字目標は、現実的な目標ではなくただの「願望」であり、そんな状態で数字目標の妥当性を検討している時間は無駄だと思うのです。
つまり言いたいのは、
「数字目標を構成する要素に不確実性の高いものが２つ以上あったら、一旦考えるのをやめようぜ」
ということです。
特に２つという数字に大きな理由はないです。１つだったらその変数の楽観パターンと悲観パターンの２パターンを想定しておけばよいが、２つになったら２×２で４パターンを想定する必要あり、どんどん考えることが増えていくので、早めに考えるのをやめたいのです。
ではどうするのか？
検証をするのです。
先日参加したDevLOVEのイベントにて、書籍「カイゼンジャーニー」や「正しいものを正しくつくる」の著者の市谷さんの登壇を聞いて、非常に参考になりました。
ここでは主にプロダクトの立ち上がり期に起こりがちな失敗パターンをまとめてくれています。
いくつか抜粋。
想像だけで始めてしまう
- プロダクトを作るという意思決定が終わっているが根拠がない
- ユーザーのことを知っているという思い込みで作り始めてしまう
体験の検証をやっていない
- モックアップとかで検証をしたけどまだ実際に深く使われていない
- 想定ユーザーの利用体験を成り立たせることができるのか、検証しないまま進めてしまう
チャネル検証をやっていない
- 開発が終わってからチャネルの検討を始めがち（結局広告頼み）
- 後になって「届けるコスト」が現実的ではないことに気づく
検証結果を都合よく解釈してしまう
- 自分の見方にバイアスがあることに気づいていない
- 解釈は正しいがデータが誤っている場合もある
事業を始めてしまう
- わかりやすい動くものができると関係者の期待が高まり「どうやって売るか、どうやって売れるか」の議論と活動が始まってしまう（検証が終わってないのに）
- モデルの検証のはずなのにビジネス自体が始まってしまう
世の中の理論を鵜呑みにする
- 世の中の理論を自分の事業に適用してしまう
- 世の中の理論が根拠としている事例や状況が当てはまるとは限らない
つまり検証を行わずに、あるいは検証結果を正しく評価せずに具体的な数字ばかり追い求めてると、高い不確実性を伴ったまま成長に挑むことになります。それはかなりのリスクです。
要は「なぜうまくいってるのか正しく理解していない」ので、いずれ「なぜかわからないがうまくいかなくなった」という事態に陥っても不思議ではありません。
今何の不確実性が高いのかを正しく把握し、それに向けての検証を的確に行うことで不確実性を下げるが求められるのです（不確実性をゼロにすることは不可能です）。
それまでは具体的な数字目標は一旦忘れてよいと思います。検証後に改めて考えればより良い現実的な目標が立てられるので。
というわけで、私のプロダクトもリリースしたところなので、これからバシバシ検証していきます。
ざっくり解説 → "Practical Lessons from my Experience in Product"
こちらの「プロダクトマネジメントに関する教訓」の記事がPM界隈で少し話題になってます。
これに関して、とある日に会社のメンバーから
というおねだりをもらいました。英語苦手なのに…
というわけで、せっかくだから解読した結果をここにまとめます。そのまま翻訳するのは許可が必要な気がするので、あくまで自分の解釈と意見を書く形にしました。（間違ってたらごめんなさい）
1.MVPはユーザーセグメントを絞って作るべし
1.Being Minimalistic- Identify a target user base don’t be greedy for every possible user segment. Segments are not just demographics but can be a mobile user, a desktop user, a college student or just people in a specific timezone. Minimalism is not just on user selection, try developing MVP and extend the minimalism to day to day work. Do your homework right.
これはこの図を見るだけで十分な気もしますが、全てのリーチ可能なユーザーセグメントをターゲットにするMVPを作ると多機能になり、結局"Functional"な部分の検証しかできなくなります。ターゲットとするユーザーセグメントを絞り、その中で本質的に検証すべきことを検証できる必要最低限のMVPを作るべきということです。
元記事より引用
続きを読む
プロジェクトマネジメントとは「基準を作ること」である
久津（@Nunerm）です。
今回はプロダクトマネジメント（以下PdM）ではなくプロジェクトマネジメント（以下PjM）の話を書きます。
PjMにおいて大事なのは「基準を作ること」だという話です。
余談：PdMとPjM
いきなり余談ですが、よく「プロダクトマネジメントとプロジェクトマネジメントは違う」という話をよく聞きます。（違いについてはこちらの超わかりやすい記事にお任せします。）
元々プロジェクトマネージャーをやり、その後プロダクトマネージャーにシフトした自分としては、PdMとPjMの「どちらか」ではなく、両方できる人が強いと思ってます。PjMはプロジェクトのリスクを減らし効率的に進めるための武器なので、プロダクトマネージャーにとってはプロダクトが達成したい世界への最善の道筋を見つけることに役立ちます。逆にPdMの視点を持っているプロジェクトマネージャーは、事業戦略や優先度を把握しているのでステークホルダーとの調整などで役立ちます。
ただし自分がどっちを主軸にしているのかは明確にしておかなくてはいけません。例えば、「リスクが高いけどプロダクトの成長に大きく寄与する施策」の実行可否を検討している場合、PjMの立場だとリスクヘッジを重視するので、成長度合いを下げてでも失敗しない方法を選ぶ力学が働きますが、PdMの立場だとプロダクトの成長第一なので、成長度合いを最大限にするべくチャレンジする力学が働きます。
これを一人の人格がやってしまうと中途半端な成果しか出なくなりますし、周りのメンバーから見ると「いつも判断軸がぶれている」と思われてしまいます。なのでPdMとPjMを完全に別の人間がやり、双方にチェックし合う関係ができるのが理想ですが、組織の都合上難しい場合は、片方の役割を主軸とし、あくまで補助としてもう片方の知識を活用する意識が必要だと思います。
続きを読む
UX DAYS TOKYO 2019 カンファレンスレポート（ユーザーオンボーディング・行動経済学）
4/5（金）にUX DAYS TOKYO 2019のカンファレンスに参加してきました。本イベントは、海外の一流のスピーカーがUXをテーマとした講演やワークショップを行う、年１回のイベントです。
というわけで、個人的に面白かった２つの講演をざっとレポートします。
※まるで自分の主張のように書いてますが、講演内容を要約しただけですのであしからず。
継続的ユーザーオンボーディング by Krystal Higgins
Googleの「シニアユーザーエクスペリエンスデザイナー」の肩書を持つKrystal Higgins氏より、サービスにおけるユーザーオンボーディングのゴールとプロセスについての講演です。
３行でまとめると…
- ユーザーオンボーディングは"first run"を支援するものではなく、長期間にわたって定着してもらうための取り組みである
- カスタマージャーニーに合わせてオンボーディングをデザインする
- 様々なオンボーディング施策は行いつつも「まとまり感」を保つ
