スタートアップのための製品要求仕様書(MRD & PRD)の書き方

プロダクトマネジメントの名著 Inspired: 顧客の心を捉える製品の創り方[1] によれば、プロダクトマネージャの役割は2つある。

  1. 製品の市場性を評価すること
  2. 開発すべき製品の定義

このふたつをまとめると、プロダクトマネージャの目的は「 市場性の高い製品(≒売れる製品)を定義すること」ということになる。

前半の市場性評価は、市場要求仕様書(MRD, Market Requirements Document)というドキュメントにまとめられ、MRDは主にソリューションではなく課題にフォーカスしたものだ。製品がどんな問題を解決するか(バリュープロポジションはなにか)、誰のためにこの問題を解決するか、その市場が大きいかといったことを書く。

後半の開発すべき製品の定義に関しては、製品要求仕様書(PRD, Product Requirements Document)がその役割を担う。PRDはMRDで明らかになった課題に対してのソリューションを形作るもので、製品の特徴や機能について書かれている。

基本的にはMRDとPRDは分けて書かれることが望ましい。それは、課題とソリューションを切り離して考えることに意味があるからだ。通常、起業や新しいプロダクトのアイディアを思いつくときは、斬新なソリューションが先に思いついて、その後に課題を後付するようなことになることが多い。しかし、実際はその課題に対するソリューションは他にも無数に存在しているのだ。その可能性をすべて考慮せずに出た最初のアイディアが最も優れているとは普通は言い難い。

ただし、その点にさえ注意すれば、いちいち大掛かりな市場調査などをやっていられないスタートアップにとってはMRDはコンパクトにまとめ、PRDに内包してしまったほうが効率は良い。そこで、本記事ではscoutyでも製品リニューアルの際に使われたMRD内包版PRD(以降PRDと呼ぶ)の書き方およびフォーマットを公開しようと思う。

なお、「スタートアップのための」とタイトルにあるが、もちろん今回扱うPRDはスタートアップ以外でも利用することはできる。

なぜPRDが必要か

私は、PRDが必要な理由もこれと同じだと考える。一般に、製品の方向性が決まっていない状態であるほど巻き戻しコストの低い表現方法を使わないといけない。プロトタイプとはいえ、製品が複雑だと作るのはそれなりに大変だ。大きな方向性が定まる前には探索範囲を増やして、いろいろな可能性を顧客と模索すべきだ。「うちはもう製品の方向性がだいたい決まっているからPRDは書いていない」という会社もあるだろうが、その場合、その方向性が正しいことはすでに検証済みだろうか?検証するとしたら、プロトタイプでやるよりは文書ベースでやる方が効率的だろう。もちろん、顧客は製品が目に見える形になってはじめてイメージがつくものなので、プロトタイプでの検証はそれでも必要だろう。

また、ソリューションの検証はできても、課題の検証はプロトタイプだけだとやりにくい。製品を作ったあとに、「解決しようとしていた課題が、プロダクトマネージャー本人には重要だと感じられていたが、顧客にとっては実際はそこまで重要じゃなかった」といったことが発覚するとたちまち無意味になる。市場の中で重要な課題をつかむためにも、PRD(特にMRDの部分の要素)を作って顧客にヒアリングしていかなければならない。

特にスタートアップでは、CEOかCTOが深夜のノリで書いたコードがそのまま製品版になることが多く、まともな市場調査ができているようなところは多くは無いだろう。そういう組織こそ、きちんとPRDを書いて検証することで、半年後に「売れなくなってきたが、大してエンジニアもいないのでピボットもできないまま資金ショートする」といった悲惨な事態を避けることができる。

PRDのフォーマット

1. 製品がどんな問題を解決するか

2. 誰のために問題を解決するか

3. プロダクト要件

また、私はこの項目にはビジネス上の要件を書くことをオススメする。たとえば、「カスタマーサポートがなくても運用が可能であるためスケーラビリティが高い」「採用ニーズがなくなってからもツールとして機能し、継続率が高い」など。こういったものからソリューションの形が見えてくる。

4. エレベーターピッチ(プロダクト概要)

<解決したい課題> したい
<ターゲットユーザー> 向けの
◯◯というプロダクトは、<プロダクトのカテゴリ> です。
これは、<アピールポイント> することができ、
<従来の方法> とは違って、<差別化要因となる決定的な特徴> が備わっています。

という形にまとめる。

5. プロダクトの機能および特長

6. 想定する運用方法

7. 想定する料金

PRDを検証する

スタートアップの製品が失敗する理由として、

  • 解決しようとしていた課題が深刻ではなかった。課題を持っているユーザーがごく一部だった。
  • 課題は存在していたが、自社のソリューションがそれを解決できなかった。
  • 顧客の課題を解決する製品仕様はできたが、それを開発できなかった。
  • 製品は顧客の課題を解決するが、プロダクトマーケティングに失敗した。(価格が不適当、認知が取れなかった 等)

といったものが挙げられるが、特に多いであろう1つ目と2つ目の要因による失敗の可能性は、このPRDの段階で最小化することができる。これをプロダクトマーケットフィットの前段階として、プロブレムソリューションフィット(Problem Solution Fit)と呼ばれることがある。顧客へのヒアリングによってPRDを更新していき、大きな変更が見られなくなった時点でプロトタイピングに入れば、大きなミスはなくなるだろう。

1つ目と2つ目に責任を持っているのはプロダクトマネージャー(ちなみに3つ目はプロダクトオーナー、4つ目はプロダクトマーケティングマネージャーの責任)なので、あなたがプロダクトマネージャーであれば、面倒臭がらずにPRDを書くことをオススメする。

参考文献

[2] How to write a good PRD, Marty Cagan, Silicon Valley Product Group, 2005

[3] How to Write Painless Product Requirements Document, Jerry Cao

[4] The Agile Inception Deck, The Agile Warrior, Jonathan Rasmusson
https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

CEO & Product Manager at LAPRAS Inc. / MSc in Artificial Intelligence at University of Edinburgh / Alumni of KUIS(Kyoto University Information Science)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store