2019.pmconf.jp現在僕は仕事でもプロダクトオーナーシップに近いところにいたりして、「プロダクトマネージャー(PdM)」への関心が急激に高まっていたりする。趣味開発プロダクトにおいては常に自分がプロダクトオーナーであるとも言えるし(?)。今回はもろもろ噛み合わず参加を見送ったのだけど、インターネット上に溢れでてきた情報からだけでも最大限インプットしたいということは、イベント開催前から思ってた。時点で全部追ったついでにまとめたメモ。盛り上がっていたのか、相当な数のツイートがあった。教えていただきたいです。登壇します(しました)!類似資料の一部はこちらから。コミュニティマネジメントです。同じ時間の別セッションのタイトルにサブタイトルを被せるというチャレンジをしたのは私です。会場内が優しい方ばかりで助かりました。本日の発表内容アップしましたー。二木の「LINEにおけるお金とユーザーのジレンマ」の登壇資料を公開いたしました。展示ブースでは各サービスのLINEのPMと話せる時間を設けています!是非遊びにきてください。Pairsの「作り手の想いとユーザーをつなぐための悪戦苦闘」の資料です。会場の皆さんに暖かく迎えていただき楽しくお話ができました。ありがとうございました。本日登壇のフォローアップ記事出しました。@mizuki_tannoさん、運営の皆様、改めてありがとうございました。明日も頑張って下さい!"事前に募集したQ&Aへの回答もできなかったため本稿はフォローアップ記事となる。Day1で登壇させて頂きました。コミュニティを始めるときのヒントや社内説得資料としてお使いいただければ嬉しいです。エムスリーテックブログプロダクトマネージャーに必要なテクニカルスキルを定義してみた話。追記)IT分野の人の既存事業への挑戦、やはり進んでいる......「企画バックグラウンドPdM」「エンジニアバックグラウンドPdM」、よい「製品を見つける」という表現、なるほど感ある発明できてるか?と自分に対して問い、ハードルあげていきたいカスタマーサクセスの考え方もめっちゃ活きそうだなーとか思ったプロダクトマネージメント・カスタマーサクセス・コミュニティマネジメント、あたりは、比較的新しくも今後激しいニーズの高まりがありそうな分野な気がする自分のキャリアを円グラフで表現するの、おもしろいなwプロダクトマネジメントトライアングル。3勝2敗/日、と言っておられるのも)「プロダクトリーダーシップ」またいいワードでてきた「スキル」と「スタンス」。「人が欲しがるものをつくる」ではなく「シーンで必ず使われるものをつくる」。具体的なシーンとコンテキストに対してどれだけ適切なプロダクトであるか。興味でてきたドッグフーディングをみんなでできてるとストーリーを共有しやすい、というのはありそう〜プロダクト内の顧客だけでなくマーケットを。見ないとなぁもっとデータを意識しないとなぁ施策や試み、それが間違い・失敗だったかどうか?という判断をおこなうタイミングを設けていなかったり、その判断をおこなうことができない(判断に必要な材料を揃えられない・その基準が明確でない)、というのも問題だよなぁすべてを鵜呑みにはしない(これを材料として、自分のチームとしての最適解を探りたい)にはしても、アンチパターンとされているものだったり注意すべき点としてあげられているものについては、先人からのアドバイスだと思って咀嚼したい愛とか情熱とか必要なのかどうか、と疑問に思ったことがあって、必要なんじゃないかと思っていたが、それが裏付けられたような気持ち。顧客対話との両輪でもある、というのは忘れないようにしないと。客観的にみても自分はプロダクトのことを考えられてるほうだと思うんだけど、それはそのプロダクトのことが熱狂的に好きだからだと思ってて、世の中のプロダクトのことを考える役割の人もまた、自分のプロダクトのことを熱狂的に好きなもんなんだろうか。(必ずしもそうでない気がしている。エンパワーされたプロダクトチームを作るかどうかは最終的には経営レベルの判断。ない企業にいると、できることは限られるか時間がかかってしまう。プロダクトチームが主体的に成果を上げることで少しずつ文化を変えることはできるかもしれないが、多くの場合は転職したほうが早い。2019年11月12日"問題解決するベストの方法は何かを考えるのがプロダクトチーム"この意識を広めて行くのは大切だ。2019年11月12日スピードと顧客ファーストを支えるのが自律的なチーム。早く持続的に動くのに最適。顧客に近いところでチーム内で意思決定。プロダクトプランやロードマップを決めるためのコミットメントやマネジメントミーティングなし。チームは正しい結論を出すか、間違いから学ぶと信じている。間違いを隠しちゃダメゼッタイ。teamになっていく組織はたくさんあります。「本当のプロダクトチームの判断にマネジメントの承認はないはず。それが一番スピード感があってサステナブルで正しい判断ができる組織になる。自律的なチームに判断する自由を。判断には常に顧客のインサイトやデータによるバックアップが必要。2019年11月12日Transferwiseさん結構過激なマネジメントしてる。意思決定の自由を持つというのは、責任を持つということ、カスタマーインサイトしているから説明できる。プロダクトチームが権限を持つ必要があるのだと思う...けど、やっぱり経営との関係がきになる。海外の方がトップダウンに動くイメージがあったけど。2019年11月12日プロダクト原則をしっかり定義して、ユーザーインサイトとデータに基づいて意思決定しながら学べばカオスにはならないという方針のよう。・価格が安い・スピードが速い・使いやすい・色んなところで使える原則この4つを良くする方向、って決まってるなら確かに迷わなさそう。2019年11月12日チームに自主性を持たせることがスピードや解像度の高い解決策を出すために必要。Discovery"って、"要件定義"よりもいい言葉だ。それは誰かが決めることではなく、皆で発見するものだと。プロダクトの開発とは、作られたロードマップを行くことではなく、繰り返される実験から導き出されるものだと。2019年11月12日Transferwiseの場合プロダクトの性質上グローバルに広がることで価値が上がるので、各国の拠点が自治的に動くのは相性が良さそう。自治は責任が伴うこともチームで同意が取れてるんだろうな。ここでもtrust(信頼すること)とoutcome(結果を出すこと)がキーワードとして上がってきた。2019年11月12日これは間違いなく真理。経営層の信頼を失ったらもうPdMにやれることなんてないです。PdMは経営層の期待に応えなければいけないし、期待値を超えたパフォーマンスを出していかないといけないと思っています。2019年11月12日https://twitter.com/hibana_co/status/1194108115207249920https://twitter.com/hibana_co/status/1194108117170229249https://twitter.com/hibana_co/status/1194108118604664832https://twitter.com/hibana_co/status/1194108124644495362PMはジレンマ回収役。デザイナーは画面Aが良くて、開発が画面Bがいい。難しいものは後にやりがち。させないためのプロダクトマネージャー。2019年11月12日ジレンマは認識の違いから発生するとのこと。対立構造の根本原因を正しく認識することで目的を共通化し、ビジョンや方針によって共闘関係に変えていくことができる。・仕様を書くだけの人になってない?・常に判断を上に求めて合議制で決めようとしてない?・他人や他部署のせいにしてない?プロダクト開発におけるジレンマに敗北していないかチェックリスト。プロダクトの成長を邪魔しちゃう要素。自分もあるし、他の人も耳が痛くなりそー。「ジレンマ解消自体がクリエイティブ」って素敵な視点だなぁ。2019年11月12日ビジョンが見えない・実現に向けて粘り強く取り組める環境がないと、PMは機能できなくなるのかも。「ジレンマはHowを2回繰り返すと同じ目的にたどり着く。ジレンマは解消できる。2019年11月12日LINE、PMが機能してないと何が起きるか「諦める:一番楽。意外とこの時点で止まってる人多い」これわかる。重要な課題なのにずーっと放置されてることがプロダクトにあったりする。闇雲にバックログを追いかけるだけのプロダクトは陳腐化し、誰のテンションもあげない。2019年11月12日プロダクトオーナーの認識が自分とは逆。プロダクトマネージャーが意思決定者でプロダクトオーナーが意思決定の中でプロダクトバックログを管理する役割だと思ってる。役割認識がチーム内で合っていれば、どちらでもいいとも思うけど。2019年11月12日PMが複数いるとその責任範囲ってどうなるんだろう。一般的なPMより権限や責任領域は少なくなって判断権限がないPMとか生まれそう。2019年11月12日M3さんのバックグラウンド毎にpmわけてるのは確かに。2019年11月12日プロダクトマネージャー、企画バックグラウンドの人と、エンジニアバックグラウンドの人がいるのはそのとおりだな。何でもできることを期待してしまいがちだけど、そうすると、プロダクトマネージャーしんどいよね。2019年11月12日そもそもPMが複数いた方がいいよねって言う考えのスタートが気になる。2019年11月12日ファクトをストーリーにすることでビジョンが浸透してバックログにも意味が宿り意思決定しやすくなる。2019年11月12日ストーリーを持たないビジョンは絵にかいた餅になる。(誰も意識できない/形骸化する)ストーリー化すると、記憶に残り、皆が意識できるようになる。課題をストーリーで語る習慣が身につくと、「何故それをやるのか?」を開発メンバーが理解でき(適切に取捨選択され)、良い循環が回る。2019年11月12日ストーリーは計測し続けること。ストーリーのオチで達成している世界観に寄与するKPIを計測し続け、オチの世界に近づけていくこと。物語はいかに当事者になって語れるか。