プロダクト主導型開発組織の探求 | 講演メモ#1

「プロダクト主導型組織（PLO）」の概念や基礎について

Product Management Lounge #1「プロダクト主導型開発組織の探求」 (2022/03/23 19:30〜)

── 「つぎの一歩を応援する、気づきと繋がりの場」 Forkwell Lounge シリーズ。 これまで Forkwell は、エンジニアの成長を支援すべく各専門領域（インフラ・フロントエンド・データ分析基盤・機械学習）を統合的に学べる勉強会シリーズを企画してまいりました。技術を学ぶ目的の一つに、 「顧客に価値を届ける」 があるのではないでしょうか。 2021年10月に発刊された『 ...

https://forkwell.connpass.com/event/240477/

プロダクト主導型組織（PLO）とは

プロダクトを単なる売り物とみなすのではなく、戦略上の打ち手の中で最も重要な資産とみなす。（略）プロダクトを最初にリリースすること以上に、その後の段階に重点を置く。（略） また、徹底的にデータドリブン。（略）継続的にデータを計測し、そのインサイトから、ユーザーにより多くの価値に気づいてもらい、同様にプロダクト自体もより良いものにするのだ。

プロダクト・レッド・グロース（PLG)とは

• 2016年にOpenVIew(VC)が提唱

• 「プロダクトそのものを顧客獲得、コンバージョン、拡大における、主要な原動力とする、エンドユーザー重視のグロースモデル」

• 対比：Sales-led Growth (セールス主導型グロース）

• PLG例 : Slack, Calendly, Dropbox, Zoom, Canva, Notion, etc.

大事だと思っていること

• 決して「Sales」が悪いわけではないし、決して常に「Sales-led」がよくない訳でもない。

• 「Product-led」だからといって、セールスやマーケティングがいらなくなるわけではない。

• 「Product-led」かそうではないかの二元論ではない

PLG3つの柱(from Openview)

1. エンドユーザーのためのデザイン

2. 価値が得られる前に、価値を（こちらから）提供する
1. ユーザーが「アハモーメント」に到達するまでの時間(Time-to-Value)の短さ
2. カスタマーの成功の優先

3. Go-to-Marketの意図を持ちプロダクト内へ投資
1. プロダクトデータへの投資（プロダクト内行動データの収集、計測、分析）
2. プロダクト自らグロースする機能
 
 

• ＜大前提＞確実にエンドユーザーのペインを解消するプロダクト

• フリーミアムモデル、フリートライアルモデル（または容易なデモ）
• 顧客流入の裾野を広げる

• プロダクト内オンボーディング機能
• 確実かつ早期に、価値を実感してもらう

• セルフサービスを助けるガイド
• ユーザーにとっても面倒な「サポートしてもらう」を減らす

• ユーザーによるリファラル、レビューの促進

• 上記の継続的な改善のために「データ」で会話、意思決定をする

プロダクト主導型組織（PLO）とは

「プロダクト主導型組織」登場の背景

1. データの影響力の向上
1. データ活用の一般化

2. 市場の過密
1. 新しいアイデア、人目をひくマーケティングだけでは勝てない

3. 購買者の変化
1. IT部門ではなく、エンドユーザーが決める

4. プロダクトのためのシステムの登場
1. データ収集/分析、フィードバック、アプリ内ガイドなどのツールの一般化

プロダクト主導型組織の特徴

1. プロダクトに地位を与える
1. プロダクトチームに企業のロードマップを推進し、戦略を策定し、目標を設定する正式な権限がある
2. CPOを置くことで、プロダクトの重要性を内外に示す

2. データインフォームドである
1. MRR、LTV、NRRなどのメトリクスはもちろんのこと、プロダクト利用状況、機能定着状況、顧客維持率、環状データなどの定量/定性両方のプロダクトメトリクスや先行指標を利用して意思決定する。
2. データがなければ実験を行ってデータを収集する

3. （顧客に）共感的である
1. 顧客と共に過ごし、顧客の「ジョブ」が何かを理解し、ペインを解決するプロダクトを作る
2. 顧客が価値を早く感じられるようにオンボーディング機能の設計をする（Time-to-Valueを短くする）
3. フィードバックを積極的に集め、すぐ要望に応えられなくても誠実にコミュニケーションを決着させる
4. データを利用したカスタマーヘルススコアを算出し、推移に応じて顧客の課題にあらかじめ手を打つ

4. （組織内はプロダクトを中心に）協調的である
1. マーケティング担当と、プロダクト自体が顧客獲得ツールになるには何をすれば良いか共に考える
2. 営業担当と、トライアル顧客のCV率を最大化するためにプロダクトをどう活用するか共に考える
3. カスタマーサクセス担当と、データから得られる成功顧客のインサイトを共に考える
4. プロダクトOpsは、フィードバックを共通のリポジトリに集約し、構造化して社内にレポートする

5. プロダクトこそが顧客体験である
1. プロダクトとの魅力を感じ、どんどん広めてくれる「アドボケイト」をどう増やすかを考える
2. プロダクトの価値を少しでも早く感じられるオンボーディング機能を、データを用いて設計する。パーソナライズされたオンボーディングを実装する
3. 迷わないシンプルな機能とUIを提供する。困ったことがあってもユーザーが自身で解決できるガイドを用意する。

プロダクト主導型ではない組織の特徴

1. プロダクトに地位なんていらない
1. プロダクトチームは、CEOや偉い人が決めたロードマップ、戦略、目標を遂行すれば良い

2. データなんていらない
1. HiPPO(Highest Paid Person’s Opinion）で意思決定する

3. 独善的である
1. 自分たちの都合で作ったものを売る。導入がゴールなので、顧客が活用できるかは顧客の責任
2. オンボーディング機能は、こちらが取りたい情報を入力させるように設計する
3. 顧客からのフィードバックは聞かない。聞いたとしても聞きっぱなしで良い
4. 顧客維持は、顧客と相対する営業担当の感覚のみが大切である

4. 組織は縦割りである
1. マーケティング担当は、派手なキャンペーンで短期的に見せられればそれで十分と考えている
2. 営業担当やカスタマーサクセスは、自分が担当する顧客さえ成功すればよく、そのための機能が優先的に実装されれば良いと考えている
3. 顧客からのフィードバック情報はそれぞれの組織に分散しており、知ることは難しい
4. プロダクトチームやエンジニアリングチームこそが社内の権威であると考えている

5. プロダクトと顧客体験は別物である
1. プロダクトには、派手なキャンペーンや営業資料があれば売れる。デモも人手で作れば良い。
2. プロダクトのオンボーディングは、カスタマーサクセスチームがWebinarをやれば良い（もちろんWebinarも大事ではあるが）
3. プロダクトで困ったことがあれば、サポートに電話で連絡してもらえば良い