prd-authoring

What this skill does

--
name: prd-authoring
description: |
Guide for writing clear, persuasive PRDs (Product Requirements Documents). Use when:
(1) Creating new product or feature proposals
(2) Reviewing PRDs for clarity and completeness
(3) Helping others improve their PRD drafts
Triggers: "write PRD", "create PRD", "product proposal", "feature proposal", "PRD feedback"

---

# Authoring Guide for Product Requirements Documents (PRDs)

A guide to writing clear, persuasive PRDs that align stakeholders, communicate user value, and enable implementation. This guide focuses on the craft of writing—how to structure arguments, explain proposals, and communicate product changes effectively.

---

## Philosophy

### PRDs Are Arguments for User Value, Not Technical Specs

A PRD is not a technical specification or design document. It is an argument for why users need this change and why this approach delivers value. Every section builds toward that argument: the problem establishes that user pain is real, the goals show what success looks like, the solution shows your approach addresses the problem, and the metrics prove we can measure impact.

If reviewers finish reading and don't understand why this matters to users or the business, the PRD has failed—regardless of how well-researched the solution is.

**Key principle**: PRDs define the **what** and **why**. Design docs and RFCs define the **how**.

### Write for Multiple Audiences

Your reviewers include product managers, engineers, designers, business stakeholders, and leadership. They skim looking for relevance (Summary), user problems (Motivation), business value (Goals, Metrics), what we're building (Solution, Requirements), and what could go wrong (Risks). Structure your PRD so each audience finds what matters to them quickly. Front-load the important information—don't bury context in paragraph four.

### PRDs Are Living Documents

PRDs used to be lengthy, rigid documents signed off once. Today they are leaner, iterative, and collaborative. Start with a draft to gather feedback early, update as you validate assumptions, and refine as implementation reveals new constraints. Keep it concise: 2-10 pages, clarity over length. When you find yourself answering the same question multiple times in comments, the PRD itself needs clarification.

---

## The Narrative Approach

### Tell a Story, Don't List Facts

The best PRDs read as a coherent narrative, not a collection of disconnected sections. Use the **ABT (And-But-Therefore)** method:

```
"Here's what users can do today..." (AND - Context)
    ↓
"But they face this problem..." (BUT - Problem/Gap)
    ↓
"Therefore, we propose this solution..." (THEREFORE - Resolution)
    ↓
"Here's how we measure success..." (Impact)
```

This narrative structure helps reviewers follow your reasoning and arrive at the same conclusion you did.

### Use Prose, Not Just Bullet Points

Bullet points work for discrete lists of items. They fail at explaining reasoning or building arguments. Compare:

```markdown
❌ Bullet-point thinking:

- Users can't track yield across protocols
- Manual tracking is error-prone
- Need aggregated dashboard
- Build pooling interface

✅ Narrative explanation:

Individual DeFi users currently track their positions across 5-8 different protocols
manually, copying balances into spreadsheets. This manual process leads to errors in
~30% of cases (user research, n=50) and takes 15-20 minutes daily. By providing an
aggregated dashboard that automatically pulls position data from connected wallets, we
reduce tracking time to under 1 minute and eliminate calculation errors entirely.
```

The narrative version explains **why** each piece matters and **how** they connect. Reviewers understand not just what you're proposing, but why it makes sense.

### Front-Load Context

Don't make readers wait for essential context. The first paragraph of each section should orient the reader:

```markdown
❌ Context buried:

The new feature will show APY history over 30 days with sparklines. Users can toggle
between protocols. This solves the comparison problem we identified in Q3 research.

✅ Context first:

Today, users cannot compare yield rates across protocols without manually tracking daily
APYs. User research (Q3 2025, n=120) found that 78% of active DeFi users want historical
APY comparison to inform their decisions. This PRD proposes an APY comparison dashboard
showing 30-day trends across connected protocols.
```

### Information Retention Through Storytelling

Research shows information presented in storytelling format is **20 times more likely to be retained** than facts presented linearly. Structure your PRD to create a clear problem → solution → impact arc, use concrete examples and user scenarios, and show before/after comparisons with specific metrics.

---

## Section-by-Section Guide

### Summary

**Purpose:** Let readers decide in 30 seconds if this PRD is relevant to them.

**Length:** 3-4 sentences maximum. Include the problem (user pain), what we're building (the solution), and what value it delivers. Leave implementation details for the design doc, background context for Motivation, and justifications for later sections.

```markdown
❌ Too long, too detailed:

This PRD proposes building a DeFi pooling aggregator that allows users to deposit funds
into a smart contract which then allocates across multiple yield protocols based on APY
optimization algorithms. Currently, users face high gas fees when interacting with
individual protocols, and they lack the sophistication to optimize yield strategies. Our
solution will reduce gas costs by 60% through batched transactions and increase average
yields by 2-4% through algorithmic optimization.

✅ Concise and clear:

Enable retail DeFi users to access institutional-grade yield strategies through a pooling
protocol that aggregates deposits and socializes gas costs. This reduces individual
transaction costs by 60% while improving average yields by 2-4%, addressing the primary
barrier to DeFi adoption for users with <$10K in capital.
```

### Problem Statement / Motivation

**Purpose:** Convince reviewers the problem is real, painful, and worth solving.

Structure as three movements: **Current State** (what users do today), **User Pain** (what's wrong with it), and **Impact** (why it matters for users and the business). Make the pain concrete with real user data—quantify whenever possible.

```markdown
❌ Vague pain:

DeFi is hard to use and expensive for small users. Many people give up.

✅ Concrete, narrative pain:

Users with less than $10K in capital face a 3-5% annual drag from gas fees alone when
managing DeFi positions across multiple protocols. Our research (Q4 2025, n=150) reveals
a stark pattern: 67% of small holders check rates daily but rebalance less than once a
month because gas costs eat their margins. The average user spends $400-600/year in gas
to manage roughly $5K in capital—making active management economically irrational. As a
result, 43% abandon DeFi entirely within six months, citing "too expensive for small
amounts." This represents a $2.4B addressable market of small holders who want DeFi
yields but are priced out by current economics.
```

Notice how the narrative version chains each fact to the next: the gas drag _causes_ infrequent rebalancing, which _leads to_ irrational economics, which _results in_ abandonment, which _represents_ an untapped market. Each sentence earns the next.

**Full example:**

```markdown
## Problem Statement

### Current State

Individual DeFi users interact directly with lending protocols (Aave, Compound), DEXes
(Uniswap), and yield farms (Curve, Convex) to earn yield on their crypto assets. Each
interaction requires a separate transaction and gas fee.

### User Pain

This direct interaction model creates three compounding problems. First, users pay
$5-50 per transaction depending on congestion, which for those with under $10K in capital
translates to 3-5% annual drag—more tha