writing-prds

製品要件定義書の作成

明確な課題と境界づけられた解決策を定義し、チームの速度と創造的な成果を最大化します。

Lenny's Podcast と Newsletter の 14 名のゲストと投稿からの知見を活用し、製品要件定義書の作成を支援します。

支援方法

1. 中核となる課題の起草 - 特定の解決策に依存しない、簡潔な課題定義の明確化を支援します。
2. 成功指標の策定 - 将来の機能要望を選別するフィルターとして機能する、具体的で測定可能な成果の定義を支援します。
3. プロジェクト境界の定義 - シェイピングの手法を用いて、曖昧な要望を境界づけられた概念へと絞り込むプロセスを導きます。
4. 明確さのためのレビュー - 既存の草案を簡潔さ、読みやすさ、技術的な理解の観点から監査し、マイクロマネジメントを防ぎます。

中核となる原則

機能的なプロトタイピングのために設計する

Jenny Wen:「かつては 2 年、5 年、いや 10 年先のビジョンを作りに出かけていました。今ではそれが 3 〜 6 か月先のビジョンになり、必ずしも美しい資料を作るのではなく、時に人々を正しい方向へ導くプロトタイプを作るだけになりました。」

AI によって推進されるエンジニアリングの速度についていくには、設計は静的な長期計画よりも、短期的な機能プロトタイピングに焦点を当てるべきです。

プロジェクト境界を早期に形作る

Ryan Singer:「シェイピングセッションで必要なのは、エンジニア、プロダクト、デザインが『理解した』と言えるような何らかの図を導き出すことです。つまり第一に、最初から終わりが見えなければ、何も始めないということです。」

開発を開始する前に、デザインとエンジニアリングを交えた高密度の協働セッションを通じて、境界に対する共通理解を形成します。

課題を中心にドキュメントを構成する

「1 ページ資料と PRD の事例とテンプレート」より:「課題志向: 解決すべき課題を、できればドキュメントの冒頭付近で、力強い数文に凝縮し、すべてのチームメイトの知力を同じ方向に向けます。」

優れた PRD は、明確に定義された課題と具体的な成功指標から始まり、何をするかの前に、なぜそれを行うのかについてチームの認識を揃えます。

簡潔さによって明確さを強制する

「私のお気に入りのプロダクトマネジメントテンプレート」より:「少なくとも最初は、これらを 1 ページに収めることがどれほど価値あるかを思い出させてくれます。」

初期のプロジェクトドキュメントを 1 ページに限定することで、チームは中核となる目標に集中し続け、早期の複雑化を防ぐことができます。

混沌から明確さへ移行するために文書化する

Melanie Perkins:「私たちには混沌から明確さという概念があり、すべてのアイデアは混沌の側から始まり、そして明確さという反対側までずっと進んでいかなければなりません。混沌はアイデアであったり、課題であったり、哲学や信念であったりします。」

抽象的なアイデアを書き留めることは、漠然とした概念を実行可能なプロジェクトへと変えるための、不可欠な第一歩です。

創造的なマイクロマネジメントを避ける

「非常に厄介なプロダクトマネージャーの 5 つの習慣」より:「プロジェクト仕様の重要な詳細を明確にすることと、1 つのボタンについて 3 ページかけて説明することの間には、紙一重の差があります。この厄介な習慣は、プロジェクトの開始時にデザイナーやエンジニアに機能の動作を細かく指示する場合にも、終盤に各機能の仕様を何日もかけて書き出す場合にも当てはまります。」

機能を過剰に指定することは、エンジニアやデザイナーの創造性を抑え込みます。ドキュメントは会話を置き換えるのではなく、会話を促進するものであるべきです。

AI でテクニカルライティングを自動化する

「AI がプロダクトマネジメントに与える影響」より:「欲しいものを人間の言葉で記述し、80% 完成した草案を手に入れ、それを洗練させてから出荷します。これは ChatPRD のようなツールですでに起きています。」

AI ツールを使って技術ドキュメントの大部分を生成することで、プロダクトマネージャーは最終的な洗練と戦略的なニュアンスに集中できます。

テンプレートとフレームワーク

• Lenny's 1-Pager Template（1ページ資料とPRDの例およびテンプレート）- Lennyが新しいプロジェクトを始めるときにいつも使う個人用テンプレート
• 5 Elements of a Great 1-Pager/PRD（1ページ資料とPRDの例およびテンプレート）- 効果的なプロダクト仕様の条件を評価する基準です。PRDの作成とレビューの両方で使われます
• AI Prompt: Write a PRD（プロダクトマネージャーは不公平な役割です。だから不公平に取り組みましょう。）- 音声からテキストへの変換を使い、背景情報を口述してPRDの草案を作成するためのChatGPTプロンプトテンプレート（GPT-4o以降）
• Breadboarding and Fat Marker Sketching（Ryan Singer）- ワイヤーフレームより詳しく、Figmaほど作り込まれていない形でアイデアを明確に伝えるための、セッションの構成に使う2つのコラボレーション手法
• Technical PM Questions for PRDs and Feature Work（より技術に詳しいプロダクトマネージャーになる）- PRDの作成や機能開発に取り組む際に、PMが技術的な知識を示し、コラボレーションを改善するために尋ねるべき質問
• Five Attributes of a Strong Problem Statement（問題解決のための3段階フレームワーク 👌）- 問題の説明が適切に作成されているかを評価する基準です。1ページ資料の「問題」セクションを作成する際に使われます。
• PRD Review Checklist (derived from Lenny's critiques)（1ページ資料とPRDの例およびテンプレート）- Lennyが実例4件を評価した内容に基づくチェックリストです。よくある落とし穴を特定し、確認できます
• Duolingo One-Pager Template（Duolingoのプロダクト開発方法）- 機能アイデアへのフィードバックを得るために、Duolingoが初期段階のプロダクトレビュー用1ページ資料に使うテンプレート

詳細を含む一覧については、references/artifacts.mdを参照してください。

ユーザーを支援する質問

• 「このプロジェクトがユーザーのために解決する、最も重要な問題は何ですか？」
• 「このプロジェクトの成功を判断するために、どの具体的な指標を使いますか？」
• 「このバージョンでは、どの機能やタスクを明確に対象外としますか？」
• 「技術的な制約について、エンジニアリングチームからすでにフィードバックを得ていますか？」
• 「次に進むまで、この問題にどのくらいの時間をかけますか？」
• 「チーム全員が実際に読めるよう、このドキュメントは簡潔ですか？」

指摘すべきよくある間違い

• 「just」という言葉を使う - エンジニアの専門性を軽視し、すぐに修正できるという非現実的な約束で、エンジニアを疲弊させるおそれがあります。
• 早すぎる段階で精度の高いモックを作る - 問題領域や技術的な制約を十分に検討する前に、チームを特定の解決策に固執させます。
• 対象外のことを無視する - 作らないものを明確にしないと、スコープが拡大し、主要な問題への集中が失われます。
• ウォーターフォール型の引き継ぎ - 初期計画からデザイナーやエンジニアを除外すると、非効率が生じ、イノベーションの機会を逃します。

詳細解説

14人のゲストから得た24件すべての知見については、references/guest-insights.mdを参照してください。

関連スキル

• Shipping Velocity
• Ai Assisted Prototyping
• Building With Ai Agents
• Product Tool Stack