pmconf2023まとめ

rince
·

pmconf2023で見たセッションのまとめ。

プロダクトマネージャーの「覚悟」を分解する(及川 卓也・吉羽 龍太郎)

内容

学び・感想

  • NOと言うのにコストがかかるのであれば、時間をかけて説得するよりとりあえず試してみる方が速い

    • そのための検証基盤がある前提

  • チームの中にとどめておくのは一番ダメ。それだと妄想(仮説)のまま

    • 社内でもいいのでリリース/dogfoodingして外の目に晒す

    • とにかくチームの外に出すのが大事!

  • プロダクトは撤退か継続投資しかない

    • 撤退しないが投資もしないのは、戦場で補給がないインパール作戦のようなもの

  • 使われない機能はどんどん削るべき

    • 運用コストはコードの量の二乗に比例する

    • 何かを足したら何かを消すくらいがちょうどいい

    • PBLに機能削除のチケットを入れる

シリコンバレーのプロダクトマネージャー達に見る、 覚悟を決めたPMは何が違うのか?(曽根原 春樹)

内容

  • Step Changeに挑もう!

    • 「右肩上がり」だけがグロースではない、非連続な成長

    • ex. インスタのストーリー、Amazonの1クリック注文、Slackのスレッド

    • 視野を広げると?視座を高くすると?さらに大きく成長するには?

    • やるとなったら強く信じよ、だが頑固にはなるな

  • ユーザーに価値があると思う「何か」をリリースしただけで満足していないか?

    • 収益性・インパクトなき価値には時間をかける意味はない

    • 当たり前品質をいくら実装し続けたところで一切プロダクトの魅力にはならない

    • 当たり前品質を実装し続けて仕事をした気になっていないか?いつになったらプロダクトの魅力を高めるのか?

  • ビジョン実現に向けて、正しい方向に進んでいるのかを計測しなければ意味がない

  • LNO Framework

    • Leverage(最もインパクトのある仕事)が力を入れるべきとこ

    • NeutralとOverheadは任せる・省く・最小化する・やらない

  • クリティカルシンキングはロジカルシンキングを包含する

    • 一段高いところから思考を深ぼる

    • なぜXXのように考えるのか、なぜそう感じるのか?外側から自分や空いてを観察する(Metacognition)

学び・感想

  • mybestも次のStep Changeが必要なフェーズに来ている

  • 当たり前品質をいくら実装し続けたところで一切プロダクトの魅力にはならない

    • 「当たり前品質を実装し続けて仕事をした気になっていないか?いつになったらプロダクトの魅力を高めるのか?」というのはガツンときた

    • 当たり前品質はさっさと達成して魅力的品質にリソースを投下する

  • Leverage(最もインパクトのある仕事)に力を入れる

    • NeutralとOverheadは任せる・省く・最小化する・やらないを意識する

  • Metacognition、しずかなインターネットに自分の思考を吐き出していくのはいいトレーニングになるかもしれない

変化を生み出すために大切なこと4選(鈴木 森人)

内容

  • 一次情報を複合的に取得する

    • 情報収集の手法にはそれぞれ弱点があるので組み合わせる

    • インタビュー、アンケート、マニュアル、オブザベーション

  • 分析よりも実行を優先する

    • 計測や分析は手段

    • 全て観測してから施策決定では遅すぎる

    • 走りながら課題と解決策を見直す

  • 合意形成とムード醸成は丹念に

    • 理性と感情に働きかける

  • ときには泥臭くやりきる

    • 知恵は絞りつつ、時間の消費を抑える

    • 必要ならお金と手間は惜しまない、イニシャルコストは追々無視できるのでスピード重視

学び・感想

  • 「分析よりも実行を優先する」というのは前期に2ヶ月ほどPM業やった時の一番の反省点

    • 課題把握のための分析に時間を使い過ぎたので、もっと実行しながら解像度を上げていくべきだった

    • 実行しながら見えてくる情報量の方が多いので走りながら考える

    • 分析している間は外から見ると何も成果が出ていない状態

    • もし何か理由があって分析を優先する場合はPOとの期待値調整が必須

社長=プロダクトオーナーから、意思決定の権限をPdMが獲得する方法(吉川 徹)

内容

  • 社長は2つのタイプに分かれるが、どちらにしてもSyncすることが重要

    • ビジネス型 → PL視点で考えよう

    • プロダクト型 → サービスへの圧倒的愛情が大事

  • 社長=プロダクトオーナーと対話する時におさえるべきポイント

    • なんでも言い合える関係性をつくる

    • 早いレスポンスを心がける

    • 社長の孤独を理解する

    • 朝令暮改に適応する

    • 失敗したら「やめる覚悟」ではなく、失敗しても「やめない覚悟」を見せる

学び・感想

  • 吉川さんも食べログの村上さんも朝令暮改の傾向は強い

    • 根本の考え方は変わっていないけれど、昨日あったできごとや会った人によって情報がアップデートされて、表面上の意思決定は変わり得る

    • 過去に囚われずに現時点での最善を常に選択できるのはCEO(やPO)としては大事な素養とハートな気がする

    • この意思決定に対して議論し、真の意図まで理解した上で変化に適応できる組織は強い

  • 「失敗したらやめる覚悟ではなくやめない覚悟を見せる」というのはいい話

    • CEOは辞められない

    • 失敗したら辞める覚悟で来られても尻拭いするのはこっちなので、失敗しても成功するまでやり続ける覚悟で来てくれた方が任せやすい

