メモ『プロダクトマネジメントを学ぶ夏』
たまたまTwitterで見かけたウェビナーに参加したので、そのメモになります。
参加したセミナー
https://codezine.jp/article/detail/12647
参加した目的
今年の4月から、転職し新たなプロダクトに参画したが、マネジメント部分に一抹の不安を感じる。課題感などをしっかりととらえられるように、プロダクトマネジメントについて学びたいと感じた。
また、チームのマネジメントが非常に軽視されている部分もあり、何か打ち手のヒントになることを得られないかという目的もある。
プロダクトマネジメントの基本
◆スピーカー
及川卓也さん
プロダクトマネージャーが調整役で終わっていないか？
調整と口に出しているときはPMの付加価値を出せていない可能性が高い
橋渡しをする人ではなく、すべてを網羅的に考えられる人物であると考える
単に分業制を進めるのではなく、全員が「プロダクト志向」を高める
→プロダクト志向が高いチームを作ることもPMの仕事
プロダクトマネージャースキルの「木」の育て方
◆スピーカー
曽根原さん
◆土壌選び
ドメインを選ぶ（自分が興味あるドメインは？）
いくら育て方を知っても土壌がよくない（= 強い興味がない）と育ちにくい
・ビジネス
・BtoB
・BtoC
・GtoC
・etc
・テクノロジー
・AI
・IoT
・Mebile
・etc
・プロダクト
・Saas
・ConsumerHardware系
・etc
◆継続して育てるために必要なもの
好奇心の3軸 = 強さ×広さ×深さ
～型人材モデル
I → T → π → ？
I：特定の領域を深堀していく
T：自分の専門領域の周辺を知っていく
π：専門領域が複数になっていく
プロダクトマネージャーのスキルはπ型の先にある
→W型
・様々なドメインを知ることによる視野の広さ
・隣接エリアも含めた適度な深堀
・知識や経験の交点から新たな洞察を産む
◆深さはどこまで追求すべきか？
PM ≠ 特定分野の研究者
PM = ユーザーの問題の専門家
様々なドメインプロフェッショナルに対して
・言ってることがわかる
・質問ができる
・コメントから視点を広げられる
プロダクトマネージャーは両利きを目指そう
PdMは、プロダクトの構想～立ち上げ～育成を担う
各専門性を結集させ連動を滑らかにするためには
それぞれの領域の知見が必要
manageは「どうにかする」こと
→ラフに定義すると「プロダクトをどうにかする人」
→なのでミニCEOなわけ
組織責任をCEO、事業責任をPdMが担う
◆ターン・アラウンド
働きかける→反応を得る→理解を正す（学ぶ）
行って帰ってきて、の期間をいかに短くするかが腕の見せ所
ターンアラウンドのmanageとは？
manageは2軸
何を学ぶために？
・有用性、有意性
我々が提供するものに価値があるか？
→ノーコード検証（ユーザーインタビュー、プロトタイプ検証）
・継続性
継続的に価値を感じてもらえるためには？
→MVPによる検証
・可能性
より提供する価値を高めていくためには？
→ノーコード検証とMVPによる検証を織り交ぜる
ターンアラウンドが長いほど、その間プロダクトを間違い続けている可能性がある
早く失敗せよという話だが、本質は失敗から学びを得ること
→学びを得るまでの距離を短くすること
※「失敗」というワードを受け入れられない人・組織もある
やってみようで始めればいいっわけではなく
学習のためのターンアラウンドを最小化する =
間違えている期間を最小する
ターンアラウンドが長い =
負債を抱える期間（わからないままの時間）が長い
アジャイルは開発内のターンアラウンドを短くするもの
→ターンアジャイルを短くする＝アジャイル ではない
→あくまでアジャイルな状態になるための1要素
全体の段階設計とスクラムで、ターンアラウンドを構造化している
◆両利き（仮説検証＋アジャイル開発）
仮説検証のみ、偏重
・プロダクト開発時の「開発内ターンアラウンド」が長い
・現物ベースの有用有意性、継続性の理解が遅れる
アジャイル開発の身、偏重
・「全体のターンアラウンド」が長い
・多大な時間をかけてっわかることが小さいという事態
詳細はそれぞれの専門家に任せるとしても両方の知見がないと正しい判断ができない
◆分担による分断を超えるために仮説検証の外在化、重奏化を目指す
・仮説の不在
・仮説の外在化
・仮説の重奏化
◆まとめ
・PdMとはそれぞれの専門戦を結集させる
・プロダクトマネージャーとは、ユーザーの反応にただただ反応していくための存在ではない
そ前提の上で、ターンアラウンドを用いて学びを得ていく