重点を置きたいキーワード
- PDMとして、解釈を届ける
- データドリブンによって動く
- 1チームのメンバーは、同じことが出来る状態を選択する。
- ストーリーテリングによって覚えてもらう。
- トラストする。(なんて日本語だw)
参加できたセッション
Day1
- ORDINARY PEOPLE, EXTRAORDINARY RESULTS
- TransferWise
- 海外の現場を訪問してわかったコード中心ビジネスの時代におけるプロダクトオーナーシップ
- PMにおけるストーリーテリング
- “失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -
- コミュニティマネジメント: プロダクトの開発と展開をコミュニティが加速させる
- 企業が求めるプロダクトマネージャーとその人材戦略
- 発明、ドッグフーディング、プロダクトマネジメント
- Zoom
Day2
- 「愛と解釈のコンダクター」
- A day in the life of Silicon Valley PM
- プロダクトアウトな新規事業立ち上げのリアル
- DXにおけるプロダクトマネジメント
- プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント
- 面白いプロダクトの作り方と魅せ方
- 顧客要望と情熱の間- B2B SaaS のプロダクトマネジメント -
- Rebuild the Industry 〜産業の半自動化を実現するプロダクト開発手法〜
- シリコンバレーPMのキャリアと働き方
自分のモチベーション見える化
数が多いほど、モチベーション得られたということじゃ!!
- トータル、62個
- 共感したこと(Empathy)、17個
- 学んだこと(Learn)、34個
- 疑問(Problem)、4個
- 次の行動(Action)、7個
共感したこと(Empathy)
- SVで、会社をやめる時の理由
マネージャーが良くないから辞める。
- ordinary people
普通の人だし、普通の事。
でも、浸透しきっているとは言えないので、知らぬ間に力関係が偏ったりする。って思ってる。
そして、恐れ知らずに意見を言うエンジニアは貴重。
- EMPOWERED
どのセッションも、プロダクトよりも先ず人が大切という気持ちが溢れてた。
社員もそうだし、ユーザーさんにもそうだし。
良い人、チームじゃないと良いプロダクトも生まれないよね。
- 自律と責任のもたせ方、もってもらい方
ただ自由ではない、責任とセット。
ふと高校の校則を思い出した、何年前だっつの。
でも、伝道師的なメンバーで組みたいけれど、パートナーの方には"契約"の話があるから、
正しくは持ってもらってはだめな責任もあったりするよなー。とも思った。
自分やパートナーの方もそんな事気にしない人たちだけれど、商習慣というかルールとして線引きがあることは覚えておかないとね。
- 同じものだと思ってたら本質が変わっていた。
表層ではなく、ソースを確認する。
- いきなりコントローラーを渡す宮本さんの話
ほんとそれ。
- 一体感を持って連携しているようで、きれいなWFしてるだけ問題。
イテレーションをするんじゃ!
- ユーザーが本気になるタイミングで｢運用だから｣と人が減らされる問題。
ずっと作り続けるんじゃ!
それがアジャイルじゃ!
- 考えて考えて考えて、ぼーっとしたときにフッとアイデアが出てくる。
PdMって毎日8時間、就業時間に沿ってに働く仕事でもない。
常に考え続けてる。
- 自分に仕事をあわせる。
仕事に自分をあわせない。
- メランビアンの法則
ボディランゲージ55%、トーン38%、言語7%
信頼にはコミュニケーションが必要か?
まぁ必要な要素の一つだと思うんだけれど、それを考えたらコミュニケーションをしっかりとるには、ボディランゲージとトーンを外しちゃ駄目だな。
チャット"だけ"は向いてない。
例えば、リモートワークのチャットだけはやっちゃ駄目だなー。
- PassionはEgoではない。
熱すぎる情熱は、Egoになる恐れがある。
周りは熱狂させても自分は常に冷静に。
- 音楽さえもPdMに役立つ!!
どんな経験が今に活きるのかわからない。
どんな経験も解釈しだいで今に活きる。
自分も、あれとか、これとか全く今の仕事に関係ないところだけれど活きている感とても感じる。
- 徹底した透明性。
全公開。
- 提供と価値と時間軸
裏で手動で動かしてもいい。
それでスループットはよくないが、検証にも活用できる。
神業BOTもいいけれど、拘りすぎない。
- PDMに型はない
状況に対して、レバレッジを考える。
経営者目線。経営者的ふるまい。
とにかくなんとかする。
- 組織問題もメカニズム
日本は、プロダクトアウトなことが多い。
IT業界では、そうでもないけれども、製造は自分たちの都合でやりがち。
そういうったことも、メカニズムで対処する。
学んだこと(Learn)
- Product Discovery
Valuable,Usable,Feasible,Viable
価値があること、使えること、
｢日本とSVで違いがあるからできない。｣ということではない。
- Product Team
Feature Teamと対比されていたのが印象的だった。
｢ロードマップを解消するでない、問題を解消せよ!｣
｢機能のを作るではない、製品を作るのだ。｣ということかな?
納品するだけでなく、ビジネスの成果も考える。
それでいうと、製品を作るに留まらず、ストーリーまで作り込んで行きたいな。
という考えに至った。
- ビル・キャンベル氏
www.amazon.co.jp
まさか、GA(F)Aの(Fは外されてた。)共通点としてコーチを挙げてくるとはサプライズ。
｢リーダーシップは、コマンド･アンド･コントロールではなく、環境のマネジメントをしてカスタマーに向かわせる事｣
最後のセッションで佐藤さんが｢頭の中に必ずカスタマーを。｣って言っていたことも想起される。
心に刻んでおきます。
ちなみに、ビル氏は残念ながら数年前亡くなられてしまった。
｢自分をあまりフォーカスしないで欲しい。周りの活躍している人たちを見てほしい｣と言っていたそうな。
そういう方だったんでしょうね。R.I.P.
ふと、この映画も思い出したので貼っとく。
www.uplink.co.jp
- CEO(もしくは、経営層) VS Product Team
っていう関係がまま問題になったりするんですね。
共感している方が多そうだった。
自分はあまり感じた経験ないから、困っている方が多くいる。ということがわかった。
- プロダクトマネージャーは、ミニCEO
会社経営ができる人材をあてる。
けど、CEOではないので勘違いしないように。
- サービスを広く使ってもらうには口コミとかコミュニティとかそういう方法
プロダクトを好きになってもらう。
- ヨーロッパでは3年くらい前から内製化?が進んでいる。
そして、人はそのままに動きが変化している。
から、そんなに人に幻滅しなくてもいいのでは?ということかな。
- はげちゃびん問題
現場を信頼して判断を委ねればいいのに変な所で説明を求める人がいることで起きる問題の名前。
意思決定が止まっちゃうから。
まぁ、意思決定するには正しい情報が必要な場合もあるけれどね。
- PBIの管理方法
3スプリント分は作業着手できるようにしておく。
それから、荒くてもいいから先々までいれておく。
- 複数チームで1つの開発をしているなら、分散させないで1チームで行えるようにする。
プロダクトを作る為に必要な業務は、チームの全員が実施可能な方法で業務フロー、技術戦略を行う。
チーム内での分断が行われないようにする。
1チームで出来ない作業があるなら、そのチームで出来るような作業に置き換える。
そして、余ったチームは別のこと新しいことをする。
目からウロコ。
Visionがあっても大して機能しない。
忘れられちゃうし。
その点ストーリーテリングは覚えられやすいし、何よりも印象的。
静的ではなく、動的で主観的で因果関係が描かれたもの。
ストーリーの型、｢主人公(当事者)→問題→解決(主人公の変化)｣
｢自分が夢中になる物語を!!｣
ヒーローズジャーニーは、ハリウッドの起承転結。
そして、ストーリーを計測する。定性的でも。
ポエム。
プレスリリースでフィードバック得たりするやつ。
- 学会の人は、ビジネスに興味がないので研究が結果が共有されないw
で、放置されるw
- いろいろな発想方法
制約的発想、そもそも発想、音楽は右脳を埋める。芋づる発想。
そもそも、ドッグフーディングってそういうモノなんだったんだろうけれど、なんだか自分の中では｢場を作って実施する。｣みたいな手法感があった。
日常的に実施するでもなく日常に取り込むことが真のドッグフィーディングだ!!
みたいなこと思った。
『プロダクトイン』『自己中心設計』
- ユーザーの体験を変化させる。
デバイスまで作っちゃう。ある種の『自己中心的』な発想なのかな。
ユーザーのストーリーやシーンにあったものを提供して使ってもらう。ではなく、
そもそものストーリーやシーンを変えてしまうほどの環境を作ってしまう。
- 指揮者(プロダクトマネージャー)は解釈を提示する。
合奏は、楽譜を再現する活動。
指揮者は、そのペースを守ること。ではなかった。
指揮者は、解釈を届ける。
｢赤ずきんちゃんがお婆さんに食べられないように(演奏する)｣ << 楽譜に無い解釈によってチーム全体の動きが統一される。
解釈によって、機能やストーリーも見え方が変わってくる。
無駄なもの必要なものが解釈によって変わってくるし判断できる。
コンセプト、ストーリー、コンテクスト。
要件は考えない、要求を考える、それ以上に解釈、ストーリーを伝える。
置かれている環境情報を伝え、自ら何が必要で不要かを判断できるようにする。
- 自律するシステムづくりをする。
人間、自動だと不満。
自分でやってる感必要。
そもそも全部自動とか難度が高い部分がある。
なので、人に対して自然と協調できるシステム。
システム任せではないモノをつくる。
半自動化。
- Think Big(大きく考える)
打席に立てるのが大事。
打席に立ちづづけるのが大事。
SVでは、ホームランを打つのに必要なヒット数(と質)という思考。
ある点から試行し続けるではなく、ある点に向けて試行し続ける。
目的が大事、みたいなことだと解釈。
- ペルソナは一回横に置く。
世界を見るとペルソナ作っても、ダイバシティーありすぎ。
(捉えきれなくなってる?)
- 強く信じるが、拘りすぎない。
柔軟性を持つ。
新しい事実が出てきたら、やりなおす。
- データドリブンは必須。
データドリブン出来るようになるのは｢できたら必要｣ではなく、必須のスキル。
直感は使うが頼りすぎない。
｢事実は何か?｣ << ｢誰が言ってるの?本当にいってるの?｣
日本はそういう確認は避けられがち。
これを避けてはいけない、これは｢リスペクトある批判｣である。
- 分けて考える。大きすぎるなら。
分け方によって熟練しているかどうかわかる。
｢何故、そのように分け方なのか?｣
そして、優先順付けと説明責任を持つ。
- やりきる力、実行力
知らないことでもやりきる力。
PDMは自分の人生も解決させることができる。
- シリコンバレーは玉石混交
Hire Slow ,Fire Fast.
Go Big or Go Home.
大きくやらないなら帰れ。
- 上手に失敗する。
レイオフなんて日常のこと。
次のチャレンジの始まり。
学びがいのある失敗の為に、賢く挑戦をする。
- 上手に失敗する1、成功しているとしたら何が必要か?
過去からの視点。
｢あれがあったから成功した。｣のあれとは?
- 上手に失敗する2、プリモーテム、失敗するとしたら何か?
未来からの視点。
｢何で失敗し"た"か?｣と考える。
むきなおり的な。
- プロダクトアウトとマーケットインは対立ではない。
価値を考える手法。
両方使えばいい。
- ワクワクさせる。
人は、感情で動く。
顧客にも社員にもワクワクしてもらう。
セールスの時、機能を説明しない、楽しく見てもらえるようにする。
利活用で、前向きなイメージを持ってくれるようにする。
遠隔のモノは遠隔で実際に見てもらうとか。考える。
- 新しいビジネスの考え方
一見愚かなアイデア
先ずマネタイズしない
新しい行動パターン
競争が激しい飽和市場
経験が無い創立者
- ピラミッド型組織
ピラミッドってお墓じゃん。
お墓な組織。
- プレイングマネージャーはNG、ポートフォリオマネージャー。
- OKRは野望を掲げる。
7割で成功。
- 新しい機能への流入を促すには｢オススメ｣表示
1年半くらいで既存機能から新機能への使用率が逆転した。
疑問(Problem)
- PDMのスキル定義をしないと、PDMできません。不安です。みたいなのはなんか違う感じがする。
そもそも向いていないというか…。
やりきる力みたいな事は必要だし｢そういう力あったらそうならなくない?｣みたいなことを思う。
そして、PDMのあり方に悩む人ってPDMをやらされているような気がしちゃってる。
組織の戦略とか教育とかそういう場合には必要になるのもわかりますけれども。
それにしたって、面白みとかで伝える方がいいよなー。
なんか型にハマる感じがして｢仕事をしているだけ。｣みたいな印象がある。
別の面として、スキルを定義するにも自分の弱点を克服するためとか伸ばすためとかそういう発見器みたいな使い方とかもあると思うけれど、
まぁ、スキル定義に興味を持っている方が多かったらしく、なんとなくそんな事を思った。
- やりきる力ってどう図る?
構造化面接?
行動面接?
適性診断?
- OKRのすり合わせはともすれば、コマンドアンドコントロールになる?
プロセスの踏み方なのかな?
組織ではなくて個人に尊重していればいいのかな?
重心の置き方なのかな?
- 複数チームで1つの開発をしているなら、分散させないで1チームで行えるようにする。
に名前が欲しい。
次の行動(Action)
- ドラッカー風エクササイズ
- ムービングモチベーター
- プロダクトを解釈しなおす。
コンセプトを確認する。
- プロダクトの価値を分割する。
そして、ストーリーを立て直す。
- セールスのストーリーを考える。
小芝居考える。
- OKRが目に触れる頻度を増やす仕組みづくりをする。
- カスタマーを頭の中に常におく。
