プロダクトマネジメント実践講座: シリコンバレーの現役プロダクトマネージャーが伝授する、伝わるプロダクトアイデアの書き方 | Udemy

基本知識

PRD とは？

プロダクト開発または機能開発を通じて、実現したいこと示す プロダクトマネージャーの考えを記したドキュメント

特性	PRD	その他 ( 例: 仕様書 )
誰向け？	全社的に横断	PG のみ
更新タイミング	継続アップデート	一度書いて終了
内容の深度	要点をハイレベルで記述	詳細を落とし込む
伝達したい内容	Why & What & When	How to...
目的	プロダクトチームの想像力を引出す	チームをルールで拘束する

PM のコミュニケーション

コミュニケーション通過思考を元にしたチーム構築

要素	実例
インスピレーション	モチベが高まるようなプロダクトビジョンやチームメンバーの強み、得意なこと、ポテンシャルが十分に発揮する機会
タスク	メンバーにとって適度なタスクを提供興味のある新ツール試行メンバーのリソース有効活用情報の透明性やサポート体制を構築
ポジション	メンバーがチームに参加してもらうことによる社内への認知拡大と評判向上「選ばれし者」としての認識
関係性	チームの中にいて良いという感覚を提供話を聞いてもらえる助け合えるという心理的安全性を提供
プライベート	仕事その他個人的な出来事を共に喜んだり感謝し合えることメンバーの自己イメージ向上仕事へのオーナーシップ提供コンフォートゾーンの尊重

価値を下げる事例
- 相手の頑張りを認めない
- サポートしない
- チャレンジさせない
- スプリント終了近くの時に、終わらせるよう恐喝
- 相手の評判に傷をつける

PRD の５形態

1~4 までの形態を経て、PRD は姿を現す

Product Vision
Product Strategy
Product Roadmap
Product Concept
Product Require Document

Product Vision

目的
- プロダクトの「なぜ」に対する説明
- プロダクトに関わる人に対して、同じ方向を向いてもらう
- 全ての意思決定は、ビジョン実現のためにする
- 必ずしもユーザの方向を向く必要はない
やること
1. 以下の特性を持つ「実現したい言葉」を文字に起こす

特性	詳細
Clear	平易な言葉を使用 ( 抽象的な言葉は可能な限り回避 )
Stable	Vison は、一度決めたら変更はあまりしない「プロダクトの先」を見据える方がブレが少なくなる
Broad	プロダクトの可能性を広く捉える
Engaging	Vision を聞いた人がワクワクするユーザが思わず使いたくなる
Short & Sweet	短く簡潔

実例: 楽曲レコメンデーション機能を作る！

悪い例: AI を活用して、他社よりも優れた、楽曲レコメンデーションを提供し、最高の顧客満足度を実現する。

AI は手段でしかない。

他社のキャッチアップに終始しかねない

顧客満足度は、良いプロダクトを作った結果でしかない

実現するとは、作り手視点でしかない

良い例: 思わず聴きたくなる曲が、使う度に現れる。

平易な言葉でブレがない

AI にこだわるのではなく、新技術も見える

「使う度」という言葉に、ユーザのエンゲージメントを深めるための手段に想像力が触発される

ワクワクする

Product Strategy

目的
- プロダクト開発時、何をして何をしないかを決定
- Vision を達成するために、現在クリアすべき仮説は何か
やること
1. 4つの事項を明確化
  - ターゲットユーザーは誰か？
  - ユーザのペインポイントをどう解決するか？
  - どのようなプロダクトで、どこで差別化できるか？
  - ビジネス上、求められるゴールは？
2. 最終的に3つの事項を明確化
  - コスト構造と収益獲得方針
  - 競合を誰とするか？
  - プロダクトの拡散手段

Product Roadmap

目的
- Product Strategy の表現形態
- 基本、ハイレベルな情報に止める
- CxO が投資家にプレゼンする時にしようされる
- プロジェクトがどのように連動しているかと、おおよそのタイムライン
やること
1. Product Strategy から、3つの観点でポテンシャルが存在するテーマを抽出
  - Delight Customer: 顧客を満足させる可能性を持つ機能
  - Margin Enhancement: 利益率の向上
  - Hard to copy by competitor: 競合に対する参入障壁

Product Concept

目的
- Product Concept は、特定の機能またはプロダクト完成時のゴールを表現（文字 or パワポ）
- 開発前、ステークホルダーやプロダクトチームに理解して欲しいことを洗い出し
やること
1. 次の説明ができるようにする。
  - エレベーターピッチ
  - プロダクトデザイン
  - やらないことリスト
  - ステークホルダーを探す
  - 解決案を描く
  - 夜も眠れない問題
  - 期間はどれくらいか
  - 何を諦めるか
  - どれだけ試算が必要か

実例: airbnb の Product Concept

Product Pitch Deck と呼ばれ投資家向け説明だが、記述する類似点が多い

なお、ある程度サービスが走ってる段階の資料であることを留意

airbnb.pdf - Google ドライブ

Product Required Document

参考フォーマット
- Product Hunt - Google ドキュメント
参考URL
- PRD を公開し、議論できるサービス => Product Hunt – The best new products in tech.

