プロダクトマネージャーが書いたPRDの通りに機能をつくる？

私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。

😭 PRDの嫌いだったところ

① プロダクトマネージャーの仕事はPRDを書くことです、という誤解
実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私はプロダクトマネージャーの仕事は「何のPRDを書くのか？」を決めることであり、PRDを書く作業はプロダクトチーム全体で実施するものだと思っています。プロダクトマネージャーが書いたPRDの通りにプロダクトチームが動く組織は好みません。

② これ1枚でほんまに全部書くんか？
PRDは「検討すべき項目がすべて検討されているか？」を問うフォーマットとして秀逸です。しかし、例えばPRDに「競合分析」や「市場分析」を記載することもあると思いますが、実際には分析結果は膨大になり1つのドキュメントにこれらすべてを記載することが現実的だとはどうも思えないのです。

😊 好きになれるPRD

1. 最初から全部を書かない

PRDはプロダクトの全体像を捉えるドキュメントなので機能まで落としこまれたものが書かれています。機能の詳細まで全体像が書かれたドキュメントが存在すること自体は素晴らしいと思います。

しかし、最初からその全部を書いて社内承認を取るスタイルは苦手です。PRDを書き始める前にプロダクトのコアになるようなOKRやビジョン、そしてそのPRDをなぜ書くことになったのか、どうしてそのPRDの優先度が高いのかの根拠となるWhyを切り出して、先に議論をする。そして、そのWhyの優先度が高いという合意が取れたあとに、どんな機能でそのWhyに取り組んでいくのかを発想したいのです。

2. どうしてそのWhatを選ぶのか？書いてある

Whyを解決するWhat（機能）は一つではありません。初回利用ユーザーが使い方が分からず困るという課題の解決策は、ヘルプページ作成、チュートリアルの実装、使い方が分からないUIを刷新することなど複数あります。つまり1つのWhyに対して複数のPRD候補が存在します。そして、「どうしてその1つを選んだのか？」をドキュメントには残していきたいです。

🤝 PRDはプロダクトマネージャーが書かない

プロダクトマネージャーがPRDに要求を書いてそれに応じてマーケティング施策を実施するのではなく、全体のマーケティング戦略があった上でそのPRDをどうマーケティングするのかをマーケティング担当者が考えてほしい。

同様に、PRDの要求に応じて画面追加をするのではなく、全体のユーザー体験の設計が事前にあった上で、そのPRDをどう組み込んで実現するのかをUXデザイナーが考えてほしい。

プロダクトマネージャーは、なぜいまそのWhyに取り組むのかを書く。そのWhyを議論して、そのWhyにプロダクトチーム全員で肉付けしていく。Whyから発散した複数あるWhatの中から一番良いものにする。私はそんなプロダクトのつくり方をしていきたいと思っています。（決意表明）

📒 言いたいことをまとめます

・PRDを書く前にWhyを議論する
・そのWhyをいま対応すべきだと決めたあとにプロダクトチームでWhatにとりかかる
・PRD内でのWhy<->Whatと、各領域視点の全体像での整合性の両方を取る
・その結果がPRDとしてまとまってるのはとても素敵👏

いつもどおり、自分の失敗談のbefore/afterでした。フィードバックお待ちしております。