Product Managers Night vol.1にモデレーターとして参加しました
先日、リクルートジョブズさん主催のProduct Managers Night vol.1に、パネルディスカッションのモデレーターとして参加させていただきました。 recruitjobs.connpass.com
50名の参加枠に150名以上の申し込みがあり、プロダクトマネジメントに対する関心の高さをひしひしと感じました。
登壇者はVASILY柿本さん、NewsPicks甲斐さん、Retty藪さん、クックパッド田中さん、エウレカ榊原さん、リクルートジョブズ渡邊さんの6名。いずれも今をときめくネットサービス企業のプロダクトマネージャー、プロダクトオーナーの方ばかり。皆さんまだ20代なのにとても優秀なPMで、モデレーターとして安心感をもって進行できました。ありがとうございました。
公式のイベントレポート記事が公開される予定とのことなので、僕の方からはパネルディスカッションで出たトピックをざっとご紹介。
ユーザー理解
- 自分自身がターゲットユーザーでないプロダクトにおいて、どのようにユーザーを理解すべきか。自分と世代や性別が異なるユーザーのインサイトを掴むにはどうすればいいのか。
社内のステークホルダーとのコミュニケーション
- 営業部門とプロダクト部門の考え方の違い、メンタルモデルの違いをどうの埋めるのか。短期計画と長期計画をどうバランスしながらプロダクト開発を進めるべきか。
チームマネジメント
- 事業の成長にともなって拡大する組織、チームをどうマネジメントしていくべきか。
PMの役割の拡大
- 事業フェーズの変化にともなってPMに求められる知識や役割が拡大していく中で、どのようにキャッチアップしていくべきか。
仮説設定と効果検証
- 筋の良い仮説を立案し、施策の結果をタイムリーに可視化し効果検証するにはどうすべきか。
おおよそこんなトピックについて各社の課題感や解決方法を共有していただきました。 印象的だったのが、自らSQLを書いてデータ分析をする、という方が多かったこと。仮説検証サイクルを素早く回す上では、データ分析スキルは必須なのかもしれません。
パネルディスカッションのお題の案を事前にもらっていたのですが、イベント中で取り上げられなかったので、僕個人の回答を記載しておきます。
PMとして日常的にどんな情報を集めているか
- プロダクトマネジメントの方法論に関する情報、グロースハックに関する情報を収集している。具体的にはMediumでProduct Managementなどのタグをフォローして新着記事をチェックしている。このブログでも過去にMediumの記事をピックアップして紹介している。特定のテーマについて知見を得たいときはQuoraで検索する。例えばPRD（Product Requirement Document）について一般的なフォーマットを知りたい、という時はQuoraで検索するとQ&Aが多数ヒットする。
PMやリーダーとして仕事をする際、一番説得しづらい人やチームは誰/どこか、それはなぜか、またどうやって上手く進めているか
- 受託開発の経験が長いと「決められた仕様通りに作りたい」と考えがち。事業会社では「ユーザーにとって価値あるものを作りたい」と考える人の方が活躍しやすい。どちらが正しいということでなく、状況に応じて適したメンタルモデルは変わる。時間が解決することもあるし、ユーザーに生の声に触れる機会を増やすことで変わることもある。
- この例以外にもメンタルモデルの違いが生むコミュニケーションコストが存在する。これを意識的に解消するのもPMの役割ではある。
- ものづくり側の人は、ユーザーに喜ばれる製品を作らないとビジネスとして成立しない、と考えている。逆にビジネス側の人は、ビジネスモデルが優れていないと良い製品を作っても無駄だと考える。どちらも正しい。同じゴールを目指しているが出発点が違う。両者の間を取りもつのがPMの役目。
今注目しているアプリやサービスとその理由 ex)流行りそう、機能が面白い、ビジネスモデルが面白いなど
- これは逆に教えてほしい。年齢とともにユーザーとしての感度や新しいものを求める欲求が低下するのが悩み。。。
実際PMっていう役割ある？社内での共通理解ってできてるの？それぞれの会社でどんなことやってるの？
- 自社ではここ1年ほどでPMという役割が定着した感がある。PMはプロダクトで課題解決する人。ユーザー課題や事業課題を発見すること、課題の原因を特定すること、ソリューションを考案すること、実現に向けてチームをリードすること、が主な役割。
PMの理想的なあり方ってなんなの？
- 良い仕事ができたとチームメンバーに感じてもらえるようなPMが個人的には理想。メンバーの共感を得ながらチームの自発性を引き出し、顧客に愛されるプロダクトを作ること。PMは責任はあるがチームに対して権限はない職務。make senseすること。思いつきでチームを振り回さないこと。
チームメンバーとの役割分掌などをどうしていくのか or どうしていく必要があるのか
- メンバーのスキルレベル次第で変わる。ベテランメンバーであればコンセプトや課題感を伝えればプロダクト開発は進むが、経験の浅いメンバーであればソリューションのゴールイメージをかなり具体化しつつ、アウトプットをレビューする必要がある。
今までで一番大きな失敗談(糧になった)と、それをどう乗り越えてどう成長できたのか
- 新規プロダクト開発のプロジェクトが中止になった。ステークホルダーの納得感を十分得ていなかった。特に営業サイドの責任者に売れるという実感を持ってもらうことができなかった。チームマネジメントにも失敗して、開発期間がずるずると伸びていた。気持ちの面で完全に立ち直るまでに1年ぐらいかかったが、その後のプロジェクトでその時の経験を活かすことができた。
- また、開発チームとの関係が険悪になったことがある。開発スケジュールが決まってから仕様を追加しようとしたり、背景や意図を伝えずに要件だけを伝えたり、開発スケジュールを無理に短縮させようとしたり、要は自分の思うままにコントロールしようとした。成果はチームで生むものだという意識で仕事をするようになった。
以上です。Vol.2も開催予定とのことなので楽しみです。pmjpでもオフ会などのイベントを企画していますのでぜひご参加ください。