Notion AIでのプロダクトマネジメント〜顧客の声を活かした高速な仮説検証(早川 和輝)

内容

学び・感想

  • 愛されているかどうかをプロダクトの成功指標に入れているのよい

  • Notionは最初はノーコードのビジュアルプログラミングツールだった

    • 行き詰まって日本に旅行したことがきっかけでピボットした

    • 今使われているNotionのコードの最初の1行は京都で書かれた

  • Notionではプロダクトマインドセットを持ったエンジニア/デザイナーの採用を心掛けている

    • コーディングやLLMの開発に長けているだけでは採用しない

    • ビジネス面を考えられるか、ユーザーのことを考えられるかを重視している

  • CEOとCTOが全社オフサイトもそっちのけでホテルに缶詰めでNotion AIのプロトタイプを開発するという話はアツかった

    • OpenAIのAPI発表からわずか数週間でアルファリリース

    • Notionの規模・ユーザー数になってもこのスピード感を持っているのはすごい

  • リリースしてユーザーの声を聞きながら大胆に改善していくの大事

    • Notion AIは最初は「物書きを代替するもの」だったが、アルファリリースのユーザーFBを受けて「自身で書いた文章をよりよくする存在」にピボット

  • 汎用的、かつ特定の問題を解決できるようにする

    • 「なんでもできる」 ではユーザーは持て余し過ぎてしまう

  • Beautiful and useful

    • 最もシンプルで、最多の問題を解決できる、使いやすいものを目指す

プロダクトと事業を無限にスケールするための最強のロードマップの作り方(山崎 聡)

内容

学び・感想

  • 安心感を捨てて「楽ではないが儲かる」方向に舵を切る

    • 「楽だが儲からない」から「楽だし儲かる」に行くことは困難

    • 「楽ではないが儲かる」から楽ではないことを自動化などで楽にすることは可能

  • 最強のロードマップとは、拡張可能な世界観から「動的に生成される」

    • ドラクエやドラゴンボールも最初からその後の展開は計画されていなかったというのはなるほど

    • 読者やユーザーの反応を見ながらどんどんと世界観が拡張されていった

    • 固定化せずにユーザーの反応から動的に世界観を拡張していく

  • 意思決定のWRAPプロセス知らなかった

    • A(決断の前に距離を置く)とP(誤りに備える)は忘れがち

  • mybestも拡張可能な世界観からロードマップが動的に生成されている感はある

    • ここからさらに世界観を拡張してネクストカーブにジャンプしないといけないが、どう拡張していくかの見極めが必要

成果が出ないユーザーインタビューは何がダメだったのか? ~「誰に聞くか」の探り方 ~(湯川 晟)

内容

学び・感想

  • 成果につながるユーザーインタビューは「誰に聞くか」が大事だが、それは事前には定義できない

    • 成果とはプロダクトのSOM(アクティブユーザー)・SAM(ポテンシャルユーザー)が広がること

    • 最初は「ゼルダの伝説」などオープンワールドのRPGの初期状態

  • 序盤は解像度を上げるために探索的インタビューを行い、それを元に行動パターンでユーザーを分類して、誰に聞くかの優先度をつける

    • 何人かに話を聞いて構造を整理

    • 行動パターンを分岐させる前提条件を分析していく

    • 優先度をつけるコツは非合理・予想外の行動

  • 最終的に成果につながる対象者選定ができたかを戦略観点でチェックする

    • 狙いをつけた対象者は十分なボリュームがあるか

    • 代替手段からの乗換理由を実現できるか、攻略可能か

    • 「今」攻略すべき対象か

  • 実際に自分たちのチームでもユーザーインタビューをしているが、「誰に聞くか」をここまで意識できていなかった

    • 行動パターンを分岐させる前提条件を分析していく話はとても参考になったのでぜひ取り入れたい

CPOが開発する覚悟 〜コンパウンドスタートアップにおける、爆速の新規プロダクト開発スタイル〜(榎本 悠介)

内容

学び・感想

  • 「作るのが大変な時点で、なんらかユーザーにとっても複雑で認知負荷が高い仕様になっていて、最適でない可能性が高い」は、わかりみが深すぎて首がもげた

    • 考える時はいろんなケースを想定して複雑なことを考えつつ、最終的な仕様はシンプルにしたい

    • ユーザーのためにも、プロダクトのためにも、開発チームのためにも

まとめ

今回のpmconfのテーマは「その覚悟が世界を変える」

全体を通して、

  • 仮説をチームの中にとどめておくのは一番ダメ、それだと妄想のまま

  • 最速でリリースしてユーザーの声を聞きながらどんどん改善していく

というのがいろんな人からも繰り返し語られていて一番心に残った。

頭ではわかっていたが、それを実際に日々実践している人たちの話を聞いて、うちもまだまだもっとできるなと。

そのためにも、

  • 全ての情報が揃いきってなくても今ある情報の中で意思決定する覚悟

  • 未完成なプロダクトを人に使ってもらう覚悟

が必要だなと感じた。

@rince
エンジニア。旅とキャンプとサウナがすき。