プロダクトマネージャーカンファレンスに参加してみて (2019/11/12,13)

自分が参加したプロダクトマネージャーカンファレンス (Yでいうサービスマネージャー)の内容をまとめてみます。

(※社内向けの自分の備忘録として作成したので、文字間違ってる所や、読みづらい所あるかと思います。すみません。)

概略がわかるだけなので、これで全てがわかるわけではありませんが参考に。
これから近い役割になる人のために。

プロダクトマネージャー(PM,PDM)とは?

プロダクトマネージャーとは

・その機能、製品に責任を持ち、ユーザにとってより良い機能、製品を考え、決定する人
・ミニCEO
・何でも屋さん
・技術、デザイン、ビジネスに精通している人
・その他色々...

実は、はっきりと決まっていない、定性的な部分が多い。
例でいうと、PayPayフリマに必要な機能をヒアリングし、解決すべきことに優先順位をつけ、決定する役目の人と思われる。

プロダクトマネージャーに必要な仕事

・プロジェクトマネージャー的仕事 (スケジューリングとか)
・ユーザの声を拾うための、営業との連携
・ユーザが望むUI/UXのためのデザイナーとの連携
・ユーザが望む機能実現のためのエンジニアとの連携
・(プロダクトを表舞台にだすための法務との連携)
=> ユーザのために、最高の製品を出すのに、必要な仕事を何でもする人

また

・実際にものを作るわけでない。
・作った人のものを集約する人。その方針決めをする人

である。

なので、以下の点を意識する必要がある。

1. 作った人に感謝し、作る人、関わる人が最大限モチベを上げて協力できる環境づくりが必要

2. 決定権があるわけで、一番偉いわけではない。あくまで、作る人、協力してくれる人がいないとできない(大事)。

----------前提ここまで。------------

今回、面白かった内容、学んだこと

・PMに必要なマインドセット,組織作り(定性的部分)
・PMとして、実際により良い製品を作るための具体的な方法 (定量的部分)

上記2つについてジャンル分けして説明します。
今回の記事では、上の定性的な部分のセッションについて書きました。
(※は特に自分が印象に残ったセッション)

・ PMに必要なマインドセット、組織作り

・ORDINARY PEOPLE, EXTRAORDINARY RESULTS
    発表者: Marty Cagan 

・プロダクトマネージャーの仕事はお客様が愛してくれる製品を作ること　
　　条件は valuable, usable, feasible, viable

・feature team (機能チーム) でなくEmpowered Teamを
　・ロードマップを押し付けることが仕事でなく、チームを信頼してチームを活用
　・PMは人の管理でなく、一人一人が考えて責任を持って動けるかを作ることが重要

・ビルキャンベルの言葉, リーダーシップとは認識すること。
　そして、いかにして良い環境を作り、
　良い解決策をメンバーが作れるかが重要

・リーダーシップの約束事
　・Product vision (北極星を指し示す)
　・product Strategy
　・Product Principles
　・Product Priorities
　・Product Evangelism
　なぜ会社をやめるか? それはマネージャーの下で働きたくないから
・Managementの約束事
　・staffing
　・coaching
　・objectives

・有能な人の例
　嫌な人でないこと。
　どれだけ実力があってもついてこなければ、意味がない。

・Empowered teamであることを確認する方法 (英語で間違いあるかも)
  ・チームは有能な人材が実力を発揮できる場所に人材配置できているか?
  ・チームではビジネスの問題や客の問題の説明責任を果たしているか?
  ・チームは一番重要な問題を解決する権限をメンバーに割り当てているか?

・LINEにおけるお金とユーザーのジレンマ
　発表者 LINE 二木祥平さん

https://speakerdeck.com/line_developers/money-and-user-dilemma-for-line

・PMはソト(ユーザー、企業)とウチ(社内)への妄想力(もしかしたら、あの人とあの人はこうかも。。。)が重要
・ユーザ目線で徹底的に触る
・Missionは自身のプロダクトを成功に導くこと
・やることはPMは何を作るかを決めること
・ジレンマの連続だが、解決できないジレンマはない。
・そこのジレンマを解決する部分にクリエイティブな部分がある。楽しもう。
(パネルディスカッションの内容は割愛)

