プロダクトのための地味な動き - 地味PM meetup

2022/04/12開催の地味PM meetupの登壇資料です。
https://mercari.connpass.com/event/243373/

Transcript

1. プロダクトのための 地味な動き @地味PM meetup 株式会社グロービス Globis Digital Platform CPO/PM 久津佑介
2. 2 自己紹介 久津 佑介 / Yusuke Hisatsu 株式会社グロービス Globis Digital Platform 学習サービス事業部 CPO 兼 法人開発チーム PM @Nunerm プロダクトマネージャーカンファレンス実行委員会もやってます（今年もがっつり計画中）
3. 3 今日話したいこと 「PMがやるべきこと」ではなく 「プロダクトのためにやるべきこと」に フォーカスしよう
4. 4 プロダクト開発の当時の状況 学習サービス 事業部 事業 開発 国内toC 国内toB 海外toC/toB コンテンツ 決済 受講者体験 法人 組織の特徴 • 事業と開発でチーム分けの軸が異なる ＝コミュニケーションパスが複雑 • 一部を除き、事業チームから依頼する/ される関係が残る CPO PM 開発依頼
5. 5 法人開発チームの当時の問題 Discovery • ユーザーの解決すべき課題の解像度が粗い • ユーザーストーリーが整理されておらず、思いつきドリブン • データよりステークホルダーの経験や主観で優先度が決まる Delivery • リリースした機能でなかなか成果が出ず、その原因もわからない • 期待される開発パフォーマンスが出ず、リリースペースが遅い 解決に向けてアクション！　
6. 6 問題解決のためにやったこと Discovery • ユーザーインタビューを100回行って課題を抽出 • プロダクトロードマップをビジュアライズしてチームへ浸透 • データ分析基盤とダッシュボードを作り、データドリブンで意思決定 Delivery • リリース前にA/Bテストを必ず行い、成果への確実性向上 • デュアルトラックアジャイルを導入しリリースへのリードタイム短縮 無事に解決！　
7. 7 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ うそです
8. 8 実際に問題解決のためにやったこと Discovery • 他チームのNotionページを全探索＆インデックス作り • カスタマーサクセスチームとの定期ミーティング設定＆明るいファシリ • アジェンダを日英併記ルール策定 • 経営会議に参加するために上司に根回し Delivery • 全チケットと突発的に発生するタスクのトラッキング＆グルーピング • 一部のタスクをやらない理由を資料にまとめてプレゼン＆根回し • 他開発チームのミーティングやランチに乱入して状況把握
9. 9 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ 地味
10. 10 なぜ地味なことばかり行なったのか？ 問題の原因の大半がこの２つであることがわかったから 　①周りとの情報の格差 　②役割定義の曖昧さ 例：ユーザーの解決すべき課題の解像度が粗い →カスタマーサクセスが持っているユーザーに関する貴重な情報がシェアされていなかった →これを無視してゼロからリサーチしても時間の無駄だし、サクセスと一枚岩になれず価値を最大化できない →まずは一致団結できる関係性づくりと情報の透明性を！ 例：期待される開発パフォーマンスが出ず、リリースペースが遅い →単純にやることが多かった →チームの役割定義が曖昧だったので、隙間にあるこぼれ球がガンガン投げられる →まずは役割の再定義をし集中できる環境づくりを！
11. 11 実際に問題解決のためにやったこと Discovery • 他チームのNotionページを全探索＆インデックス作り • カスタマーサクセスチームとの定期ミーティング設定＆明るいファシリ • アジェンダを日英併記ルール策定 • 経営会議に参加するために上司に根回し →周りの情報を取りやすくする動き Delivery • 全チケットと突発的に発生するタスクのトラッキング＆グルーピング • 一部のタスクをやらない理由を資料にまとめてプレゼン＆根回し • 他開発チームのミーティングやランチに乱入して状況把握 →「やらない」の説得力を上げて周りにパスしやすくする動き
12. 12 どう考えているか
13. 13 どう考えているか
14. 14 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ それはPMがやるべきことなの？
15. 15 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ 知らん
16. 16 プロダクトのために誰かがやるべきことではある こういう地味な仕事は、プロダクトの価値を最大化するために必要になる場合がある ただ、面白くないし直接的な成果も見えづらいから誰もやりたがらない それが「PMがやるべきこと」かどうかは知らない でも誰もやる人がいないなら自らやった方がいい なぜならPMは「プロダクトの価値の最大化に誰よりもコミットする人」だと思うから
17. 17 今日話したいこと（再掲） 「PMがやるべきこと」ではなく 「プロダクトのためにやるべきこと」に フォーカスしよう
18. 18 宣伝 このような取り組みもあり GLOBISのプロダクト開発組織は 目に見えて成長しています ただ、まだまだ課題も多いしPMも足りません 一緒に「学びの未来」を作りませんか まずはカジュアル面談しましょう！ Twitterで「久津 PM」と検索したら出てきます→