11月12日・13日の日程で開催されている pmconf こと、プロダクトマネージャーカンファレンス 2019。
現在僕は仕事でもプロダクトオーナーシップに近いところにいたりして、「プロダクトマネージャー(PdM)」への関心が急激に高まっていたりする。趣味開発プロダクトにおいては常に自分がプロダクトオーナーであるとも言えるし(?)。今回はもろもろ噛み合わず参加を見送ったのだけど、インターネット上に溢れでてきた情報からだけでも最大限インプットしたいということは、イベント開催前から思ってた。
これは、Twitter の「話題を検索」で #pmconfjp を検索した結果の「最新」で見られるものを 2019-11-13 9:00 AM 時点で全部追ったついでにまとめたメモ。やはり盛り上がっていたのか、相当な数のツイートがあった。もし資料の取りこぼしがあったらぜひ @a_know に教えていただきたいです。
登壇資料(順不同・2019-11-13 20:18 追加)
さっきのエムスリーの資料ですhttps://t.co/NmSkN2isRD #pmconfjp #pmconfjp_2_3
— nishiba (@m_nishiba) 2019年11月12日
14:50 から登壇します(しました)!類似資料の一部はこちらから。コミュニティマネジメントです。https://t.co/CewPtPU3Jp https://t.co/Hew70T6qKI #pmconfjp
— Taka Umada 🐴 (@tumada) 2019年11月12日
同じ時間の別セッションのタイトルにサブタイトルを被せるというチャレンジをしたのは私です。
— 吉本 猛 @bellFace 経営企画室長 【エンジニア、PdM採用強化中】DMください (@t_yoshimoto0107) 2019年11月12日
会場内が優しい方ばかりで助かりました。
本日の発表内容アップしましたー。https://t.co/D4bT6FpE3T#pmconfjp #pmconfjp_2_3 https://t.co/gQN0iUDrg9
現在開催中の #pmconfjp にて、執行役員 二木の「LINEにおけるお金とユーザーのジレンマ」の登壇資料を公開いたしました。
— LINE Developers (@LINE_DEV) 2019年11月12日
また展示ブースでは各サービスのLINEのPMと話せる時間を設けています!是非遊びにきてください。⁰https://t.co/ThY3m2iYcj
#pmconfjp 1日目 Pairsの「作り手の想いとユーザーをつなぐための悪戦苦闘」の資料です。会場の皆さんに暖かく迎えていただき楽しくお話ができました。ありがとうございました。
— Yuuki KANADA (@Kanadadada) 2019年11月12日
15分では話したいこと足りず、あと2セッションくらい持ちたい気持ちですwhttps://t.co/ZIUwlOMchf
本日プロダクトマネージャーカンファレンス2019でお話しさせていただいた、#VRoid 事業責任者の佐藤(@machie)の講演資料を公開しました!https://t.co/0z3y2ZBwS1 #pmconfjp pic.twitter.com/U4f4y4ViHg
— ピクシブ株式会社 pixiv Inc. (@pixiv_corp) 2019年11月12日
本日登壇のフォローアップ記事出しました。
— Yamotty | 矢本真丈 (10X) (@yamotty3) 2019年11月12日
オファーいただいた @mizuki_tannoさん、運営の皆様、改めてありがとうございました。明日も頑張って下さい!
"事前に募集したQ&Aへの回答もできなかったため本稿はフォローアップ記事となる。"
--
10xのための逆説 #pmconfjphttps://t.co/Pf0HaTnlRg
昨日の #pmconfjp でのCTO増井( @masui )の講演資料を公開しました!ご覧いただいた皆さん、ありがとうございました!https://t.co/smeX0AlK0k
— Nota (@notainc_jp) 2019年11月13日
プロダクトマネージャーカンファレンス Day1で登壇させて頂きました。ありがとうございました!
— オカダ ヤスヒロ | Product Manager@エン・ジャパン (@middleOkada) 2019年11月13日
登壇時のスライドをシェアさせていただきます!質問もいただいたので、それも簡易的にまとめました!https://t.co/m1IgsGSYBC#pmconfjp
昨日 #pmconfjp のコミュニティマネジメントの資料を整理してアップロードしました! コミュニティを始めるときのヒントや社内説得資料としてお使いいただければ嬉しいです。「PMとPMMのためのコミュニティマネジメント: プロダクトの開発と展開をコミュニティが加速させる」https://t.co/2yS8R2zA96
— Taka Umada 🐴 (@tumada) 2019年11月13日
www.slideshare.net
その他、参考になりそうなページなど
- エムスリーでプロダクトマネージャーとして働くということ(デジカル編) - エムスリーテックブログ
- プロダクトマネージャーに必要なテクニカルスキルを定義してみた話。|岡田康豊(Yasuhiro Okada) | プロダクトマネージャー|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
- 「普通の人、特別な結果」 byプロダクトマネージャーカンファレンス2019_議事録|TSUYOSHI(デザインマネージャー)|note
自分の感想とか(2019-11-13 20:26 追記)
- 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で獲得していけるアニマルである必要がある
- 増井さんの資料も見つけた!
- 「コロンブスの卵が好き」わかる〜〜
- 「発明」やっぱ良い、「発明家」名乗りたすぎる......
- 「バックグラウンドで考え続ける」この感じもわかる......
- Helpfeel 、興味でてきた
- ドッグフーディングをみんなでできてるとストーリーを共有しやすい、というのはありそう〜
- プロダクト内の顧客だけでなくマーケットを。見ないとなぁ
- もっとデータを意識しないとなぁ
- 施策や試み、それが間違い・失敗だったかどうか?という判断をおこなうタイミングを設けていなかったり、その判断をおこなうことができない(判断に必要な材料を揃えられない・その基準が明確でない)、というのも問題だよなぁ
- すべてを鵜呑みにはしない(これを材料として、自分のチームとしての最適解を探りたい)にはしても、アンチパターンとされているものだったり注意すべき点としてあげられているものについては、先人からのアドバイスだと思って咀嚼したい
- 愛とか情熱とか必要なのかどうか、と疑問に思ったことがあって、必要なんじゃないかと思っていたが、それが裏付けられたような気持ち。
- ただし、顧客対話との両輪でもある、というのは忘れないようにしないと。。
客観的にみても自分はプロダクトのことを考えられてるほうだと思うんだけど、それはそのプロダクトのことが熱狂的に好きだからだと思ってて、世の中のプロダクトのことを考える役割の人もまた、自分のプロダクトのことを熱狂的に好きなもんなんだろうか。(必ずしもそうでない気がしている。)
— a-know | Daisuke Inoue (@a_know) 2019年7月27日
参加者のみなさんの感想 ほか、印象にのこったツイート(順不同)
2つのチーム
— h (@hyt_ina) 2019年11月12日
- featureを作ることに責任を持つ
- customerの問題解決に責任を持つ
強いチームは後者#pmconfjp
#pmconfjp エンパワーされたプロダクトチームを作るかどうかは最終的には経営レベルの判断。そうでない企業にいると、できることは限られるか時間がかかってしまう。プロダクトチームが主体的に成果を上げることで少しずつ文化を変えることはできるかもしれないが、多くの場合は転職したほうが早い。
— project dot (@projectdot1) 2019年11月12日
"問題解決するベストの方法は何かを考えるのがプロダクトチーム"
— KANE@Podcastの妖(精|怪)&エナジャイザー (@higuyume) 2019年11月12日
この意識を広めて行くのは大切だ。
#pmconfjp
あなたのチームが強化されている?
— Nao Haida (@naohaida) 2019年11月12日
1.競争力があり、キャラクターのある人で構成され、必要なスキルセットが整っている
2.チームは解決すべき課題が割り当てられておりその問題を解決する最高の方法を決めることができる
3.チームは、顧客またはビジネス課題を解決することに説明責任がある#pmconfjp pic.twitter.com/gwY7DFbAY9
スピードと顧客ファーストを支えるのが自律的なチーム。
— Nao Haida (@naohaida) 2019年11月12日
早く持続的に動くのに最適。顧客に近いところでチーム内で意思決定。プロダクトプランやロードマップを決めるためのコミットメントやマネジメントミーティングなし。チームは正しい結論を出すか、間違いから学ぶと信じている。#pmconfjp pic.twitter.com/VVbSGy5pTA
"Learn from wrong ones" -> 間違いを隠しちゃダメゼッタイ。
— Haruki Sonehara / 🇺🇸 Head of Product @ シリコンバレー (@Haruki_Sonehara) 2019年11月12日
間違いから学ぶというのは、反省して萎縮というよりもむしろ「早く動くため」#pmconfjp
この考え方が、経営者や創業者へのコーチングがワークしていたことに注目すべき
— Landon Hong | メルカリJP (@Landon_kousan) 2019年11月12日
Product teamがみずからFeature teamになっていく組織はたくさんあります。フェーズの問題として片付けられることもしばしば
もっと上流から意識をかえていかないといけない
まとめありがとうございます#pmconfjp https://t.co/ihVlhzSIr2
「本当のプロダクトチームの判断にマネジメントの承認はないはず。それが一番スピード感があってサステナブルで正しい判断ができる組織になる。なぜなら、顧客の一番近くにいるのはチームだから」 #pmconfjp
— ワタナベモリヲ (@watanabemoriwo) 2019年11月12日
自律的なチームに判断する自由を。ただし、判断には常に顧客のインサイトやデータによるバックアップが必要。 #pmconfjp
— ワタナベモリヲ (@watanabemoriwo) 2019年11月12日
Transferwiseさん結構過激なマネジメントしてる。
— 高松 智明 | Workyspace (@t14i_) 2019年11月12日
・速さとサステナビリティを重視した自治的なチーム
・カスタマーのより近くで意思決定
・マネジメントミーティングとかプロダクトストラテジーとか無い
・信頼する
・正しい決定をするか、間違ってもそこから学べば良い#pmconfjp pic.twitter.com/MiNgabrjR4
・自主性を高めるために権限移譲を進めることは大事です
— けーた (@kee_tap) 2019年11月12日
・任されたら物事を背負い始めて、自分で考え始めます
・が、初めての能動的思考なので、最初は筋が良さそうな方に並走する必要があります(ここやらないとただの失敗体験)#pmconfjp
PMを雇うときの条件
— サエキミルテ@Radiotalk PdM (@_msaeki) 2019年11月12日
1会社を経営できるスキルをもつ…!#pmconfjp pic.twitter.com/CoVB53x7w9
意思決定の自由を持つというのは、責任を持つということ、カスタマーインサイトしているから説明できる。だからプロダクトチームが権限を持つ必要があるのだと思う...けど、やっぱり経営との関係がきになる。海外の方がトップダウンに動くイメージがあったけど。#pmconfjp
— Ryo Miura (@ryo_miura_it) 2019年11月12日
プロダクト原則をしっかり定義して、ユーザーインサイトとデータに基づいて意思決定しながら学べばカオスにはならないという方針のよう。
— 高松 智明 | Workyspace (@t14i_) 2019年11月12日
・価格が安い
・スピードが速い
・使いやすい
・色んなところで使える
原則この4つを良くする方向、って決まってるなら確かに迷わなさそう。#pmconfjp pic.twitter.com/j4qGrZ0UTm
チームに自主性を持たせることがスピードや解像度の高い解決策を出すために必要。チームに自主性を持たせるには、情報の透明性や意思決定権の譲渡、共通言語として語れる顧客像の目線合わせが重要と言う理解
— Yabe Yusuke (@tarobeeeee) 2019年11月12日
#pmconfjp
スクラムでも時々でてくる言葉、”Product Discovery"って、"要件定義"よりもいい言葉だ。それは誰かが決めることではなく、皆で発見するものだと。プロダクトの開発とは、作られたロードマップを行くことではなく、繰り返される実験から導き出されるものだと。#pmconfjp
— ちくちゅう@フリーランスPdM (@chiku_chu) 2019年11月12日
Transferwiseの場合プロダクトの性質上グローバルに広がることで価値が上がるので、各国の拠点が自治的に動くのは相性が良さそう。
— 高松 智明 | Workyspace (@t14i_) 2019年11月12日
自治は責任が伴うこともチームで同意が取れてるんだろうな。
ここでもtrust(信頼すること)とoutcome(結果を出すこと)がキーワードとして上がってきた。#pmconfjp pic.twitter.com/KdHGfbDM57
・PMあるいはプロダクトチームに戦略の意思決定の自由と結果に対する責任を与える
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2019年11月12日
・ユーザーが求めることが明確で共通認識になっていればカオスは生まれない
・間違いから学ぶ
#pmconfjp #pmconfjp_main
- プロダクトマネージャーを雇用する場合の条件
— Shoya Tezono (@yan_tzn) 2019年11月12日
- 事業も出来る人を雇用する
- 意思決定もできる
- 会社を自ら経営できる人材であるべき
- 政治的なゲームを楽しむ人でない
- チームとして仕事が出来る人
- ディスカッションして進められる人
#pmconfjp pic.twitter.com/eX5BvI4gdp
これは間違いなく真理。経営層の信頼を失ったらもうPdMにやれることなんてないです。
— 笹口直哉@キャディのプロダクトマネージャー (@sasaguchisan) 2019年11月12日
だからPdMは経営層の期待に応えなければいけないし、期待値を超えたパフォーマンスを出していかないといけないと思っています。#pmconfjp https://t.co/URQd7aQVJR
■PdMはカメレオンやで話
— けーた (@kee_tap) 2019年11月12日
・大きい組織のPdMはよりビジョナリー性質を要求されるで...
・一方、スモールな組織だと推進力を要求されるんやで...
・かつ、フェーズ(企画~リリース~グロース)に応じても発揮スキルが変動するんやで...
→とにかく、PdMは成功に導いたらええんや...!!!#pmconfjp
https://twitter.com/hibana_co/status/1194108115207249920
https://twitter.com/hibana_co/status/1194108117170229249
https://twitter.com/hibana_co/status/1194108118604664832
https://twitter.com/hibana_co/status/1194108124644495362
PMはジレンマ回収役。デザイナーは画面Aが良くて、開発が画面Bがいい。 など🐻ジレンマをどう解消するかを考えるのが最もおもしろい作業 #pmconfjp pic.twitter.com/6nJckUazd7
— akane (@akane_256) 2019年11月12日
これはよくある現場の優先順位付け(笑
— Sumida🔥新規プロダクト開発中 (@walkersumida) 2019年11月12日
難しいものは後にやりがち。
こうさせないためのプロダクトマネージャー。#pmconfjp pic.twitter.com/IV2cteWLgr
ジレンマは認識の違いから発生するとのこと。
— tomohi (@tomohi_pm) 2019年11月12日
対立構造の根本原因を正しく認識することで目的を共通化し、ビジョンや方針によって共闘関係に変えていくことができる。#pmconfjp
LINE二木さんのセッション良かった
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2019年11月12日
「ジレンマの解消自体がクリエイティブ」っていい言葉
ジレンマ敗北度チェックは週1でやろう
・仕様を書くだけの人になっていないか
・判断を上に求めて合議制で決めようとしてないか
・人のせいにしてないか
・feature teamになっていないか?
#pmconfjp
・仕様を書くだけの人になってない?
— Kohei Kadowaki (@kadoppe) 2019年11月12日
・常に判断を上に求めて合議制で決めようとしてない?
・他人や他部署のせいにしてない?
プロダクト開発におけるジレンマに敗北していないかチェックリスト。プロダクトの成長を邪魔しちゃう要素。自分もあるし、他の人も耳が痛くなりそー。 #pmconfjp
「ジレンマ解消自体がクリエイティブ」って素敵な視点だなぁ。 #pmconfjp
— GETSUKIKYU(りん) (@getsukikyu) 2019年11月12日
ビジョンが見えない・実現に向けて粘り強く取り組める環境がないと、PMは機能できなくなるのかも。
— 石田智子 / Designer🦄 (@tomokoishida19) 2019年11月12日
「ジレンマはHowを2回繰り返すと同じ目的にたどり着く。
大抵のジレンマは解消できる。
そしてそのジレンマをどう解消したかが、プロダクトのユニーク性になる」#pmconfjp pic.twitter.com/RufrY4Yx6C
LINEにおけるお金とユーザーのジレンマ
— Shoya Tezono (@yan_tzn) 2019年11月12日
PMに限らずですが、要望をそのまま受け取るだけでなく価値があるのかしっかり考える癖はつけていきたい
#pmconfjp pic.twitter.com/J8vyY7eFqP
LINE、PMが機能してないと何が起きるか「諦める:一番楽。意外とこの時点で止まってる人多い」
— かしたか (@kashitaka1118) 2019年11月12日
これわかる。重要な課題なのにずーっと放置されてることがプロダクトにあったりする。
#pmconfjp
https://twitter.com/bash0C7official/status/1194116372545978369
https://twitter.com/bash0C7official/status/1194117113763385344
freee 執行役員 岡田さん
— akane (@akane_256) 2019年11月12日
バックログの縮小均衡
闇雲にバックログを追いかけるだけのプロダクトは陳腐化し、誰のテンションもあげない。社内でも存在感が薄れていき、縮小銀行に陥る#pmconfjp
プロダクトオーナーの認識が自分とは逆。プロダクトマネージャーが意思決定者でプロダクトオーナーが意思決定の中でプロダクトバックログを管理する役割だと思ってる。
— tomohi (@tomohi_pm) 2019年11月12日
まぁ役割認識がチーム内で合っていれば、どちらでもいいとも思うけど。#pmconfjp #pmconfjp_2_1
PMが複数いるとその責任範囲ってどうなるんだろう。一般的なPMより権限や責任領域は少なくなって判断権限がないPMとか生まれそう。どうしてるんだろ #pmconfjp
— はち (@PassionateHachi) 2019年11月12日
M3さんのバックグラウンド毎にpmわけてるのは確かに。感がある #pmconfjp
— Eiji Hachiya (@hachi_eiji) 2019年11月12日
プロダクトマネージャー、企画バックグラウンドの人と、エンジニアバックグラウンドの人がいるのはそのとおりだな。何でもできることを期待してしまいがちだけど、そうすると、プロダクトマネージャーしんどいよね。#pmconfjp
— Koji Shiraishi (@shiraco) 2019年11月12日
そもそもPMが複数いた方がいいよねって言う考えのスタートが気になる。どうしても Scrumでやってる人間からすると不便さの方が多く見えてしまう #pmconfjp
— はち (@PassionateHachi) 2019年11月12日
PMとしてストーリーを語ることはなぜ大事か?1.ストーリーは話したくなる 2.ストーリーは記憶に残りやすい
— Nao Haida (@naohaida) 2019年11月12日
結果として、・ビジョンがボトムアップでムーブメント化して機能しだした・バックログに意味が宿り意思決定がしやすくなった#pmconfjp pic.twitter.com/pkNbeZCLa5
ファクトをストーリーにすることでビジョンが浸透してバックログにも意味が宿り意思決定しやすくなる。#pmconfjp pic.twitter.com/23MDVDo1Js
— まいどる🃏devPM運営中🤹🏻 (@maidol_28) 2019年11月12日
ストーリーを持たないビジョンは絵にかいた餅になる。(誰も意識できない/形骸化する)
— けーた (@kee_tap) 2019年11月12日
ストーリー化すると、記憶に残り、皆が意識できるようになる。
課題をストーリーで語る習慣が身につくと、「何故それをやるのか?」を開発メンバーが理解でき(適切に取捨選択され)、良い循環が回る。#pmconfjp
ストーリーは計測し続けること。ストーリーのオチで達成している世界観に寄与するKPIを計測し続け、オチの世界に近づけていくこと。#pmconfjp pic.twitter.com/kRBhWm4kuy
— Nao Haida (@naohaida) 2019年11月12日
物語はいかに当事者になって語れるか。
— Aya Nishiwaki(Takahashi) (@tkhsaya) 2019年11月12日
あるある。と共感を呼べる内容。利き手を惹きつけられるフックになると印象に残る。
物語の最後に主人公に何らかの変化が起こっている。#pmconfjp pic.twitter.com/5FYKqhcoH0
ピクシブのプロダクトマネージャー
— Shoya Tezono (@yan_tzn) 2019年11月12日
- サービスの成長に対応する①
- 強味の異なるPMでネットワークを埋めあう
- PMを複数立てる
- サービスの成長に対応する②
- プロダクトオーナが複数のPMを統合する
- 複数PMを立てる場合の注意点
- 意思決定者を一人にする
#pmconfjp pic.twitter.com/f8OLxAh6iY
「最も大切なのは、自分が夢中になれる物語を描くこと。」
— けーた (@kee_tap) 2019年11月12日
良い言葉。
ストーリーを作成して、実現されたか計測すると、無意識にPDCAが回る体験が全員に得られるのが肝に思いますね。
普通にバックログ潰していると前に進んでいるのか、よかったのか悪かったのかが見えにくくなってしまう。#pmconfjp
自分の言葉で表現し、それを読んでもらう(フィードバックをうける)ことの場数をどんどん踏んで行くことがものすごく大事なんだけど、それは最初にちらっと伝えたところがこれまたにくい。実はそこ、成功必須要因だと思うよ。#freee #pmconfjp
— riotaro okada (@okdt) 2019年11月12日
プロダクトビジョンをストーリーとして作成し、語り、計測するのが重要。
— akky (@tall_tree_desu) 2019年11月12日
どうやってストーリーを作る?
・誰の問題なのか
ドッグフィーディング
・何が問題なのか
具体的に:年末調整、FAX
・どうなる
主人公の変化
ストーリーを作った後は、叫び続ける
PMは手段を選んではいけない#pmconfjp
1人のPdMが全てを見ることが不可能になってくる
— KANE@Podcastの妖(精|怪)&エナジャイザー (@higuyume) 2019年11月12日
やはり、規模が大きくなってくると1人だと辛いよなぁ#pmconfjp#pmconfjp_2_3
freee岡田さんのセッションも良かった
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2019年11月12日
ただのビジョンではなく、動的な流れを持つストーリーで語ると、自分ごとになり組織にムーブメントが生まれる。
主人公(=ユーザー)を設定し、問題を定義し、狙う主人公の変化(=ストーリーのオチ)を語るべし。
#pmconfjp
PMが調整役になってしまうと、以下のような不安が生まれやすい。
— オカダ ヤスヒロ | Product Manager@エン・ジャパン (@middleOkada) 2019年11月12日
①自分の仕事や役割をうまく説明できない
②自分の持ってるスキルを説明できない
③自分は他社で通用するのか
PMはminiCEOと言ったりしますが、果たしてどれだけのPMがそういう役割を演じられてるか。
#pmconfjp #pmconfjp_main
sansanさんのセッション。長期は、中期、短期でpdmの責任者レイヤーを分けてる #pmconfjp
— Eiji Hachiya (@hachi_eiji) 2019年11月12日
リーンな組織の価値は改善の速さではなく、
— 高松 智明 | Workyspace (@t14i_) 2019年11月12日
どこが問題の芯なのかをコストを抑えて探す「探索力」。
リーンに芯を探して、手応えを掴んだらそこに投資する。
それを探すためのリーン。#pmconfjp pic.twitter.com/DK587qtXav
ユーザペインによって優先度をつける、大事 #pmconfjp
— Eiji Hachiya (@hachi_eiji) 2019年11月12日
toCかtoBは関係なく、フリクションを解決できるか。toCのユーザー数は資金で解決できるが、toBは非生産的システム、複雑なオペレーション、ガバナンスが立ちはだかる。これを解決することこそがDX。#pmconfjp #pmconfjp_2_1 pic.twitter.com/4AefqukF3V
— MURAKAMI Tomoyoshi (@ux_burger) 2019年11月12日
エン・ジャパン岡田さん(@middleOkada)のお話で記事で見たPMのスキルを明確化したチャート出てきた!
— マツバラヤスユキ@100人のPMインタビュー実施中 (@yaspontax) 2019年11月12日
個人的にこういうスキル見える化にとても興味があり、やっていたりする。
PM界隈が盛り上がることが、ひいては日本を盛り上げることに繋がるという視座の高さが素敵。#pmconfjp pic.twitter.com/DXCYAMAvRw
https://twitter.com/hibana_co/status/1194128370537136129
これは本当に思う。
— 高松 智明 | Workyspace (@t14i_) 2019年11月12日
シリコンバレーとかの事例も、収集するしためになる部分もあるけど、実際何が自分のプロダクトや組織にマッチするかを自分で見極めないとダメだなあと。
Googleってすごいけど実際にスタートアップ として立ち上がったのは20年以上前だしね、という見方というか。#pmconfjp pic.twitter.com/hSSbVRI0Jo
<ゼロからプロダクトビジョン合意(として感じたこと>
— まっちゃん (@mas1s2) 2019年11月12日
1,PMがまじで当事者意識をもって、ビジョンを一旦決める
2,ビジョンを推進すると事業に返ってくるよ!という確約を経営陣と握る(想いやPL含め)
3,ストーリーと事業への跳ね返りを定点観測する
の3点が大切だと思った
#pmconfjp
コミュニティはPMにもPMMにも大事。まず、コミュニティとは何か?オーディエンスとコミュニティは違う。オーディエンスは1:n。対してコミュニティはユーザー間の関係をマネジメントする。いかにユーザー同士の繋がりを作るか、強くするか。今日はコミュニティマネジメントの話。 #pmconfjp pic.twitter.com/puRSV3JtPu
— Nao Haida (@naohaida) 2019年11月12日
製品の周辺のコミュニティやサポートも含めてプロダクト。コミュニティがあれば製品チームのユーザーへのアクセスが早くなり改善速度も上がる。新しい機能を出したときに、ユーザーからフィードバックをもらえる関係性になっているか?#pmconfjp pic.twitter.com/niC3xDSItB
— Nao Haida (@naohaida) 2019年11月12日
PdMとは、戦略と実装を一致させる経営者 #pmconfjp pic.twitter.com/cuxmgrNBGT
— Takashi Adachi (@asanebo_) 2019年11月12日
Productの責任は、自分が全てやるのではなく(コミニュケーションを含めて)助けを求めることができるPdMが一番強いのではないか?
— Aya Nishiwaki(Takahashi) (@tkhsaya) 2019年11月12日
誰にどう見られるのか?ではなく、UserやProductに対して真摯な行動をとることが責任を取ること。#pmconfjp #pmconfjp_2_2
サブスクのような、長期的にユーザーとの関係を構築する必要がある場合、製品に貢献するコミュニティ作りも含めて、プロダクト作りをするといい。
— tomohi (@tomohi_pm) 2019年11月12日
情報発信、フィードバックから迅速かつ精度の高い開発サイクルに繋がる。#pmconfjp_main #pmconfjp
コミュニティではオンボーディングが重要(価値/愛着/貢献を早期に感じてもらう)、プロダクトマネジメントスキルはコミュニティ醸成にも活かせる #pmconfjp #pmconfjp_main
— Keisuke Yokoi (@KSKyokoi) 2019年11月12日
オンボーディングが大事。
— 星 永亮@ユアマイスター (@inase17000) 2019年11月12日
コミュニティが自分たちのチームだとしたら、採用もコミュニティへのオンボーディングだから似てる話多い。
#pmconfjp
コミュニティデザイン!
— のりぴー/Norihiko Saito (@nolick1219) 2019年11月12日
1. 戦略と目的(=>ビジネスとの統合)
→ないと「楽しかったね」だけで終わる
2. 構造(サイズ、人数、階層)
→最初は小さくはじめる
→多い場合はサブグループに分割★
3. 体験とプロセス/貢献
→早めにメンバーにあえて貢献を求める★
※★おススメ#pmconfjp
■コミュニティ作りの肝
— けーた (@kee_tap) 2019年11月12日
・初期は熱狂的なユーザーのみで閉鎖的に
・人数増えると場に対するニーズに多様性が生まれるため、サブグループ化しある程度のサイズを維持
・ストーリー共有や、通過儀礼、メンター制度等、初動サポート
・組織貢献の定義を明確化し、価値発揮しやすい環境作り#pmconfjp
カスタマーサクセス、採用と組織化、そして、コミュニティ。それぞれにおいてオンボーディングというフェーズがキー要素になってきてる。じゃ、オンボーディングって具体的に何よ? と聞かれると答えられない自分がいる。ここもあとで勉強しよっと。#pmconfjp
— Ryo Miura (@ryo_miura_it) 2019年11月12日
まとめ: 1. コミュニティマネジメントは自社内から。戦略とビジネス価値との接続を考え社内を説得する。2. コミュニティ作りは自分から始めて渦を起こす。3. コミュニティのメンバーには積極的に貢献してもらえるように促し、デザインする。#pmconfjp pic.twitter.com/FrFg0aLgdZ
— Nao Haida (@naohaida) 2019年11月12日
PMのスキルを明確化して組織をつくっていく。
— 浅沼 祥 (@sho_asanuma) 2019年11月12日
必要なスキルが明確になることで、他職種や複数のファンクションが個人や組織全体レベルを補う&高め合っていき、いい事業/プロダクトにつながっていく。(勉強会が自律的に行われる等)
#pmconfjp pic.twitter.com/KsTAka4Lsb
NewsPicksはプロダクトマネージャーが10名いる。あるべき姿としてうちだと何人必要なんだろう。#pmconfjp
— Yusuke Ura (@ysk_ur) 2019年11月12日
企業が欲しいのはプロダクトマネージャーではなく「プロダクトマネジメント」であって、
— h (@hyt_ina) 2019年11月12日
プロダクトマネジメントはプロダクトマネージャーだけのものじゃないよ、って話かな#pmconfjp
質問1:プロダクトマネージャー人材の役割と需要
— Nao Haida (@naohaida) 2019年11月12日
杉浦: ミニCEO。特化した強みがありつつ、プロダクトにコミットできる人。特化する方向にこだわりはない。PMは現在10名ほどで2名のリーダー組織。
土屋:組織内ではメインはPJM。立場上PDMは相手企業にあるので、右腕のような存在。#pmconfjp pic.twitter.com/DeuIInDRG8
グッドパッチ土屋: 失敗談として、PDMを外部から雇ったが、会社の文化の理解度や創業者との信頼関係を上手く作れるかに課題があり上手くいかなかった。逆に新卒で入社して真っ白だったが、上記の課題をクリアしながら徐々に育っていった成功事例もある。#pmconfjp
— Nao Haida (@naohaida) 2019年11月12日
プロダクトマネージャーをどうオンボードさせるか?
— Nao Haida (@naohaida) 2019年11月12日
ニューズピックス杉山:丸投げして上手くいくものではない。プロダクトこれで、後はよろしく、では無理。人それぞれの強みごとにサポートを変える。責任範囲も絞る。
及川:PMは採用して成功ではない。入社して成功体験があって始めて成功。#pmconfjp pic.twitter.com/fA48uPGCV2
グッドパッチにいるUXデザイナーやサービスデザイナー、デザインストラテジスト、PMは、クライアントにいるPOやPdMの右腕として評価されるメンバーが多いです(中の人より)#pmconfjp
— 國光俊樹|Goodpatch (@ku_ni_29) 2019年11月12日
意思決定のポイントや判断基準、優先順位の感覚が近くなるまで一緒にやる
— Yuki Ogata (@yk_ogata) 2019年11月12日
わからなくはないけど、そこを超える人材はどうする??みたいなところはある
#pmconfjp
デジタル側かビジネス側か、どちらにしても、半年から1年の並走が必要。視座や視野の状勢、期待値調整、ロードマップの組み方が似てきたなと思ってきたら委譲する。自分のミラーコピーを作るという話。価値感が近い人を採用する。...って経営における後継者育成と同じやな。#pmconfjp #pmconfjp_main
— Ryo Miura (@ryo_miura_it) 2019年11月12日
コスト削減ばかりでなく、攻めのデータ活用をやろう。 #pmconfjp_2_2 #pmconfjp pic.twitter.com/zB1636pHjz
— MURAKAMI Tomoyoshi (@ux_burger) 2019年11月12日
グッドパッチ土屋:基本、半年から1年併走が必要。創業者または前任者がどこを見ているかを伝えていくことが必要。感覚が揃ってきたら徐々に委譲していく。根底の価値観が揃っていないとそもそもキツい。1on1などの継続的な対話。#pmconfjp
— Nao Haida (@naohaida) 2019年11月12日
pdmが新しくプロダクトに関わる時、ともに並走し1つの成果を上げるまでがオンボーディング。
— tomohi (@tomohi_pm) 2019年11月12日
わたしは伴走者が居なかったので、期待値のズレに気付くのに半年かかりました。。#pmconfjp_main #pmconfjp
PdMの採用
— 浅沼 祥 (@sho_asanuma) 2019年11月12日
■失敗事例
外部からPdMを採用したが、なにをするかなぜするかを語れず、プロダクト成長が止まった。
■成功事例
内部からPdMに若手を着任させたときに信頼貯金&信頼残高があることでチームもプロダクトもグロースした。(真っ白なキャンパスもあり)
信頼残高重要!
#pmconfjp
コミュニティ形成の話は興味深かった。
— Yosuke Kawashima (@yolinling) 2019年11月12日
サブスクプロダクトの相性がいい。
・プロダクトのフィードバックと質が高まる
・辛辣な意見も聞ける。
・ユーザ間の話が見える
・当日中に機能のフィードバックがもらえる
・迅速な改善で将来もよくしてくれそうと感じる#pmconfjp
誤解を恐れずに言えばPdMって「本質を常に考え続けて、ものすげーコミットするマン」なんだよな。スキルはそれを助けるためのもの。表層的なポジショニングとしてのPdMはメッキすぐ剥がれるんですよ。プロダクトの規模に関わらず。#pmconfjp
— しんごさん (@pantune_style) 2019年11月12日
#pmconfjp 初めて参加したけど、day1はどちらかというとこれからPdMを目指す人向けの内容が多かった気がする。day2はより現場向けなのかな。
— うえだ@マーケxIT (@_HrsUed) 2019年11月12日
PdMはユーザーの満足度にコミット
— 國光俊樹|Goodpatch (@ku_ni_29) 2019年11月12日
PO(事業責任者)はその上でどのようなビジネスを組み立てることにコミット
両者は並列に配置されている#pmconfjp
企業視点でプロダクトマネージャーの需要やオンボーディングの話があったけど、個人側の視点で捉え直すと、
— マツバラヤスユキ@100人のPMインタビュー実施中 (@yaspontax) 2019年11月12日
・企業や事業、プロダクトのミッション、ビジョンへの共感度の高さ
・経営層など上位レイヤーとの価値観の一致
・視座、視野、視点を盗めるか
あたりが活躍するPMのポイント#pmconfjp
Goodpatch 土屋さん
— 國光俊樹|Goodpatch (@ku_ni_29) 2019年11月12日
---
PdMには「なんとかする力(突破力)」が必要。
スキルはどこかしら足りていないのは当たり前。なので、短期間で状況把握をしてなんとかする力がベースとして必要。
PdMは総合力。
ただ、それは自分で全部やるという意味ではなく、巻き込みながらなんとかする力が必要#pmconfjp
増井のメソッド
— Nao Haida (@naohaida) 2019年11月12日
1.自分が作りたいものを作る
2.コロンブスの卵が好き(簡単で有益なもの)
3.誰もが使えるものはプロダクト化
プロダクトイン:自分が使う便利なものでよのなかにもウケるものをプロダクトにしている。ユーザー調査を元にしていない自己中心設計。#pmconfjp pic.twitter.com/ARbqoOLwuZ
発想するだけでは論文くらいしかかけない #pmconfjp
— とみね / 遠見海@バーチャル多趣味アンドロイド (@htomine) 2019年11月12日
「ビジネスのためにプロダクト開発をする」っていう発想じゃなくて「自分が使いたいものを作る」っていうプロダクトファーストな思想だからこそなせる自由さ。
— はち (@PassionateHachi) 2019年11月12日
商業開発だと忘れてしまいがちな考え方に立ちもどれる話。 #pmconfjp
newspicksで定義しているPdMのスキル
— 國光俊樹|Goodpatch (@ku_ni_29) 2019年11月12日
---
1. トライアンドエラーを繰り返す(デザインシンキング的な)
2. ユーザーリサーチからインサイトをディープに知るインタビューなどのスキル
3. マーケットでこのプロダクトがヒットできそうかを科学的に分析できるスキル
---#pmconfjp
というか、現時点でPdMと同じ動き方はできるはずで、まずは関係のあるメンバーが何やってるか全部把握してみればいい #pmconfjp #pmconfjp_2_1
— メゾン ド ブタサン (@_keihino) 2019年11月12日
「自分がこれが無いと死んじゃうぐらいの勢いで作らないとだめ」 #pmconfjp #pmconfjp_main
— Hiroki Akiyama (@akiroom) 2019年11月12日
発想法は色々ある。無理やりまとめるなら、情報を集めた上で、ぼーっとする。#pmconfjp pic.twitter.com/k3WVtnMVgR
— Nao Haida (@naohaida) 2019年11月12日
ドッグフーディング中は音楽聞いちゃだめらしい(右脳を使ってしまい発想が阻害されるからw)#pmconfjp_main #pmconfjp
— takono@無職 (@takono0807) 2019年11月12日
泥酔指向インターフェース最高#pmconfjp
— 星 永亮@ユアマイスター (@inase17000) 2019年11月12日
長屋発想(長屋に住めるかという制約条件をつける)、そもそも発想(そもそも何を解決したいのか)、ドッグフーディング発想(ひたすら使う)、とかよく使う発想法はある。昔、発想法を一回色々と集めたとのこと。 #pmconfjp pic.twitter.com/sAbBpceptS
— Nao Haida (@naohaida) 2019年11月12日
本日の増井先生の一番重要な教えです #pmconfjp pic.twitter.com/5dngAvTcbJ
— スーパークレイジー君 (@yuiseki) 2019年11月12日
https://twitter.com/hibana_co/status/1194159292527435777
https://twitter.com/hibana_co/status/1194159293571858433
https://twitter.com/hibana_co/status/1194159294574317569
https://twitter.com/hibana_co/status/1194159297757728773
増井さんにとってのプロダクトマネジメント=発想+プロトタイピング+ドッグフーディング #pmconfjp #pmconfjp_main
— Hiroki Akiyama (@akiroom) 2019年11月12日
"発明、ドッグフーディング、プロダクトマネジメント"
— のりぴー/Norihiko Saito (@nolick1219) 2019年11月12日
・自分が使いたいものを作る
・ユーザー調査しない
・「自己」中心設計
・無いと困るものを作る
・発想法も使う
・音楽は聴かない
・問題発見できたら半分終わり
・できる限り認証ナシ
・簡単に使える
・簡単に作れる
...理想!#pmconfjp
最後、個人でプロダクトマネージャーを目指すには→エンジニアは素養があるので、得意なところから学ぼ。自分でプロダクトをつくって学ぶのがいいのでは。他、求人側がプロダクトマネージャーを理解していないリスクもあるので気を付けて。など。あっというまの30分だった。#pmconfjp #pmconfjp_2_1
— Ryo Miura (@ryo_miura_it) 2019年11月12日
https://twitter.com/OhmaeYuki/status/1194160707417198592
良いチームからしか、良いプロダクトは生まれない。
— まっちゃん (@mas1s2) 2019年11月12日
良いチームを作るにはリーダーとの信頼関係が必要だ。
信頼関係を作るには、ビジョンが必要。
良いビジョンを語ると、良い人が集まる。#pmconfjp
PMはなんでも屋のminiCEOだということが今日は何回も出てきたなー #pmconfjp
— zc (@zc90109847) 2019年11月12日
プロダクトマネージャーカンファレンスに来ています。
— かねこつよし (@tsuyoshi_osiire) 2019年11月12日
初回のkeynoteが非常によかったので爆速でまとめてみました!(主にデザイナー向けの観点でまとめています。)
会場に来れなかったデザイナーの皆様、よかったら見てくださいーhttps://t.co/mcMPXEULtk
#pmconfjp
LINE社二木さんの「ジレンマは必ず解消出来る 」「HOWを2回繰り返すと、ジレンマは同じ意見にたどり着く」という話面白かった。
— sonopy@Ubie (@sonopy_u) 2019年11月12日
コンフリクトしているようで実のところ目的は同じ、というのはよくあることなので、こうした思考プロセスがチームで共有できているとよさそう。#pmconfjp pic.twitter.com/2FszJhHE3V
でも自分が絶対に欲しいプロダクトを作るってめっちゃ大事だよね。プロダクト愛と信じ力がプロダクトを良いものにする #pmconfjp
— まみたす (@zhen_meii) 2019年11月12日
いろんなセッションを聞いて、やっぱりtrustがキーワードっぽいなあと感じる。
— kenken🐶 (@tkhs0604) 2019年11月12日
日本語の"信頼"に近いんだろうけど、個人的にはそれよりも強いニュアンスに思えて、少し腹落ちしてない部分もあるけど。#pmconfjp
どのセッションでもこれな感じする。
— まみたす (@zhen_meii) 2019年11月12日
ドメイン理解、カルチャーフィット、チームとうまくやること(信頼)、プロダクト愛 #pmconfjp pic.twitter.com/MERIslp1aN
エンジニアの立場で参加したのですが、プロダクトチームのつもりがいつの間にかフィーチャチームになっているような気がして耳が痛かったのと、ともかくInspired読みます。という初日のざっくり感想。 #pmconfjp
— kalibora (@kalibora) 2019年11月12日
プロダクトマネージャーに必要なこと
— かねこつよし (@tsuyoshi_osiire) 2019年11月12日
・業界の専門知識
・チームとの協調性
・カルチャーへの適応性
・情熱
例えば朝起きて仕事に行こうと思ったときにハッピーでないなら会社に来ないほうがいい。
自分の好きな人達と、自分の好きなサービスを創りたいと思う情熱が大切。
#pmconfjp
顧客視点が一番大事。
— かねこつよし (@tsuyoshi_osiire) 2019年11月12日
ただし、
顧客の「〇〇がほしい」を
「何が必要なのか?」
に変換するのが私達の仕事
早い馬が欲しい人達に車を提供する
#pmconfjp
顧客から要望を聞きすぎるのも良くない。なんでそういった要望を出したのか?それを深く聞く。そのうえで、解決策を提示する。あくまで、プロダクト全体のビジョンや方向性からそれないで。全体最適化の話。 #pmconfjp
— Tomo|SCRAMBLE UP (@TomoYanagida) 2019年11月12日
https://twitter.com/hibana_co/status/1194170316999708673
創造性を産み出すサイクルを日々の成長で広げること。アーティスト、科学者、エンジニア、デザイナーとしての資質を広げる。また、顧客起点で考えること #pmconfjp pic.twitter.com/bTIDtHRc1i
— Nao Haida (@naohaida) 2019年11月12日
コアバリューだけをひたすら追求しきるって普通に不安になるし、一定水準までいくと次のレベルに上がるためのコストも比例して上がって意思決定は難しくなる中、1点を極めたってのが本当に凄い。「何を提供するのかの絞り」と「目指す水準の高さ」が噛み合ってないと組織で実現できなそう。#pmconfjp
— けーた (@kee_tap) 2019年11月12日
10X社矢本さん @yamotty3 の『10xのための逆説』
— sonopy@Ubie (@sonopy_u) 2019年11月12日
個別の逆説もそれぞれ面白かったけれど、結論に共感。「知識は持ったうえでゼロベースで思考できる」というのが一番強いと最近よく思います。#pmconfjp pic.twitter.com/6uVZsyi8am
#ベルフェイス 吉本さん @t_yoshimoto0107
— 浅野恭兵 @ リクルートSaaS PdM (@asano_kyohei) 2019年11月12日
各TのKPIが違う中で、プロダクトの指向性を変える(自社HPにタグ埋め込み→ベルフェイスサイト上に誘導)ことで、各Tの利害を一致させ、チームが自走できるようにして、プロダクトを成長させた。
PdMではなく、そのトライアングルの機能が必要。#pmconfjp pic.twitter.com/SsMAbJUxvX
今日はTrustにつきるんだけど、
— Shogo Yoshizumi (@Xen_55) 2019年11月12日
最初のTrustもあれば継続的なTrustもあるから、それぞれどう実現していくかが #pmconfjp 後の課題だな〜👀
(個人的には特に継続的なほう)
"Speed of now" これはシリコンバレー界隈でもめっちゃ意識されている。ユーザーがプロダクトに向き合う「時間」はある種の投資(Investment)。だからこそReturnがきちんと感じられないとユーザーはすぐ逃げる。最近のよくできたB2BプロダクトをConsumer-gradeとよく呼ぶのにはそんな背景が。#pmconfjp
— Haruki Sonehara / 🇺🇸 Head of Product @ シリコンバレー (@Haruki_Sonehara) 2019年11月12日
早速1日目の参加レポート書きました。明日も期待。
— 高松 智明 | Workyspace (@t14i_) 2019年11月12日
プロダクトマネージャーカンファレンス 2019 1日目まとめ|高松智明 @t14i_ #note #pmconfjp https://t.co/CvNfHTBhhV
これ面白い!ちなみに僕は完璧なビジネス寄り…#pmconfjp pic.twitter.com/OELp00kN9y
— Takeshi Fujikawa (@tks_fujikawa) 2019年11月12日
今日の話を聞きつつ、これまでの経験からPOとPdMをあえて定義するなら以下
— 國光俊樹|Goodpatch (@ku_ni_29) 2019年11月12日
---
PO(事業責任者):
経営の言葉を事業の言葉に変換して事業戦略(ビジネス)を組み立てる役割
PdM:
事業の言葉を理解しつつ、ユーザーの言葉を事業戦略にフィードバックしたりプロダクトへの実装をリードする役割#pmconfjp
ステークホルダーが多く、PdMはジレンマの中で意思決定が必要。
— 浅野恭兵 @ リクルートSaaS PdM (@asano_kyohei) 2019年11月12日
一見相反することもWHYを2回繰り返すと同じ目的に辿り着く。その本質を捉えた上であるべき打ち手を考え、決める。
きっとどこでもよくあるシーン。改めて意識したいこと。#LINE 二木さん#pmconfjp pic.twitter.com/sq4kTWdZeO
納得感ある✍
— すずきりょう (@stvjbz) 2019年11月12日
・マネージャーのタスク
①採用
すぐれた人を採用する
②コーチング
人に対しての能力を高められる
③チームの目的を設定する
エンパワーメントするための目的
・PMの真の仕事とは「TRUST」である#pmconfjp https://t.co/pardf5oNcP
「PMの真の仕事はチームを信頼すること。チームは、機能を実装するのではなく、ユーザーの問題を解決する。」と書いてて良い。PMが全て指示すると、社内合意することがゴールになる。
— 敷地 琢也👨💻エンジニア (@shikichee) 2019年11月12日
「普通の人、特別な結果」 byプロダクトマネージャーカンファレンス2019_議事録 #pmconfjp https://t.co/oDHH5Us1KJ
#LINE のPdMとは、自身のプロダクトを成功に導くミッションを背負い、意思決定をして市場に届ける役目。
— 浅野恭兵 @ リクルートSaaS PdM (@asano_kyohei) 2019年11月12日
その中でLINEで活躍するPdMとは、
・足りない部分の協力を誘発できる
・妄想力がある
・ユーザ視点でディテールまで詰めきれる
力を持つ人#pmconfjp pic.twitter.com/G9Iu9yvlXU
会社の規模が大きくても小さくても抱えていることは同じなんだなぁ。
— 高橋優|Makuake Androidアプリリリースしました! (@yu_tokyorider) 2019年11月12日
組織のフリクションを想定、意識しながら経営、プロダクト、セールス、CSの意見汲み取って改善繰り返していいもの作って結果だす。
関係各所巻き込んで成果出してみんなハッピーになるつよつよマンになるしかないw
#pmconfjp
freeeさんの発表も良かった。ストーリーテリングはさっそく明日から実践しようと思えるいいTips #pmconfjp https://t.co/EUDPwmmkVG
— Satomi Moriki (@satomikko94) 2019年11月12日
コミュニケーションしなくていい環境とか作ったらアウトって経験があるから僕もメッチャ共感した。#pmconfjp https://t.co/AgSJjbFwSW
— eroccowaruico🧸 (@eroccowaruico) 2019年11月12日
PMはカメレオン。これよく分かる。カメレオンになるために沢山の知識と経験と妄想力が必要。 #pmconfjp
— はるか (@haruge) 2019年11月12日
心に刻んだ
— 3pay | COUNTERWORKS Inc (@naoki_sanpei) 2019年11月12日
「失敗というのは、避けられたはずで、学びが残らず、何も解決せず、時間やマインドシェアを奪うもの」である。それはなにかというと「日々の易きに流れる惰性の積み重ね」だと思う。易きに流れないことが大事
10xのための逆説 #pmconfjp | Yamotty (@yamotty3) https://t.co/KBVL9RNSu5
話を聞けなかった タベリー@yamotty3さんの「定説に対する逆説」記事、QA含めとても有り難い。
— 浅野恭兵 @ リクルートSaaS PdM (@asano_kyohei) 2019年11月12日
結論、定説は当てはまらないので、
自分のユーザーと向き合い、考え、Un-concensus right(他の誰もが同意しない、自分だけが知る事実)を見つける・賭けるのが最も早く、成功に近い道と考える#pmconfjp https://t.co/8uffeIVDgZ
今日の #pmconfjp のネットワーキングパーティーの席でOKRやプロダクトロードマップについて聞かれた際にもお話したのですが、プロダクトはその企画から開発〜運用まで一気通貫のぶれない方針が必要です。// はじめてのPRD https://t.co/njF4LsoV29
— 及川卓也 / Takuya Oikawa 「ソフトウェア・ファースト 4刷発売中」 (@takoratta) 2019年11月12日
かの名著InspiredのMarty Cagan氏の講演を聞けただけでも非常に意味の深いカンファレンスでした。
— かねこつよし (@tsuyoshi_osiire) 2019年11月12日
『PMの仕事は信頼である』
組織で働くためのエッセンスが詰まった、
PMだけでなくチームではたらく人全てに聞いて欲しい素晴らしい講演でした。#pmconfjp https://t.co/mcMPXEULtk
本日はpmconf、コミュニティマネジメントの講演学び多かった。
— オザワ シンイチロウ | Brightwin (@brightwin_) 2019年11月12日
特に「コミュニティに貢献した人はそのコミュニティをより好きになるので、貢献できる仕組みを作る」てのはとても刺さった。
あとはPMMの働き方やスキルセットについて深く聞いてみたかったなー#pmconfjp
https://t.co/y7qKEIvz8g
#pmconfjp 参加。#inspired 著者のMartyCagan @cagan のkeynote。開発チームはビジネスではなく顧客に仕えるチームになっているか?トップダウンで決めた機能を作らせるだけの「feature team」になっていないか?課題を突き止めて解決策自体を考えられるチームになっているか?キーワードは「Trust」。 pic.twitter.com/UBiLp0Ygzx
— Shunpei Koutake | トレタbizdev🏊♂️🚴♂️🏃♂️ (@shumpeei) 2019年11月12日
UXエンジニア並にプロダクトマネージャも何者か捉えがたいなあ。
— kenken🐶 (@tkhs0604) 2019年11月12日
何となく分かったことは「人をマネージするわけではないけどモチベートする役割ではある」ってことだったけど、「モチベートする=感情をマネージする」なのでは?って疑問が。#pmconfjp
と思ったら、今日のプロダクトマネージャーカンファレンスでは、組織・人は見るなという話が多かったですね。
— 高橋 義典 (@a2586) 2019年11月12日
マトリックス型組織がとても増えている様子でした。#pmconfjp
本日のProduct Manager Conference 2019 Day1について、グラレコ風メモ付きでまとめました! #pmconfjp / “Product Manager Conference 2019 Day1に参加してきた - @satomikko94.b” https://t.co/gs0lUrubAD
— Satomi Moriki (@satomikko94) 2019年11月12日
PMに必要なのは信頼貯金って各所で言われていた。自分も日頃から大切にしてるが貯金の仕方がわかってないメンバーには小さい成功体験を積ませられるよう工夫するのが自分の役目だと思った。社内のリファラルってバカにできないし。 #pmconfjp
— たなか。 (@mashmar0man) 2019年11月12日
SaaSに関わる文脈メインですが、PMカンファレンスのハイライト書いてみました。https://t.co/ciXOfZBcIj#pmconfjp
— Sasaki Kota (@kosasaki7) 2019年11月12日
本日参加したpmconfを「新米PM」という視点でまとめました!#pmconfjp
— よしでぃ@Retty/CS立ち上げ (@yoshiD0301) 2019年11月12日
新米PMは何から始めれば良いか~pmconf-day1の学びから実践へ-|YoshiD @yoshiD0301 #note https://t.co/dZ9skW5CyF
1日目のメモを読み返してまとめてみた
— 久津佑介(HisatsuYusuke) / プロダクトマネージャー (@Nunerm) 2019年11月12日
・PMは信頼(Trust)の獲得をして結果に対する責任と意思決定の自由を勝ち取る
・ユーザーとプロダクトと向き合い、ステークホルダ間のジレンマを解消しながら、定説に頼らず何とか突破していく
明日も学ぼう
#pmconfjp
4000字くらい。
— nickota✈️早起きエンジニア (@xxnickota) 2019年11月12日
あとで見返す用。
pmconf2019 一日目メモ - nickotaのあうとぷっと。 https://t.co/scZU0cGq8S#pmconfjp
プロダクトマネージャーカンファレンスに来ています。
— かねこつよし (@tsuyoshi_osiire) 2019年11月12日
初回のkeynoteが非常によかったので爆速でまとめてみました!(主にデザイナー向けの観点でまとめています。)
会場に来れなかったデザイナーの皆様、よかったら見てくださいーhttps://t.co/mcMPXEULtk
#pmconfjp
2日目もしっかり追いたい。