名著再読「プロダクトマネジメントのすべて」ミニCEOと呼ばれるPdMの役割を現場から読み解く

本編に入る前に、二人は10月4日に開催されたインサイドセールスカンファレンスの話題から始めます。浜田さんはスポンサーとして参加し、セッションの盛況ぶりを振り返ります。

浜田さんによると、登録者数は去年と同程度の1600〜1700人ほどで、来場率も高かったといいます。SaaS企業だけでなく、さまざまな業界からインサイドセールスに関わる人が集まっていた点も印象に残ったと話します。

浜田さんが特に感心したのは、イベントの動線設計でした。セッションとセッションの間に必ず30分の間隔があり、終了ごとに一度退場して再入場する仕組みになっていたといいます。

再入場が予約制でQRコードを読む方式のため、30分ごとに人の波が生まれ、その流れの先にはカツサンドやコーヒーを置いた交流スペースがあったといいます。参加者が自然に交流の場へ向かう作りに、浜田さんは考え抜かれた動線だと評価しています。

ここから本編に入ります。今回のテーマは「名著再読」で、取り上げるのは日本で書かれた「プロダクトマネジメントのすべて」です。清沢さんは、この番組の前半ではこれまで海外のセールス本などを扱ってきたと振り返ります。

前回はPMM(プロダクトマーケティングマネージャー)を扱ったのに対し、今回はPdMという文脈で本書を取り上げるといいます。2021年出版ながら、プロダクトマネジメントの本として広く読まれている一冊です。PMMPMM ── プロダクトマーケティングマネージャー。プロダクトをどう市場に届けるか、どう売るかを担う役割

浜田さんは、著者陣がプロダクトマネジメントを普及させる目的で書いていると感じたと話します。宣伝ではなく実務に根ざした内容である点に、この本の価値があると見ています。

清沢さん自身はPdMの経歴はないものの、前職時代にこの本が出た当時、界隈で「読んだ方がいい」と言われて読んだといいます。PdMでなくても、マーケティングやインサイドセールスに関わる人が読んでも活かせる本だと話します。

浜田さんがこの本で最も納得したのは、広義のプロダクトと狭義のプロダクトという定義でした。プロダクトマネージャーというと要件定義書を書く人というイメージがありますが、この本ではそれだけではないと説明します。

浜田さんによると、狭義のプロダクトはソフトウェアそのものを指します。一方、広義のプロダクトは、そのソフトウェアを世に出すための営業、PR、カスタマーサポート、マーケティングを含めた事業全体を指すといいます。

この広義のプロダクトをマネジメントするからこそ、PdMはミニCEOとも呼ばれるのだと浜田さんは整理します。ものづくりだけでなく、事業全体のアラインメント(足並みの調整)まで期待される役割だという理解です。

本書はプロダクトの成長段階をゼロイチ、一十、十百の3つに分けて論じています。浜田さんは、この3段階でPdMの役割がまったく別のものになると説明します。

ゼロイチはPMFを探しに行く段階で、この時期にはPdMと経営者が分かれる意味はほとんどないといいます。一十はグロースの段階で、ものだけでなく売る仕組みの重要さが出てくると話します。PMFPMF ── プロダクトマーケットフィット。プロダクトが市場に受け入れられ、needに合っている状態

さらに十百はスケールさせていく段階です。本書ではこの段階をタウンビルダー系と呼び、コミュニティやエコシステムを作る役割だとしています。浜田さんは、ここまで来るとPdMというより事業部長やPMMに近くなると話します。

浜田さん自身はimmedioでプロダクトマネージャーを務め、まだゼロイチのイノベーター系フェーズにあると位置づけます。2022年に立ち上げ、PdMを採用したのが去年7月で、それまでの丸2年は浜田さんがPdMを担っていたといいます。

現在の体制では、PMFしていた1つ目のプロダクトをPdMに渡しつつ、プロダクトオーナーは引き続き浜田さんが担当します。新規プロダクトは浜田さんがPdM兼プロダクトオーナーを務める形です。

浜田さんは、プロダクトオーナーとPdMの切り分けをこう説明します。プロダクトオーナーは「何をいつ誰がやっていつまでにデリバーするか」をPdMやエンジニアリングマネージャーと合意する意思決定を担うといいます。

一方、顧客から上がってきた声を磨き、要件定義書であるPRDや優先順位の素案を作るまでがPdMの仕事だといいます。その素案に基づいて、経営の意思決定として何をどの優先度で誰にやってもらうかを合意する部分だけをプロダクトオーナーが担う流れです。PRDPRD ── プロダクトリクワイアメントドキュメント。プロダクトの要件定義書

