11月12日・13日の日程で開催されている pmconf こと、プロダクトマネージャーカンファレンス 2019。
現在僕は仕事でもプロダクトオーナーシップに近いところにいたりして、「プロダクトマネージャー(PdM)」への関心が急激に高まっていたりする。趣味開発プロダクトにおいては常に自分がプロダクトオーナーであるとも言えるし(?)。今回はもろもろ噛み合わず参加を見送ったのだけど、インターネット上に溢れでてきた情報からだけでも最大限インプットしたいということは、イベント開催前から思ってた。
これは、Twitter の「話題を検索」で #pmconfjp を検索した結果の「最新」で見られるものを 2019-11-13 9:00 AM 時点で全部追ったついでにまとめたメモ。やはり盛り上がっていたのか、相当な数のツイートがあった。もし資料の取りこぼしがあったらぜひ @a_know に教えていただきたいです。
登壇資料(順不同)
14:50 から登壇します(しました)!類似資料の一部はこちらから。コミュニティマネジメントです。http://bit.ly/pm2019cm1 http://bit.ly/pm2019cm2 #pmconfjp
同じ時間の別セッションのタイトルにサブタイトルを被せるというチャレンジをしたのは私です。
会場内が優しい方ばかりで助かりました。
本日の発表内容アップしましたー。https://speakerdeck.com/t_yoshimoto0107/beruhueisugamiao-kuzong-purodakutomaneziyagou-xiang …#pmconfjp #pmconfjp_2_3 https://twitter.com/pmconfjp/status/1194137770782015490 …
現在開催中の #pmconfjp にて、執行役員 二木の「LINEにおけるお金とユーザーのジレンマ」の登壇資料を公開いたしました。
また展示ブースでは各サービスのLINEのPMと話せる時間を設けています!是非遊びにきてください。⁰https://speakerdeck.com/line_developers/money-and-user-dilemma-for-line …
#pmconfjp 1日目 Pairsの「作り手の想いとユーザーをつなぐための悪戦苦闘」の資料です。会場の皆さんに暖かく迎えていただき楽しくお話ができました。ありがとうございました。
15分では話したいこと足りず、あと2セッションくらい持ちたい気持ちですwhttps://speakerdeck.com/kanadadada/zuo-rishou-falsexiang-itoyusawotunakutamefalse-e-zhan-ku-dou …
本日プロダクトマネージャーカンファレンス2019でお話しさせていただいた、#VRoid 事業責任者の佐藤(@machie)の講演資料を公開しました!https://docs.google.com/presentation/d/1o3bDSU9MMwegHKP04HiJtO4tdqDcSEIhYZGi1FL3jNw/edit#slide=id.g6fb2cb931d_0_5 … #pmconfjp
本日登壇のフォローアップ記事出しました。
オファーいただいた @mizuki_tannoさん、運営の皆様、改めてありがとうございました。明日も頑張って下さい!
"事前に募集したQ&Aへの回答もできなかったため本稿はフォローアップ記事となる。"
--
10xのための逆説 #pmconfjphttps://yamotty.tokyo/post/20191112_pmconf/ …
その他、参考になりそうなページなど
- エムスリーでプロダクトマネージャーとして働くということ(デジカル編) - エムスリーテックブログ
- プロダクトマネージャーに必要なテクニカルスキルを定義してみた話。|岡田康豊(OkaP) | HR Tech プロダクトマネージャー|note
- プロダクトマネジメントトライアングルと各社の PM の職責と JD - Taka Umada - Medium
- Product Managers Japan (PMJP)
- プロダクトマネージャーに求められるスキルとマインドセットとは-[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業における…
- 新米PMがまず最初にやるべき4つのこと~pmconf-day1の学びから実践へ-|YoshiD|note
- 視座の獲得と視野の拡張|JuKoA|note
- Product vs. Feature Teams | Silicon Valley Product Group
- 事業ドメインを絞り込むことで磨かれるプロダクトマネジメント | プロダクトマネージャー・カンファレンス 2018
- 視座の獲得と視野の拡張|JuKoA|note
自分の感想とか
- IT分野の人の既存事業への挑戦、やはり進んでいる......
- 「企画バックグラウンドPdM」「エンジニアバックグラウンドPdM」、よい
- 「製品を見つける」という表現、なるほど感ある
- 発明できてるか?と自分に対して問い、ハードルあげていきたい
- カスタマーサクセスの考え方もめっちゃ活きそうだなーとか思った
- プロダクトマネージメント・カスタマーサクセス・コミュニティマネジメント、あたりは、比較的新しくも今後激しいニーズの高まりがありそうな分野な気がする
- 自分のキャリアを円グラフで表現するの、おもしろいなw
- プロダクトマネジメントトライアングル。
- 「顧客の定義を考えることが習慣に」「どうすればサクセスするかが共通言語に」、良い
- 妥協、一番怖いかもしれん......
- 「そもそもこれは二律背反なのか」大事ですよね
- 「解決できないジレンマはない」と言ってもらえるのは心強いね(LINE の PdM の方ですら 3勝2敗/日、と言っておられるのも)
- 「プロダクトリーダーシップ」またいいワードでてきた
- 「スキル」と「スタンス」。スキルに目が行きがちだけど、もう片方を「スタンス」という表現されてるのは良い気がした
- pixivさんに対するイメージが良い意味でめちゃくちゃ変わったぞ......
スタンス=意思決定をし、チームを導くために必要となる性質
- https://docs.google.com/presentation/d/1o3bDSU9MMwegHKP04HiJtO4tdqDcSEIhYZGi1FL3jNw/edit#slide=id.g73e2635c52_0_136
- PMギルド、めちゃくちゃ気になる
- 10Xさんのセッションもめちゃ刺さる
- 「特定の人物の、特定のシーンの、重要なイシューを解決する」めっちゃよい
- 「ユースケースの芯を食う」
- 「人が欲しがるものをつくる」ではなく「シーンで必ず使われるものをつくる」。
極めて具体的なシーンとコンテキストに対してどれだけ適切なプロダクトであるか
。 同じシーンを捉えたサービスをベンチマークにする
LTVが低い=顧客への提供価値が低い
失敗のたびにビジョンをアップデート出来ないといけない
プロダクトを成功させるという戦争
ANDで獲得していけるアニマルである必要がある
- ドッグフーディングをみんなでできてるとストーリーを共有しやすい、というのはありそう〜
- プロダクト内の顧客だけでなくマーケットを。見ないとなぁ
- もっとデータを意識しないとなぁ
- 施策や試み、それが間違い・失敗だったかどうか?という判断をおこなうタイミングを設けていなかったり、その判断をおこなうことができない(判断に必要な材料を揃えられない・その基準が明確でない)、というのも問題だよなぁ
- すべてを鵜呑みにはしない(これを材料として、自分のチームとしての最適解を探りたい)にはしても、アンチパターンとされているものだったり注意すべき点としてあげられているものについては、先人からのアドバイスだと思って咀嚼したい
- 愛とか情熱とか必要なのかどうか、と疑問に思ったことがあって、必要なんじゃないかと思っていたが、それが裏付けられたような気持ち。
- ただし、顧客対話との両輪でもある、というのは忘れないようにしないと。。
客観的にみても自分はプロダクトのことを考えられてるほうだと思うんだけど、それはそのプロダクトのことが熱狂的に好きだからだと思ってて、世の中のプロダクトのことを考える役割の人もまた、自分のプロダクトのことを熱狂的に好きなもんなんだろうか。(必ずしもそうでない気がしている。)
参加者のみなさんの感想 ほか、印象にのこったツイート(順不同)
2つのチーム
- featureを作ることに責任を持つ
- customerの問題解決に責任を持つ
強いチームは後者#pmconfjp
#pmconfjp エンパワーされたプロダクトチームを作るかどうかは最終的には経営レベルの判断。そうでない企業にいると、できることは限られるか時間がかかってしまう。プロダクトチームが主体的に成果を上げることで少しずつ文化を変えることはできるかもしれないが、多くの場合は転職したほうが早い。
"問題解決するベストの方法は何かを考えるのがプロダクトチーム"
この意識を広めて行くのは大切だ。
#pmconfjp
あなたのチームが強化されている?
1.競争力があり、キャラクターのある人で構成され、必要なスキルセットが整っている
2.チームは解決すべき課題が割り当てられておりその問題を解決する最高の方法を決めることができる
3.チームは、顧客またはビジネス課題を解決することに説明責任がある#pmconfjp
スピードと顧客ファーストを支えるのが自律的なチーム。
早く持続的に動くのに最適。顧客に近いところでチーム内で意思決定。プロダクトプランやロードマップを決めるためのコミットメントやマネジメントミーティングなし。チームは正しい結論を出すか、間違いから学ぶと信じている。#pmconfjp
"Learn from wrong ones" -> 間違いを隠しちゃダメゼッタイ。
間違いから学ぶというのは、反省して萎縮というよりもむしろ「早く動くため」#pmconfjp
この考え方が、経営者や創業者へのコーチングがワークしていたことに注目すべき
Product teamがみずからFeature teamになっていく組織はたくさんあります。フェーズの問題として片付けられることもしばしば
もっと上流から意識をかえていかないといけない
まとめありがとうございます#pmconfjp https://twitter.com/yan_tzn/status/1194075946241773569 …
「本当のプロダクトチームの判断にマネジメントの承認はないはず。それが一番スピード感があってサステナブルで正しい判断ができる組織になる。なぜなら、顧客の一番近くにいるのはチームだから」 #pmconfjp
自律的なチームに判断する自由を。ただし、判断には常に顧客のインサイトやデータによるバックアップが必要。 #pmconfjp
Transferwiseさん結構過激なマネジメントしてる。
・速さとサステナビリティを重視した自治的なチーム
・カスタマーのより近くで意思決定
・マネジメントミーティングとかプロダクトストラテジーとか無い
・信頼する
・正しい決定をするか、間違ってもそこから学べば良い#pmconfjp
・自主性を高めるために権限移譲を進めることは大事です
・任されたら物事を背負い始めて、自分で考え始めます
・が、初めての能動的思考なので、最初は筋が良さそうな方に並走する必要があります(ここやらないとただの失敗体験)#pmconfjp
![]()
Autonomy=responsibility
自主性というのは、責任を伴う。
自由な裁量権を持つということは、その分結果に対する責任も負う
意思決定にはもちろんデータが必要だし、顧客のインサイトへの理解も必要#pmconfjp
意思決定の自由を持つというのは、責任を持つということ、カスタマーインサイトしているから説明できる。だからプロダクトチームが権限を持つ必要があるのだと思う...けど、やっぱり経営との関係がきになる。海外の方がトップダウンに動くイメージがあったけど。#pmconfjp
![]()
Transferwiseさん結構過激なマネジメントしてる。
・速さとサステナビリティを重視した自治的なチーム
・カスタマーのより近くで意思決定
・マネジメントミーティングとかプロダクトストラテジーとか無い
・信頼する
・正しい決定をするか、間違ってもそこから学べば良い#pmconfjp
プロダクト原則をしっかり定義して、ユーザーインサイトとデータに基づいて意思決定しながら学べばカオスにはならないという方針のよう。
・価格が安い
・スピードが速い
・使いやすい
・色んなところで使える
原則この4つを良くする方向、って決まってるなら確かに迷わなさそう。#pmconfjp
チームに自主性を持たせることがスピードや解像度の高い解決策を出すために必要。チームに自主性を持たせるには、情報の透明性や意思決定権の譲渡、共通言語として語れる顧客像の目線合わせが重要と言う理解
#pmconfjp
スクラムでも時々でてくる言葉、”Product Discovery"って、"要件定義"よりもいい言葉だ。それは誰かが決めることではなく、皆で発見するものだと。プロダクトの開発とは、作られたロードマップを行くことではなく、繰り返される実験から導き出されるものだと。#pmconfjp
![]()
プロダクト原則をしっかり定義して、ユーザーインサイトとデータに基づいて意思決定しながら学べばカオスにはならないという方針のよう。
・価格が安い
・スピードが速い
・使いやすい
・色んなところで使える
原則この4つを良くする方向、って決まってるなら確かに迷わなさそう。#pmconfjp
Transferwiseの場合プロダクトの性質上グローバルに広がることで価値が上がるので、各国の拠点が自治的に動くのは相性が良さそう。
自治は責任が伴うこともチームで同意が取れてるんだろうな。
ここでもtrust(信頼すること)とoutcome(結果を出すこと)がキーワードとして上がってきた。#pmconfjp
・PMあるいはプロダクトチームに戦略の意思決定の自由と結果に対する責任を与える
・ユーザーが求めることが明確で共通認識になっていればカオスは生まれない
・間違いから学ぶ
#pmconfjp #pmconfjp_main
- プロダクトマネージャーを雇用する場合の条件
- 事業も出来る人を雇用する
- 意思決定もできる
- 会社を自ら経営できる人材であるべき
- 政治的なゲームを楽しむ人でない
- チームとして仕事が出来る人
- ディスカッションして進められる人
#pmconfjp
これは間違いなく真理。経営層の信頼を失ったらもうPdMにやれることなんてないです。
だからPdMは経営層の期待に応えなければいけないし、期待値を超えたパフォーマンスを出していかないといけないと思っています。#pmconfjp https://twitter.com/hideo515/status/1194092396054794241 …
■PdMはカメレオンやで話
・大きい組織のPdMはよりビジョナリー性質を要求されるで...
・一方、スモールな組織だと推進力を要求されるんやで...
・かつ、フェーズ(企画~リリース~グロース)に応じても発揮スキルが変動するんやで...
→とにかく、PdMは成功に導いたらええんや...!!!#pmconfjp
![]()
市場拡大とPairsの成長の中で起こった"お客様は誰だ"問題。
マーケットが広がる中で、想定外のユーザーに使っていただいている。#pmconfjp
プロダクトチームが見ているユーザーとマーケティングチームが見ているユーザーが段々とかけ離れていく。#pmconfjp
![]()
プロダクトチームが見ているユーザーとマーケティングチームが見ているユーザーが段々とかけ離れていく。#pmconfjp
「自分たちはユーザーのことを良く知っている」という過信。
・"自分たち = ユーザー"の過ち
・自分たちの想い、思いつきでの課題/ソリューション検討(ユーザーを見る大切さを分かりつつもすごく難しくなっていく)#pmconfjp
![]()
「自分たちはユーザーのことを良く知っている」という過信。
・"自分たち = ユーザー"の過ち
・自分たちの想い、思いつきでの課題/ソリューション検討(ユーザーを見る大切さを分かりつつもすごく難しくなっていく)#pmconfjp
Pairsが想いと思いつきベースから、お客様との対話ベースへ。
プロダクトマネジメントの方向性を失敗からのラーニングに振り切っている。
・顧客のプロファイル化
・検証のハードルを下げる
・学びの共有文化醸成#pmconfjp
![]()
月に一度、全社での学びの共有会の運営を行う。"リリース後施策の報告メイン"から"リリース前の学び中心"に。
"失敗こそ共有しよう"というメッセージを会に浸透させている。#pmconfjp
総括
・プロダクトが大きくなるに連れて顧客の多様化/ニーズの多様化が発生し迷う
・プロダクト内の顧客だけ見ているとマーケット自体の鈍化とプロダクトの停滞にあたる。マーケットを見よ
・想いも大事だが、プロダクトはもっと顧客対話型にならなければいけない#pmconfjp
ジレンマは認識の違いから発生するとのこと。
対立構造の根本原因を正しく認識することで目的を共通化し、ビジョンや方針によって共闘関係に変えていくことができる。#pmconfjp
LINE二木さんのセッション良かった
「ジレンマの解消自体がクリエイティブ」っていい言葉
ジレンマ敗北度チェックは週1でやろう
・仕様を書くだけの人になっていないか
・判断を上に求めて合議制で決めようとしてないか
・人のせいにしてないか
・feature teamになっていないか?
#pmconfjp
・仕様を書くだけの人になってない?
・常に判断を上に求めて合議制で決めようとしてない?
・他人や他部署のせいにしてない?
プロダクト開発におけるジレンマに敗北していないかチェックリスト。プロダクトの成長を邪魔しちゃう要素。自分もあるし、他の人も耳が痛くなりそー。 #pmconfjp
「ジレンマ解消自体がクリエイティブ」って素敵な視点だなぁ。 #pmconfjp
ビジョンが見えない・実現に向けて粘り強く取り組める環境がないと、PMは機能できなくなるのかも。
「ジレンマはHowを2回繰り返すと同じ目的にたどり着く。
大抵のジレンマは解消できる。
そしてそのジレンマをどう解消したかが、プロダクトのユニーク性になる」#pmconfjp
LINE、PMが機能してないと何が起きるか「諦める:一番楽。意外とこの時点で止まってる人多い」
これわかる。重要な課題なのにずーっと放置されてることがプロダクトにあったりする。
#pmconfjp
freee 執行役員 岡田さん
バックログの縮小均衡
闇雲にバックログを追いかけるだけのプロダクトは陳腐化し、誰のテンションもあげない。社内でも存在感が薄れていき、縮小銀行に陥る#pmconfjp
プロダクトオーナーの認識が自分とは逆。プロダクトマネージャーが意思決定者でプロダクトオーナーが意思決定の中でプロダクトバックログを管理する役割だと思ってる。
まぁ役割認識がチーム内で合っていれば、どちらでもいいとも思うけど。#pmconfjp #pmconfjp_2_1
PMが複数いるとその責任範囲ってどうなるんだろう。一般的なPMより権限や責任領域は少なくなって判断権限がないPMとか生まれそう。どうしてるんだろ #pmconfjp
M3さんのバックグラウンド毎にpmわけてるのは確かに。感がある #pmconfjp
プロダクトマネージャー、企画バックグラウンドの人と、エンジニアバックグラウンドの人がいるのはそのとおりだな。何でもできることを期待してしまいがちだけど、そうすると、プロダクトマネージャーしんどいよね。#pmconfjp
そもそもPMが複数いた方がいいよねって言う考えのスタートが気になる。どうしても Scrumでやってる人間からすると不便さの方が多く見えてしまう #pmconfjp
PMとしてストーリーを語ることはなぜ大事か?1.ストーリーは話したくなる 2.ストーリーは記憶に残りやすい
結果として、・ビジョンがボトムアップでムーブメント化して機能しだした・バックログに意味が宿り意思決定がしやすくなった#pmconfjp
ストーリーを持たないビジョンは絵にかいた餅になる。(誰も意識できない/形骸化する)
ストーリー化すると、記憶に残り、皆が意識できるようになる。
課題をストーリーで語る習慣が身につくと、「何故それをやるのか?」を開発メンバーが理解でき(適切に取捨選択され)、良い循環が回る。#pmconfjp
物語はいかに当事者になって語れるか。
あるある。と共感を呼べる内容。利き手を惹きつけられるフックになると印象に残る。
物語の最後に主人公に何らかの変化が起こっている。#pmconfjp
ピクシブのプロダクトマネージャー
- サービスの成長に対応する①
- 強味の異なるPMでネットワークを埋めあう
- PMを複数立てる
- サービスの成長に対応する②
- プロダクトオーナが複数のPMを統合する
- 複数PMを立てる場合の注意点
- 意思決定者を一人にする
#pmconfjp
「最も大切なのは、自分が夢中になれる物語を描くこと。」
良い言葉。
ストーリーを作成して、実現されたか計測すると、無意識にPDCAが回る体験が全員に得られるのが肝に思いますね。
普通にバックログ潰していると前に進んでいるのか、よかったのか悪かったのかが見えにくくなってしまう。#pmconfjp
プロダクトビジョンをストーリーとして作成し、語り、計測するのが重要。
どうやってストーリーを作る?
・誰の問題なのか
ドッグフィーディング
・何が問題なのか
具体的に:年末調整、FAX
・どうなる
主人公の変化
ストーリーを作った後は、叫び続ける
PMは手段を選んではいけない#pmconfjp
1人のPdMが全てを見ることが不可能になってくる
やはり、規模が大きくなってくると1人だと辛いよなぁ#pmconfjp#pmconfjp_2_3
freee岡田さんのセッションも良かった
ただのビジョンではなく、動的な流れを持つストーリーで語ると、自分ごとになり組織にムーブメントが生まれる。
主人公(=ユーザー)を設定し、問題を定義し、狙う主人公の変化(=ストーリーのオチ)を語るべし。
#pmconfjp
PMが調整役になってしまうと、以下のような不安が生まれやすい。
①自分の仕事や役割をうまく説明できない
②自分の持ってるスキルを説明できない
③自分は他社で通用するのか
PMはminiCEOと言ったりしますが、果たしてどれだけのPMがそういう役割を演じられてるか。
#pmconfjp #pmconfjp_main
sansanさんのセッション。長期は、中期、短期でpdmの責任者レイヤーを分けてる #pmconfjp
リーンな組織の価値は改善の速さではなく、
どこが問題の芯なのかをコストを抑えて探す「探索力」。
リーンに芯を探して、手応えを掴んだらそこに投資する。
それを探すためのリーン。#pmconfjp
ユーザペインによって優先度をつける、大事 #pmconfjp
toCかtoBは関係なく、フリクションを解決できるか。toCのユーザー数は資金で解決できるが、toBは非生産的システム、複雑なオペレーション、ガバナンスが立ちはだかる。これを解決することこそがDX。#pmconfjp #pmconfjp_2_1
エン・ジャパン岡田さん(@middleOkada)のお話で記事で見たPMのスキルを明確化したチャート出てきた!
個人的にこういうスキル見える化にとても興味があり、やっていたりする。
PM界隈が盛り上がることが、ひいては日本を盛り上げることに繋がるという視座の高さが素敵。#pmconfjp
定説:人が欲しがるものを作れ
逆説:シーンで必ず使われるものを作れ
極めて具体的なシーンとコンテキストに対してどれだけ適切なプロダクトであるかの方が重要
ペルソナは誰がいつどこでという情報が曖昧
同じセグメントでもシーンによって意思決定やビヘイビアは変化する。
#pmconfjp
これは本当に思う。
シリコンバレーとかの事例も、収集するしためになる部分もあるけど、実際何が自分のプロダクトや組織にマッチするかを自分で見極めないとダメだなあと。
Googleってすごいけど実際にスタートアップ として立ち上がったのは20年以上前だしね、という見方というか。#pmconfjp
<ゼロからプロダクトビジョン合意(として感じたこと>
1,PMがまじで当事者意識をもって、ビジョンを一旦決める
2,ビジョンを推進すると事業に返ってくるよ!という確約を経営陣と握る(想いやPL含め)
3,ストーリーと事業への跳ね返りを定点観測する
の3点が大切だと思った
#pmconfjp
コミュニティはPMにもPMMにも大事。まず、コミュニティとは何か?オーディエンスとコミュニティは違う。オーディエンスは1:n。対してコミュニティはユーザー間の関係をマネジメントする。いかにユーザー同士の繋がりを作るか、強くするか。今日はコミュニティマネジメントの話。 #pmconfjp
製品の周辺のコミュニティやサポートも含めてプロダクト。コミュニティがあれば製品チームのユーザーへのアクセスが早くなり改善速度も上がる。新しい機能を出したときに、ユーザーからフィードバックをもらえる関係性になっているか?#pmconfjp
Productの責任は、自分が全てやるのではなく(コミニュケーションを含めて)助けを求めることができるPdMが一番強いのではないか?
誰にどう見られるのか?ではなく、UserやProductに対して真摯な行動をとることが責任を取ること。#pmconfjp #pmconfjp_2_2
サブスクのような、長期的にユーザーとの関係を構築する必要がある場合、製品に貢献するコミュニティ作りも含めて、プロダクト作りをするといい。
情報発信、フィードバックから迅速かつ精度の高い開発サイクルに繋がる。#pmconfjp_main #pmconfjp
コミュニティではオンボーディングが重要(価値/愛着/貢献を早期に感じてもらう)、プロダクトマネジメントスキルはコミュニティ醸成にも活かせる #pmconfjp #pmconfjp_main
オンボーディングが大事。
コミュニティが自分たちのチームだとしたら、採用もコミュニティへのオンボーディングだから似てる話多い。
#pmconfjp
コミュニティデザイン!
1. 戦略と目的(=>ビジネスとの統合)
→ないと「楽しかったね」だけで終わる
2. 構造(サイズ、人数、階層)
→最初は小さくはじめる
→多い場合はサブグループに分割★
3. 体験とプロセス/貢献
→早めにメンバーにあえて貢献を求める★
※★おススメ#pmconfjp
■コミュニティ作りの肝
・初期は熱狂的なユーザーのみで閉鎖的に
・人数増えると場に対するニーズに多様性が生まれるため、サブグループ化しある程度のサイズを維持
・ストーリー共有や、通過儀礼、メンター制度等、初動サポート
・組織貢献の定義を明確化し、価値発揮しやすい環境作り#pmconfjp
カスタマーサクセス、採用と組織化、そして、コミュニティ。それぞれにおいてオンボーディングというフェーズがキー要素になってきてる。じゃ、オンボーディングって具体的に何よ? と聞かれると答えられない自分がいる。ここもあとで勉強しよっと。#pmconfjp
まとめ: 1. コミュニティマネジメントは自社内から。戦略とビジネス価値との接続を考え社内を説得する。2. コミュニティ作りは自分から始めて渦を起こす。3. コミュニティのメンバーには積極的に貢献してもらえるように促し、デザインする。#pmconfjp
PMのスキルを明確化して組織をつくっていく。
必要なスキルが明確になることで、他職種や複数のファンクションが個人や組織全体レベルを補う&高め合っていき、いい事業/プロダクトにつながっていく。(勉強会が自律的に行われる等)
#pmconfjp
NewsPicksはプロダクトマネージャーが10名いる。あるべき姿としてうちだと何人必要なんだろう。#pmconfjp
企業が欲しいのはプロダクトマネージャーではなく「プロダクトマネジメント」であって、
プロダクトマネジメントはプロダクトマネージャーだけのものじゃないよ、って話かな#pmconfjp
質問1:プロダクトマネージャー人材の役割と需要
杉浦: ミニCEO。特化した強みがありつつ、プロダクトにコミットできる人。特化する方向にこだわりはない。PMは現在10名ほどで2名のリーダー組織。
土屋:組織内ではメインはPJM。立場上PDMは相手企業にあるので、右腕のような存在。#pmconfjp
グッドパッチ土屋: 失敗談として、PDMを外部から雇ったが、会社の文化の理解度や創業者との信頼関係を上手く作れるかに課題があり上手くいかなかった。逆に新卒で入社して真っ白だったが、上記の課題をクリアしながら徐々に育っていった成功事例もある。#pmconfjp
プロダクトマネージャーをどうオンボードさせるか?
ニューズピックス杉山:丸投げして上手くいくものではない。プロダクトこれで、後はよろしく、では無理。人それぞれの強みごとにサポートを変える。責任範囲も絞る。
及川:PMは採用して成功ではない。入社して成功体験があって始めて成功。#pmconfjp
グッドパッチにいるUXデザイナーやサービスデザイナー、デザインストラテジスト、PMは、クライアントにいるPOやPdMの右腕として評価されるメンバーが多いです(中の人より)#pmconfjp
意思決定のポイントや判断基準、優先順位の感覚が近くなるまで一緒にやる
わからなくはないけど、そこを超える人材はどうする??みたいなところはある
#pmconfjp
デジタル側かビジネス側か、どちらにしても、半年から1年の並走が必要。視座や視野の状勢、期待値調整、ロードマップの組み方が似てきたなと思ってきたら委譲する。自分のミラーコピーを作るという話。価値感が近い人を採用する。...って経営における後継者育成と同じやな。#pmconfjp #pmconfjp_main
グッドパッチ土屋:基本、半年から1年併走が必要。創業者または前任者がどこを見ているかを伝えていくことが必要。感覚が揃ってきたら徐々に委譲していく。根底の価値観が揃っていないとそもそもキツい。1on1などの継続的な対話。#pmconfjp
pdmが新しくプロダクトに関わる時、ともに並走し1つの成果を上げるまでがオンボーディング。
わたしは伴走者が居なかったので、期待値のズレに気付くのに半年かかりました。。#pmconfjp_main #pmconfjp
PdMの採用
■失敗事例
外部からPdMを採用したが、なにをするかなぜするかを語れず、プロダクト成長が止まった。
■成功事例
内部からPdMに若手を着任させたときに信頼貯金&信頼残高があることでチームもプロダクトもグロースした。(真っ白なキャンパスもあり)
信頼残高重要!
#pmconfjp
コミュニティ形成の話は興味深かった。
サブスクプロダクトの相性がいい。
・プロダクトのフィードバックと質が高まる
・辛辣な意見も聞ける。
・ユーザ間の話が見える
・当日中に機能のフィードバックがもらえる
・迅速な改善で将来もよくしてくれそうと感じる#pmconfjp
誤解を恐れずに言えばPdMって「本質を常に考え続けて、ものすげーコミットするマン」なんだよな。スキルはそれを助けるためのもの。表層的なポジショニングとしてのPdMはメッキすぐ剥がれるんですよ。プロダクトの規模に関わらず。#pmconfjp
#pmconfjp 初めて参加したけど、day1はどちらかというとこれからPdMを目指す人向けの内容が多かった気がする。day2はより現場向けなのかな。
PdMはユーザーの満足度にコミット
PO(事業責任者)はその上でどのようなビジネスを組み立てることにコミット
両者は並列に配置されている#pmconfjp
企業視点でプロダクトマネージャーの需要やオンボーディングの話があったけど、個人側の視点で捉え直すと、
・企業や事業、プロダクトのミッション、ビジョンへの共感度の高さ
・経営層など上位レイヤーとの価値観の一致
・視座、視野、視点を盗めるか
あたりが活躍するPMのポイント#pmconfjp
Goodpatch 土屋さん
---
PdMには「なんとかする力(突破力)」が必要。
スキルはどこかしら足りていないのは当たり前。なので、短期間で状況把握をしてなんとかする力がベースとして必要。
PdMは総合力。
ただ、それは自分で全部やるという意味ではなく、巻き込みながらなんとかする力が必要#pmconfjp
増井のメソッド
1.自分が作りたいものを作る
2.コロンブスの卵が好き(簡単で有益なもの)
3.誰もが使えるものはプロダクト化
プロダクトイン:自分が使う便利なものでよのなかにもウケるものをプロダクトにしている。ユーザー調査を元にしていない自己中心設計。#pmconfjp
「ビジネスのためにプロダクト開発をする」っていう発想じゃなくて「自分が使いたいものを作る」っていうプロダクトファーストな思想だからこそなせる自由さ。
商業開発だと忘れてしまいがちな考え方に立ちもどれる話。 #pmconfjp
newspicksで定義しているPdMのスキル
---
1. トライアンドエラーを繰り返す(デザインシンキング的な)
2. ユーザーリサーチからインサイトをディープに知るインタビューなどのスキル
3. マーケットでこのプロダクトがヒットできそうかを科学的に分析できるスキル
---#pmconfjp
というか、現時点でPdMと同じ動き方はできるはずで、まずは関係のあるメンバーが何やってるか全部把握してみればいい #pmconfjp #pmconfjp_2_1
「自分がこれが無いと死んじゃうぐらいの勢いで作らないとだめ」 #pmconfjp #pmconfjp_main
ドッグフーディング中は音楽聞いちゃだめらしい(右脳を使ってしまい発想が阻害されるからw)#pmconfjp_main #pmconfjp
長屋発想(長屋に住めるかという制約条件をつける)、そもそも発想(そもそも何を解決したいのか)、ドッグフーディング発想(ひたすら使う)、とかよく使う発想法はある。昔、発想法を一回色々と集めたとのこと。 #pmconfjp
![]()
発明、ドッグフーディング、プロダクトマネジメント#pmconfjp
プロダクトイン、自己中心設計
・自分が使いたいものをつくる
・コロンブスの卵が好き(簡単で有益なもの)
・誰もが使えるものはプロダクト化
POBoxやフリック入力は成功、Gyazoはまあ成功、Scrapboxはこれから。#pmconfjp
![]()
プロダクトイン、自己中心設計
・自分が使いたいものをつくる
・コロンブスの卵が好き(簡単で有益なもの)
・誰もが使えるものはプロダクト化
POBoxやフリック入力は成功、Gyazoはまあ成功、Scrapboxはこれから。#pmconfjp
日々のドッグフーディングによる問題の発見と解決。いい問題の発見といい解決が重要である。UI研究は論文の数が多いが評価者が少ない #pmconfjp
![]()
日々のドッグフーディングによる問題の発見と解決。いい問題の発見といい解決が重要である。UI研究は論文の数が多いが評価者が少ない #pmconfjp
発想フェーズと運用フェーズでは異なる才能が必要で、発明家兼PMは少ない。 #pmconfjp
![]()
面白いものの発想
高速プロトタイピング
ドッグフーディング,フィードバック
真面目実装#pmconfjp
新しい便利なサービスを世の中に広めるためには、
(1)サービスを思いつく
(2)プロトタイプを作って感触を確かめる
(3)周囲を巻き込んで利用してもらう
(4)高品質な実装を行なって公開する
(5)ユーザの声を聞きながら継続的に改善を続ける
という長いステップが必要である。#pmconfjp
増井さんにとってのプロダクトマネジメント=発想+プロトタイピング+ドッグフーディング #pmconfjp #pmconfjp_main
"発明、ドッグフーディング、プロダクトマネジメント"
・自分が使いたいものを作る
・ユーザー調査しない
・「自己」中心設計
・無いと困るものを作る
・発想法も使う
・音楽は聴かない
・問題発見できたら半分終わり
・できる限り認証ナシ
・簡単に使える
・簡単に作れる
...理想!#pmconfjp
最後、個人でプロダクトマネージャーを目指すには→エンジニアは素養があるので、得意なところから学ぼ。自分でプロダクトをつくって学ぶのがいいのでは。他、求人側がプロダクトマネージャーを理解していないリスクもあるので気を付けて。など。あっというまの30分だった。#pmconfjp #pmconfjp_2_1
土屋さんの話の中で出たプロダクトマネージャーに1番重要なのはどのスキルに強みがあるとがでなく統合力、突破力、総合格闘技で勝つ、みたいな話が1番納得感があった。 #pmconfjp
良いチームからしか、良いプロダクトは生まれない。
良いチームを作るにはリーダーとの信頼関係が必要だ。
信頼関係を作るには、ビジョンが必要。
良いビジョンを語ると、良い人が集まる。#pmconfjp
PMはなんでも屋のminiCEOだということが今日は何回も出てきたなー #pmconfjp
プロダクトマネージャーカンファレンスに来ています。
初回のkeynoteが非常によかったので爆速でまとめてみました!(主にデザイナー向けの観点でまとめています。)
会場に来れなかったデザイナーの皆様、よかったら見てくださいーhttps://note.mu/osi_ire/n/nbbfb1bdba15f …
#pmconfjp
LINE社二木さんの「ジレンマは必ず解消出来る 」「HOWを2回繰り返すと、ジレンマは同じ意見にたどり着く」という話面白かった。
コンフリクトしているようで実のところ目的は同じ、というのはよくあることなので、こうした思考プロセスがチームで共有できているとよさそう。#pmconfjp
でも自分が絶対に欲しいプロダクトを作るってめっちゃ大事だよね。プロダクト愛と信じ力がプロダクトを良いものにする #pmconfjp
いろんなセッションを聞いて、やっぱりtrustがキーワードっぽいなあと感じる。
日本語の"信頼"に近いんだろうけど、個人的にはそれよりも強いニュアンスに思えて、少し腹落ちしてない部分もあるけど。#pmconfjp
エンジニアの立場で参加したのですが、プロダクトチームのつもりがいつの間にかフィーチャチームになっているような気がして耳が痛かったのと、ともかくInspired読みます。という初日のざっくり感想。 #pmconfjp
プロダクトマネージャーに必要なこと
・業界の専門知識
・チームとの協調性
・カルチャーへの適応性
・情熱
例えば朝起きて仕事に行こうと思ったときにハッピーでないなら会社に来ないほうがいい。
自分の好きな人達と、自分の好きなサービスを創りたいと思う情熱が大切。
#pmconfjp
顧客視点が一番大事。
ただし、
顧客の「〇〇がほしい」を
「何が必要なのか?」
に変換するのが私達の仕事
早い馬が欲しい人達に車を提供する
#pmconfjp
顧客から要望を聞きすぎるのも良くない。なんでそういった要望を出したのか?それを深く聞く。そのうえで、解決策を提示する。あくまで、プロダクト全体のビジョンや方向性からそれないで。全体最適化の話。 #pmconfjp
顧客視点が重要である。しかし顧客の言う「hogehogeが欲しい」を「必要な体験はなにか?」に変換するのが仕事である。#pmconfjp
創造性を産み出すサイクルを日々の成長で広げること。アーティスト、科学者、エンジニア、デザイナーとしての資質を広げる。また、顧客起点で考えること #pmconfjp
コアバリューだけをひたすら追求しきるって普通に不安になるし、一定水準までいくと次のレベルに上がるためのコストも比例して上がって意思決定は難しくなる中、1点を極めたってのが本当に凄い。「何を提供するのかの絞り」と「目指す水準の高さ」が噛み合ってないと組織で実現できなそう。#pmconfjp
#ベルフェイス 吉本さん @t_yoshimoto0107
各TのKPIが違う中で、プロダクトの指向性を変える(自社HPにタグ埋め込み→ベルフェイスサイト上に誘導)ことで、各Tの利害を一致させ、チームが自走できるようにして、プロダクトを成長させた。
PdMではなく、そのトライアングルの機能が必要。#pmconfjp
今日はTrustにつきるんだけど、
最初のTrustもあれば継続的なTrustもあるから、それぞれどう実現していくかが #pmconfjp 後の課題だな〜
(個人的には特に継続的なほう)
"Speed of now" これはシリコンバレー界隈でもめっちゃ意識されている。ユーザーがプロダクトに向き合う「時間」はある種の投資(Investment)。だからこそReturnがきちんと感じられないとユーザーはすぐ逃げる。最近のよくできたB2BプロダクトをConsumer-gradeとよく呼ぶのにはそんな背景が。#pmconfjp
早速1日目の参加レポート書きました。明日も期待。
プロダクトマネージャーカンファレンス 2019 1日目まとめ|高松智明 @t14i_ #note #pmconfjp https://note.mu/t14i/n/nf4a54a621573 …
今日の話を聞きつつ、これまでの経験からPOとPdMをあえて定義するなら以下
---
PO(事業責任者):
経営の言葉を事業の言葉に変換して事業戦略(ビジネス)を組み立てる役割
PdM:
事業の言葉を理解しつつ、ユーザーの言葉を事業戦略にフィードバックしたりプロダクトへの実装をリードする役割#pmconfjp
納得感ある
・マネージャーのタスク
①採用
すぐれた人を採用する
②コーチング
人に対しての能力を高められる
③チームの目的を設定する
エンパワーメントするための目的
・PMの真の仕事とは「TRUST」である#pmconfjp https://note.mu/osi_ire/n/nbbfb1bdba15f …
「PMの真の仕事はチームを信頼すること。チームは、機能を実装するのではなく、ユーザーの問題を解決する。」と書いてて良い。PMが全て指示すると、社内合意することがゴールになる。
「普通の人、特別な結果」 byプロダクトマネージャーカンファレンス2019_議事録 #pmconfjp https://note.mu/osi_ire/n/nbbfb1bdba15f …
会社の規模が大きくても小さくても抱えていることは同じなんだなぁ。
組織のフリクションを想定、意識しながら経営、プロダクト、セールス、CSの意見汲み取って改善繰り返していいもの作って結果だす。
関係各所巻き込んで成果出してみんなハッピーになるつよつよマンになるしかないw
#pmconfjp
freeeさんの発表も良かった。ストーリーテリングはさっそく明日から実践しようと思えるいいTips #pmconfjp https://twitter.com/satomikko94/status/1194117623404879872 …
コミュニケーションしなくていい環境とか作ったらアウトって経験があるから僕もメッチャ共感した。#pmconfjp https://twitter.com/satomikko94/status/1194199214659493888 …
PMはカメレオン。これよく分かる。カメレオンになるために沢山の知識と経験と妄想力が必要。 #pmconfjp
心に刻んだ
「失敗というのは、避けられたはずで、学びが残らず、何も解決せず、時間やマインドシェアを奪うもの」である。それはなにかというと「日々の易きに流れる惰性の積み重ね」だと思う。易きに流れないことが大事
10xのための逆説 #pmconfjp | Yamotty (@yamotty3) https://yamotty.tokyo/post/20191112_pmconf/ …
話を聞けなかった タベリー@yamotty3さんの「定説に対する逆説」記事、QA含めとても有り難い。
結論、定説は当てはまらないので、
自分のユーザーと向き合い、考え、Un-concensus right(他の誰もが同意しない、自分だけが知る事実)を見つける・賭けるのが最も早く、成功に近い道と考える#pmconfjp https://twitter.com/yamotty3/status/1194182919637458946 …
今日の #pmconfjp のネットワーキングパーティーの席でOKRやプロダクトロードマップについて聞かれた際にもお話したのですが、プロダクトはその企画から開発〜運用まで一気通貫のぶれない方針が必要です。// はじめてのPRD https://www.slideshare.net/takoratta/prd-192302662 …
かの名著InspiredのMarty Cagan氏の講演を聞けただけでも非常に意味の深いカンファレンスでした。
『PMの仕事は信頼である』
組織で働くためのエッセンスが詰まった、
PMだけでなくチームではたらく人全てに聞いて欲しい素晴らしい講演でした。#pmconfjp https://note.mu/osi_ire/n/nbbfb1bdba15f …
本日はpmconf、コミュニティマネジメントの講演学び多かった。
特に「コミュニティに貢献した人はそのコミュニティをより好きになるので、貢献できる仕組みを作る」てのはとても刺さった。
あとはPMMの働き方やスキルセットについて深く聞いてみたかったなー#pmconfjp
https://www.slideshare.net/takaumada/startup-community-management-2-design …
UXエンジニア並にプロダクトマネージャも何者か捉えがたいなあ。
何となく分かったことは「人をマネージするわけではないけどモチベートする役割ではある」ってことだったけど、「モチベートする=感情をマネージする」なのでは?って疑問が。#pmconfjp
と思ったら、今日のプロダクトマネージャーカンファレンスでは、組織・人は見るなという話が多かったですね。
マトリックス型組織がとても増えている様子でした。#pmconfjp
本日のProduct Manager Conference 2019 Day1について、グラレコ風メモ付きでまとめました! #pmconfjp / “Product Manager Conference 2019 Day1に参加してきた - @satomikko94.b” https://htn.to/2u4vJ2Wpa5
PMに必要なのは信頼貯金って各所で言われていた。自分も日頃から大切にしてるが貯金の仕方がわかってないメンバーには小さい成功体験を積ませられるよう工夫するのが自分の役目だと思った。社内のリファラルってバカにできないし。 #pmconfjp
SaaSに関わる文脈メインですが、PMカンファレンスのハイライト書いてみました。https://note.mu/kota_sasaki_shr/n/n2b4feffa3447 …#pmconfjp
本日参加したpmconfを「新米PM」という視点でまとめました!#pmconfjp
新米PMは何から始めれば良いか~pmconf-day1の学びから実践へ-|YoshiD @yoshiD0301 #note https://note.mu/yoshi_d/n/n979b71e1c135 …
1日目のメモを読み返してまとめてみた
・PMは信頼(Trust)の獲得をして結果に対する責任と意思決定の自由を勝ち取る
・ユーザーとプロダクトと向き合い、ステークホルダ間のジレンマを解消しながら、定説に頼らず何とか突破していく
明日も学ぼう
#pmconfjp
4000字くらい。
あとで見返す用。
pmconf2019 一日目メモ - nickotaのあうとぷっと。 http://nickota.hatenablog.com/entry/2019/11/13/003421 …#pmconfjp
プロダクトマネージャーカンファレンスに来ています。
初回のkeynoteが非常によかったので爆速でまとめてみました!(主にデザイナー向けの観点でまとめています。)
会場に来れなかったデザイナーの皆様、よかったら見てくださいーhttps://note.mu/osi_ire/n/nbbfb1bdba15f …
#pmconfjp
2日目もしっかり追いたい。