※・PDMのFlexibilityについて
　  発表者 楽天 熊谷亘太郎さん

・PMとはプロダクトの成功のためなら、何でもする。何でも屋
・今回はスキルとかのハードの面ではなく人間性などのソフトの面を説明

・他の部署の人とどううまくやっていくかの話
　・経理が使うシステムのプロダクトマネージャーに配属
　・Urgentのリクエスト このデータを今日中に解決したい。
　・背景を理解していなく、緊急度が高いことが連続で起こる。
　・経理にどういう背景で行われている? → 背景は知らない。(何!?)
　　決められた日にやることが仕事になってる。
　　これがおかしいという感覚がない。
　・勉強のために、ヒアリングさせていただいてもよいですか?
　　　　↓
　・施策が効率的でなかった。例えば↓
　　・月に10万円得るために、100万円かかっている。
　　・決められた日にデータ出てるけど、使われていない。
　　・二回のオペレーションを1回に
　　　　↓
　・月100あったオペレーションを0に
　　・早く帰れるようになった。
　　・利益がマイナスが0に
　　いいことずくめ。
　・他の業務に割り込んで行くことが大事
　　でも、すぐに口を挟むと受け入れてもらえない。どうする? ↓

今回のテーマがこれ。
Break down
・サービスローンチしたが、ロールバックする羽目に。
・一回関係性が悪くなった。事業とPDMとエンジニアとの関係が最悪に
　なぜ? -> 早く終わらすためのストレスから、Strong initiatibveをして

・Bad cycle
　　Strong initiative => unsupportive
　　=> project Fail => Because of PDM 　　
　　=> Bad relation =>最初に戻る
解決するためには↓
・Good cycle
　　Listen => Sympathy
　　=> Suggest => Solve
　　=> Thanks => Trust => 最初に戻る

　・Listen: ヒアリングの時は、なるほどを使う。whyを使わない。
　　　言う時は自分はこう思っているんですがこう言うことですか?と尋ねる。
　・Syimpacy: あなたの問題は私の問題だと思う。 まじかい。
　・Suggest: もしかしたら、こういうとか、ひょっとしてで、提案する。 
　　　相手が意見してきたら、それいいですねと言う。自分のものにしなくていいと思う。　
　・Solve issue: Pdmがアイデア出したと主張しなくていい。十分目立っている 
　・Thanks: ありがとうと言う。 例として、あるPDMはすみませんといつも自分のせいにする。これは自分の責任とするため。ありがとう。
　・Trust: 以上により信頼が生まれる。
　　・プライドが邪魔をすることがある?
　　　PDMにはプロダクトの成功のためのプライドだけ持っていれば良い。
　　　他のプライドはいらない。
　　・相手が自分を尊敬しているかはわかる。相手の発言は遮らない。

Herrman Model
・人の利き脳を知るための手法 => 話す人との糸口
　・Analytical 青 はボトムアップで話す。
　・黄色はこれはこうと経験的
　・赤はemotionで、感覚
　・緑はpractical 実践的 ロードマップはこうで。
　相手がどのタイプか知っているとうまく行く。

弊害
・拡大解釈してしまうこと。受け取ろうとしやすい
・相手の言っていることを掘り下げることが必要

Enjoy your work
・PMといってもどうすれば...->オペレーションなどの簡単なところから。
　できることから。
・プロダクトマネージャーが楽しくなければ、どこかが間違っている。
　
今回の話の流れは、
プロダクトマネージャーとは？
→ 今回はソフト面の心持ちのお話
→ 自分が経験した実態例
→ 失敗パターンと成功パターン
→ うまくやるためのTipsと気をつけること
→ 最後に伝えたいこと
となっていた。
今回参加したセッションの中で、一番共感でき、感動した。

PMとして上手くやる具体例、フレームワーク(具体例)の方は、別記事に載せます。(上で力尽きてしまった...)

※参考資料
https://medium.com/@oikawa/pmconf-jp-2019-slides-1e56aae20b5b (ここにほとんど載ってる、すごい)