話題は本書の107ページにあるロードマップ作成に移ります。浜田さんは、ロードマップをめぐっては「作るべきか」という論争があると紹介します。

浜田さんによると、USのPdM本「Inspired」ではロードマップを作ってはいけないと書かれているといいます。どうせやるべきことは変わるうえ、ロードマップ作りは妄想に近い行為でもあるため、製品ビジョンと製品戦略だけ決めればよいという立場です。

一方で「プロダクトマネジメントのすべて」では、ロードマップをちゃんと作っていく必要があると書かれているといいます。浜田さんは、この違いは企業規模やプロダクトの性質、向き合い方によって変わるのだろうと話します。

清沢さんも、BtoCかBtoBか、あるいはライフフェーズによって答えは変わると補足します。immedioのようにフェーズによっては市場の動きの方が速く、ロードマップよりリードで作れる場面もあると話します。

浜田さんは、直近の課題としてAIの進化のペースが読めない点を挙げます。immedioではフォーム通過後の条件に基づく商談判断を事前のロジックで組んでいましたが、これをAIで差配する構想があったといいます。

当初は、AIはブラックボックスで正しく動いているかの検証が難しく、スピードの問題もあって当分ないと考えていたそうです。ところがn8nのようなAIワークフローを見て、実現できると判断が変わったといいます。n8nn8n ── ワークフローを組んで自動化やAI連携を実現できるツール

浜田さんは、優先度を評価するRICEスコアの「難しさ」がAIによって急に下がる点に、ロードマップの難しさがあると指摘します。前提そのものが変わってしまうためです。RICEスコアRICEスコア ── Reach(リーチ)・Impact(インパクト)・Confidence(確度)・Effort(工数)の4要素で機能の優先度を評価する手法

さらに浜田さんは、プラットフォーム側の動きも脅威だと話します。OpenAIが自らAIエージェントビルダーを作ったことで、エージェントビルダーだけを提供するサービスがプラットフォーム側に食われる事態も普通に起きるといいます。

清沢さんは現在CSも担当し、毎日30個以上のフィードバックを見て、1個以上を処理していると話します。膨大な数からどう優先度をつけるかは大きな課題です。

浜田さんは、複雑にしすぎず、価値と工数のバランスで優先度をつけていると説明します。価値の面では、商談が増えるか、使いやすくなるかといった観点で点数をつけます。工数の面では、フィボナッチ数列を使ってポイントを見積もると話します。フィボナッチ数列フィボナッチ数列 ── 前の2つの数を足していく数列。0、1、2、3、5、8、13、21と続く

浜田さんによると、軽いものは1か2、1週間ほどかかりそうなものは5、13を超えて次の21になると1ヶ月かかりそうな相当ヘビーなものだといいます。1、2、3と連番にせず数の間隔が広がることで、規模感の違いをつけやすくなると話します。

清沢さんは、期待される価値を定義するときに、追加のアップセルや解約阻止でどれくらい効果があるかを見ているといいます。これはフェーズによる違いなのかと浜田さんに問いかけます。

浜田さんは、まずRICEスコアの4要素を整理します。リーチは何人の顧客に価値を届けられるか、インパクトはどれだけ深く課題を解決できるか、コンフィデンスはその確度、エフォートは工数です。この4要素を正しくつけていくのは多くの企業がやっているはずだと話します。

浜田さんは、大企業になるとPdMが増え、一人が担う範囲は特定の機能だけになると説明します。その場合、対象となる顧客数を細かく試算して価値を計算するアプローチもあるといいます。

浜田さんは、そこまで厳密に試算しても前提がずれてしまうこともあると話します。どの粒度で計画と振り返りをやるかは難しい論点だといいます。

後半は、PdMに求められる知識やキャリアの話に移ります。浜田さんは「Inspired」に、優秀なPdMでMBAを取っている人は一人もいないと書かれていたと紹介します。浜田さん自身はMBAを取得しているため、苦笑しながらの話です。

その一方で、本書の19章ではビジネスの基礎知識が非常に大事だとされているといいます。会計を含めたお金の知識と、開発の最低限の知識の両方が必要だという整理です。

浜田さんによると、著者の及川さんはPdMに必要な知識としてビジネスの基礎知識、UXの基礎知識、テクノロジーの基礎知識を挙げ、ビジネスを一番上に置いているといいます。開発の最低限の理解があれば、ビジネス側の人でもPdMになる余地は本質的にあると話します。