問い・背景

ユーザが直面する問題は？

3つのスコープで、緊急性や重要性が高くないと、ユーザに価値が伝わらない
- Pain: 困りごと・不便
- Gain: 利得・利便
- Jobs: 効率・帰結

ビジネス機会・規模は？

フェルミ推定で、概算でターゲットユーザ数を計算
- 市場調査の前に本当にビジネス機会があるかのあたりをつける ( Backward research method )
いずれかのフレームワークでマーケットリサーチ
- PEST
- DEEPLIST
- FiveForth
- SWOT

自社と競合の立ち位置は？

Customer
- 顧客は誰か？（セグメントサイズ、成長率、マーケットシェア）
- 過去から現在までのトレンドは？（上昇、下降、定常）
- ニーズは？（各サグメントが価値を感じていること）
- セグメント毎に好まれる販売チャネルは？
- カスタマー集中度はどのくらい？
Product
- プロダクト名は？
- プロダクトができることは？
- プロダクトの使われ方は？
- コモディティー化しているか？、どこで差別化できるか？
- プロダクトライフサイクルの位置付け（新規参入者？、以前から？）
Company
- 会社の強みは？
- コスト構造は？
- ブランド力は？
- 財務状況
- 組織体制
- 法規制環境
Competition
- マーケット集中度は？（独占・寡占・混沌？、何社競合が存在しシェアは？）
- 競合はどこ？
- 競合は、どのようなプロダクトを出してる？
- 競合は、最近どんな一手を出した？
- 競合がしていて、自社がしてないことは？
- どのような販売チャネル？
- 参入障壁とそのハードルの高さは？

仮説

仮説を立てる

なぜ問題が発生し、どこを解決すると、プロダクトとしてビジネスが成立するか OR ユーザの増加定着しそうか
例: ユーザは X という問題を抱えている。この仮説が正しいと仮定し、Y のプロダクトに対し、Z の機能を盛り込むことで解決する。
仮説が増えると検証が複雑になるため、一つの PRD に一つの仮説を立てる

仮説を研ぎ澄ます

仮説に対し反論し、その反論にサポートできる仮説や事実は存在しないか？
- Step1: 仮説が確かであっても、Y のプロダクトに対し、Z の機能を追加してはいけない！
- Step2: 仮説が不確かであっても、Y のプロダクトに対し、Z の機能を追加してはいけない！
Backward Casting
- 仮説が既に成功していたとしたら、何が成功要因か
Premotem
- 仮説が失敗するとしたら、何が原因になりそうか

仮説を検証する

A/B テスト

機能・プロダクト

What を定義する
- 特性で考える
  - 価値機能群（技術要件、パフォーマンス要件、デザイン要件）
  - ビジネスプロファイル群（ビジネス要件、プロジェクト要件）
- 時間×時間軸で考える
  - Phase1: MVP を目指して、UI/UX に不足あっても、コアとなる価値を提供する
  - Phase2: MVP で対応不可だった事項（ PRD の場合、見通しレベル）
  - Phase3: やろうとした機能を網羅（ PRD の場合、見通しレベル）

ビジネス要件

考慮事項	内容
目的	プロダクト又は機能のゴールは何か
提案の概要	一言で何をするプロダクト又は機能か？どのユーザに対し、どのような利得が生じるか？
対応スコープ	何を作り、何を作らないか？その境界線はどこか？
リスク	施策の遂行にあたり、何がリスクとなるか？そのリスクはどのように再消化できるか？
依存関係	社内・社外で依存関係となる部分はどこか？

プロジェクト要件

考慮事項	内容
スケジュール	PM としてリリースしたいタイミングはいつか？
将来の対応事項	今回の施策はワンショット？、又は継続的に対応する？継続的な場合、どのようになぜ分割する？
テスト計画	プロダクト又は機能の Acceptance Criteria をどこに置くか
人員	プロダクトチームの所属メンバーはどこから調達するか？

技術要件

Input と Output を意識して、ユーザストーリーで考える
- #{ペルソナ定義}のユーザとして、A ということがしたい、その結果 B ということを実現したい。
周辺要件（適宜必要な事項を考慮）
- API を使用するか
- データ信頼性・依存性・一貫性
- ユーザイベントログ
- CRM
- Deeplink
- プライバシー
- セキュリティー
- サポータビリティ（新機能をリリースする場合、運用サポート担当者の観点から使いやすいか）

パフォーマンス要件

タップやクリックに対するレスポンス速度
アクセス集中時、システムクラッシュさせるかデグレを発生させても使用可能にするか

デザイン要件

デザイン部分は、PRD を書く前にデザイナーとエンジニアと調整し、まとめておく
最低でも、ワイヤーフレーム〜LowFidelity 程度のモックを用意
ローカリゼーションの必要性
ユーザインタビューを通して、Usability がある程度クリアできているか
ユーザのモチベーションを捉えているか

何をもって成功とするか

プロダクトの成功を定義
- トップライン KPI がどれだけ動くか
- 顧客の流入する Input がどれだけ増加し、利益に繋がる Output への影響要素を増加させるか