Pmconf 2019 11/12 まとめ
以下、敬称略
ただのまとめメモ
ORDINARY PEOPLE, EXTRAORDINARY RESULTS. Marty Cavan
プロダクトチームには2種類ある。一つは、与えられたロードマップでフィーチャー開発するだけ。もう一つはお客さまのことを考え、好まれるソリューションを提供し、同時にビジネスのニーズに答える。
前者をフィーチャーチームと呼び、後者を真のプロダクトチームと呼ぶ。
前者のチームはプロジェクトマネージャーを欲し、リーダーはチームを信頼していない。
後者のチームはコラボレーションで問題解決をし、PMはコラボレーションをまとめる。
後者のチームのいる企業のCOOレイヤーは以下の責任を持つ
The Role of Leadership
* Product Vision
* Product Strategy
* Product principle
* Product Priorities
* Product Evangelism
同様の企業のマネージャーは以下の責任を持つ
The Role of Management
* Staffing
* Coaching
* Objectives
最後のスライドは以下の画像
Special Session. Karelia Kuddu
自社事例についての話
スピードと顧客にフォーカスしている(スピードは、全体のスピード・プロダクト改善のスピード・意思決定のスピードなどを含む)
意思決定の速度を上げるために、チームに決定権を委譲している。
PMはデザイナー・エンジニア・アナリストと意思決定をし、製品を作る。
チームは意思決定をする自由を手に入れるために
* 顧客
* データ
の2つを理解していないといけない。
(マネジメントから上がってきた話に耳を傾けるのも大切だが)
▼顧客にとって重要なものを定義している
* PRICE
* SPEED
* CONVERNIENCE
* COVERAGE
意思決定において失敗した場合も、何が悪かったのかを理解して、次はより良い意思決定をする。これが自主的なチームのやるべきこと。
LINEにおけるお金とユーザーのジレンマ. 二木 祥平
1. PMってなんだろう?
LINEのPMはカメレオン。多様な人格&スキルが要求される。フェーズによって人格の配分が変わる。その人格を完璧に使い分けられるスーパーマンは滅多にいない。
PMの役割をシンプルに考えると
Mission: 自身のプロダクトを成功に導く
やること: 何を作るかを決める、そして、決めたものを市場に届ける
PMにはソト(ユーザー・企業)とウチ(社内)への妄想力が大切
PMは、基本的には一歩先を考える。開発の時にはQAのことを。QAの時にはリリース後のことを。開発サイクルを理解する。
「数字とかそれっぽい説明はどうでもいい、画面を見せろ」がキーワード。
社内の都合なんかユーザーは知らない。最終的にどう画面に起こされたのかを知る。
2. PMってジレンマ多くない?
PMはジレンマ回収役。めっちゃステークホルダーが多い
LINEのプロダクトポリシー: 徹底的なユーザーファースト
欲を言えば、お金は稼ぎたい。そのお金でもっと便利な機能を作りたい。。。
そんな状況で、PMが機能していないと
* 諦める。意外とこの時点で止まっているPM多い。
* 短絡的選択(AorB)
* 合議的結論: とりあえず全員の意見をそのまま混ぜる
結果、妥協したものが出来上がる。
「何を作るかを決める、そして決めたものを市場にとどける」
営業・開発・法務など複合的な情報を持っているのはPMだけ、決定責任がある。
ジレンマはHOWを2回繰り替えす
プロダクトビジョンを作る際は、社内ジレンマを解消するようなものにする
PMの仕事はジレンマの連続でありつつ、解決できないジレンマはない。そして、ジレンマの解消自体がクリエイティブな仕事であり、プロダクトに競争優位性をもたらす。
PMは調整役ではない。どう解消するか、をもう一段考えるべき。
コミュニティマネジメント: プロダクトの開発と展開をコミュニティが加速させる. 馬田 隆明
コミュニティ全体のデザインの話
https://www.slideshare.net/takaumada/startup-community-management-1
https://www.slideshare.net/takaumada/startup-community-management-2-design
ユーザー同士の繋がりが強くなることで、プロダクトも強くなる
身近な人からのアドバイスが大切になる
失敗事例で学ぶ 失敗しないプロダクトマネジメント -PMの必須スキルと、自走する組織のつくりかた- 岡田 康豊
PM組織にこんな問題があった
①自分の仕事や役割をうまく説明できない
②自分の持っているスキルを説明できない
③自分は他社で通用する...?
わかってきた打ち手
①PMの役割の明確化
②PMが持つべきスキルの特定
③どこでも通用する働き方
具体的には
* PMの仕事とは何かを他社事例を元に分析した
* 組織改革をした
* PM HEXを使った
PM HEXについて、詳しくは以下のnoteに
https://t.co/lQnSUQUceJ
企業が求めるプロダクトマネージャーとその人材戦略. 杉浦 正明 土屋 尚史 丸山 貴宏 / モデレーター 及川 卓也
プロダクトマネージャー人材の需要について
杉浦: ミニCEOを求めている。なんでもできるスーパーマンはそんなにいないので、何か1つ強みがありプロダクトにコミットできる人材の需要が高まっている。NewsPicksでは何か強みがあればよい。多様性があれば会社が強くなる。マネージャーチームだとメンバー2名。まずは今の体制でサービスを強めたいが、海外進出も視野に入れている。それに合わせて拡大したい。
土屋: PdMよりPjMを欲している。PdMのマインドを持ちながらでないとできない仕事が多い。ほぼPdMと同じ仕事をしているけど、企業側にいるPdMの右腕になれるような人材を欲している。GPではPjMだけど、企業だとPdMとしてやれる仕事をしている。
採用について
土屋: 失敗事例は外部から直接PdMを採ってしまった時。その人材がうまくチームをまとめることができなかった。何を作るべきかのWhatを求められているが、それをリーダーシップを持って提示できなかった。成功事例は新卒から無茶振りのようにPdMをお願いした子の方がいいチームができ、信頼を得た。会社の文化をどれだけ理解しているかが大切。創業者・経営者との信頼関係を持つのも大切。スタートアップにおいて、権限があるから動く、ということはない。
杉浦: 価値観・ミッションに共感できているPdMを採用できるかがキモ。PdMは愛が必要。プロダクト愛がなければメンバーの説得ができない。1人そういうリーダーを採れるとそういった人材が集まり、うまく循環が集まる。NewsPicksはPdMを外部から採用して成功している。
人材市場でのPdMの需要
丸山: 採用したい会社はとても増えている。人がいない。なかなか探せないため、あまり重点的にはやっていなかった。DBでサッと検索しただけで100近くある。ニーズはとても高い。需要と供給のミスマッチがかなり多い。窓口になる人事の責任者がPdMについてよくわかっていない。よくわかってないまま求人を出している。創業者PdMについては訳が違うが。。。
及川: 認知は確実に上がった。それはイベントでも感じる。
プロダクトマネージャーのオンボーディングについて
杉浦: まるっとぶん投げてうまくいくもんではない。強みが違う中、丸投げしても荷が重い。どういったところに強みを見出して、どういった課題を解決したいのかを明確に説明することが大切。1番最初は責任範囲を1つに絞るのがいい。NewsPicksでは最初は新規プロダクト1つをお任せして、それから全体を見てもらうようにする。
及川: ZOZOの話を覚えている。ある花を持たせるようなプロダクトを持たせて、最初に成功させる。そこがエンゲージメントだそう。
土屋: 自社プロダクトのチームが小さい。いきなり権限を渡してあとはよろしくはいけない。半年〜1年は並走することになる。意思決定のポイントや視座と視野の範囲を見ている。創業者がどれくらいのことを期待しているかをわかってもらう。期待値調整とオンボーディングをどこまでやるかが必要。自らのミラーコピーが必要。
価値観の確認について
杉浦: 仕組みは1on1。価値観が合っているかは入社時に確認するが、入社後にも確認する。
土屋: 1on1はもちろん。スクラムイベントに自ら参加し、自身の視点と視野がわかるように説明する。5W1Hを理解してもらうようにする。事業ミッションは抽象的なので、具体的なHowは一緒にすり合わせていく。
丸山: 1on1は非常に効果的。週一回は必要。まず何をやってもらいたいのかをしっかり伝える。短期的・長期的なミッションを伝える。その後お互いのチューニング期間がだいたい3週間。入社初日のランチを誘うなど、しっかりとコミュニケーション取れる場としていく。
発明、ドッグフーディング、プロダクトマネジメント. 増井 俊之
日々のドッグフーディングによる問題の発見と解決. WEB+DB PRESS Vol.102
良い問題の発見と良い解決
* ドッグフーディングを使うとよい
発送フェーズと運用フェーズ
* 発明家 兼 PMは少ない
得意技の融合と継続
* デザインエンジニアリング=デザイナー+エンジニア
* 発明+プロトタイプ+ドッグフーディング+実装+運用+営業
ドッグフーディングを取り入れた開発の流れ
* 発想
* 高速プロトタイピング
* ドッグフーディング
* 改良
* ドッグフーディング
* 改良...
発想
* 問題発見
* 問題解決
* 制約発想
* そもそも発想
* ドッグフーディング発想
* 芋蔓発想
泥酔してても使えるものを考えるとよい
あなたにとってのPdMとは
* 発想+プロトタイピング+ドッグフーディング