prd-writing

エビデンスを最優先し、簡潔でざっと読みやすいPRDを作成しましょう。PRDは思考のためのツールです。1200語を超える場合、著者は十分に考え抜けていません。簡潔な仕様書は読まれやすく、遵守されやすく、予定どおりにリリースされやすくなります。

構成

以下の構成に従ってください。任意と記載されていないセクションはすべて必須です。

1. 課題

顧客のエビデンスから始めます。発言、データ、サポートチケット、観察された行動などです。エビデンスがない場合は、そのことを明記してください。これは意見に基づくPRDであり、注記する必要があります。

例：

「インタビューした顧客5人のうち3人が、チーム招待の段階でオンボーディングを中断しています。タブを閉じるまでの平均時間は47秒です。」

NG：「ユーザーはオンボーディングがわかりにくいと感じています。」

2. 目標

成果を測定可能な形で示し、アウトプットではなく成果を記載します。各目標には数値を含めます。

• 「オンボーディングの離脱率を60％から30％未満に下げる」
• NG：「オンボーディング体験を改善する」

3. 対象ユーザー

具体的に誰にメリットがあるのかを示します。対象は絞り込みます。「最初のPM採用前にPM業務を担うシリーズAスタートアップの創業者」とし、「プロダクトマネージャー」とはしません。

4. 要件

明確な定義とともにP0／P1／P2を使います。

• P0 — これがなければリリースしません。これがないと機能が壊れているか、役に立ちません。
• P1 — なくてもリリースできますが、大幅に機能が損なわれます。可能であれば同じサイクルで対応します。
• P2 — あれば望ましい項目です。早期の追加対応候補です。

各要件は1文で記載します。説明に段落が必要な場合は大きすぎるため、分割してください。

5. 成功指標

必ず数値を使います。「W週間以内にXをYからZに減らす」のように記載します。

指標の不正な操作を防ぐため、各指標には必ずカウンター指標を組み合わせます。

• 指標：「アクティベーション率を70％に引き上げる」
• カウンター指標：「30日後の継続率を45％未満に下げない」

6. 対象外

意図的に構築しないものと、その理由を記載します。このセクションはスコープの拡大を防ぎ、境界について検討したことを示します。

7. 未解決の質問（任意）

意見を求める必要がある未解決の決定事項を記載します。各質問には、誰がいつまでに回答すべきかを明記します。

ガイドライン

• 重要：最大800〜1200語です。PRDが長すぎる場合、検討が完了していません。
• 解決策から始めてはいけません。エビデンスに基づく課題から始めます。
• 実装の詳細（アーキテクチャ、API、データベーススキーマ）は含めてはいけません。それらは仕様書の内容であり、PRDの内容ではありません。
• 必ず「対象外」を含めます。境界がないPRDはスコープの拡大を招きます。
• 要件は必ず顧客のエビデンスに結び付けます。エビデンスがなければ意見です。
• 曖昧な指標（「パフォーマンスを改善する」「体験を向上させる」「エンゲージメントを高める」）は使ってはいけません。数値を示すか、記載しないでください。
• P0要件は3〜5件にします。P0が5件を超える場合、優先順位を付けられていません。

例：良い例と悪い例

悪いP0要件：

「システムは、複数のプロバイダーやエッジケースに対応し、セキュアでユーザーフレンドリーな認証を処理する必要があります。」

良いP0要件：

「P0：ユーザーはメールアドレスとパスワードで登録・ログインできます。Google OAuthはP1です。」

1文で、スコープが明確です。優先順位を付けることで、決定を促します。

---

Linearの「網羅的なドキュメントより短い仕様書」という理念に基づいています。スキルはproductskillsから。