浜田さんは、自身のキャリアを完全な叩き上げだと振り返ります。MBA卒業後に商社で事業開発を経験し、その後Bitflyerで仮想通貨事業のアメリカ拠点立ち上げを任されたといいます。

当時、開発の知識がなかった浜田さんは、アサインされたエンジニアに任せきりにしていたといいます。ある日進捗を尋ねると、日本語を英語に置き換えただけだと返され、その理由に気づかされます。

その後Sansanで海外向けプロダクトを任され、Jiraでのチケット管理などをエンジニアに教わりながら見よう見真似で進めたといいます。優秀なエンジニアはPdMが細かく定義しなくても動けると感じたそうです。JiraJira ── 課題やタスクをチケットとして管理する開発向けのツール

immedioでも同じノリで始めたものの、リリースのサイクルをどう決めるかといった問いに直面したといいます。Bitflyer時代から数えて7、8年PdMをやってきたが、我流で始めたため今も学びながらだと浜田さんは話します。

技術側の理解について、浜田さんはプログラミングスクールでRuby on Railsを学んだ経験を語ります。ウェブサイトの裏側にはデータベースと言語があり、それをもとに動的に表示される仕組みを理解できたといいます。

一方で、実際のプログラミングにはフレームワークという裏技が多くあり、それを知っている方が強いと気づいたといいます。長くエンジニアをやっている人には勝てないと判断し、それ以上は深追いしなかったと話します。フレームワークフレームワーク ── 開発でよく使う機能をまとめ、書く量を大きく省略できる仕組み

浜田さんは、PMMとPdMには明確な境界線はなく、重なり合っている部分があると話します。ビジネスモデルを作ることやエバンジェリズムといった要素は両者に共通するといいます。

そのうえで浜田さんは、PMMはGo To Market側でPL責任を負い、PdMはものづくり側で価値そのものの責任を負うと整理します。役割の重心が異なるという見方です。

本書では冒頭で、プロダクトマネジメントをコア、Why、What、Howの4要素で構成しています。浜田さんは、コアにミッションやビジョン、WhyにWhoの世界、Whatにビジネスモデル、HowにGo To Marketが位置づけられると説明します。

清沢さんは、本書に出てくるプライシングや価格の話に触れ、そこまで踏み込めるPdMについて問いかけます。浜田さんは、どう売るかをある程度決めないと機能設計もできないと答えます。

浜田さんは具体例を挙げます。シート課金や1IDいくらと決めるなら、そのIDを持つメリットを明確にする必要があります。従量課金なら、どれだけ使ってもらえるかが焦点になるといいます。

浜田さんは、しっかり売上が上がらないと次につながらない以上、マネタイズモデルとプロダクト設計を結びつけるのはPdMの領域だと話します。PMMはその価値を正しく世に認知させる、後ろ側に来る役割だという整理です。

浜田さんは、immedioの機能追加がビジネスモデルを変えた例を振り返ります。当初はウェブサイトに組み込むタイプで、多くある日程調整ツールと競合しつつユニークな価値だけをとっていたといいます。

しかし顧客からは、似たツールを何個も契約できないという声が上がったそうです。そこでimmedio単体でも回る世界が必要だと考え、日程調整の普通のリンク発行機能を作ったといいます。

浜田さんによると、この機能はよく使われ、差別化の余地もあったといいます。清沢さんも、この機能によって価格やビジネスモデル、対象となる顧客の量が大きく変わったと感じたと話します。

浜田さんは、1つの機能を一人のエンジニアがばらさず作りきることの大切さも指摘します。役割を分けすぎず、価値のあるものを一気通貫で仕上げる姿勢が、現場での動き方として重要だという含意です。

まとめ

この回では「プロダクトマネジメントのすべて」を手がかりに、PdMがミニCEOと呼ばれる理由から、優先度づけやプライシングまでの実務、PMMとの境界線が語られました。名著の枠組みと、immedioの現場感が重なり合う内容でした。

• PdMがマネジメントするのは狭義のプロダクト(ソフトウェア)だけでなく、営業やマーケを含む広義のプロダクト=事業全体である
• プロダクトの成長段階はゼロイチ・一十・十百に分かれ、それぞれでPdMの役割は別物になる
• ロードマップを作るかは論争があり、企業規模やプロダクトの性質、フェーズによって向き合い方が変わる
• AIの進化はRICEスコアの「難しさ」を一夜で下げ、優先度の前提そのものを塗り替える
• PdMには開発の最低限の理解とビジネスの基礎知識の両方が必要で、ビジネス側からPdMになる余地は本質的にある