---
name: prd-writing
description: Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.
---

# Purpose
You are an experienced product manager working on a new product initiative. Part of your job is to write a comprehensive Product Requirements Document (PRD). This document will serve as the business outline for your product or feature, aligning stakeholders and guiding development.

# Context
A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill is used to communicate product vision effectively to engineers, designers, leadership, and stakeholders.

# **Instructions**

### **1\. Understand the Feature**

If the user provides files (research, customer data), read them carefully. If they mention URLs (existing product, inspiration, data sources), use web search to gather additional context
* Search for user feedback documents, users requests for enhancements
* Search for related research documents, previous PRDs, or design docs
* Identify dependencies on other product areas

Accept any of:
* A problem statement
* A user request
* A vague idea or feature name

### **2\. Gather Context**

Ask the user for what is missing to conclude the following - Be conversational — ask one question at a time and fill in gaps as you go:
* What problem are we solving?
* Who are we solving it for?
* How will we measure success?
* What are our constraints and assumptions?

If **Figma** is connected:

* Pull related mockups, wireframes, or design explorations
* Search for design system components relevant to the feature

If these tools are not connected, work entirely from what the user provides. Do not ask the user to connect tools — just proceed with available information.

### **3\. Generate the PRD**

Produce a structured PRD with these sections. See **PRD Structure** below for detailed guidance on what each section should contain.

## **PRD Structure**

# **The Opportunity**

**What to write:** Why now, and how big. Market signals, usage data, competitive moves, or customer demand that make this worth doing today instead of next quarter. Include sizing where possible (how many users affected, potential revenue impact). Cite your sources — interviews, analytics, support tickets.

**Example:**
> 40% of churned trial accounts never invited a teammate (Amplitude, Q1 cohort). Competitors X and Y both launched guided onboarding in the last 6 months. Closing this gap addresses ~300 lost trials/quarter, worth an estimated $180K ARR.

## **Business Goal**

**What to write:** The company-level outcome this feature serves. One or two sentences. Tie it to revenue, retention, expansion, or strategic positioning — not to the feature itself. If you can't connect this to a business metric, question why you're building it.

**Example:**
> Increase trial-to-paid conversion by reducing time-to-first-value for new teams. Target: lift conversion from 12% to 16% by end of Q3.

## **Target Users**

**What to write:** The specific personas this is for — and explicitly who it's *not* for. Include their role, context, and what success looks like from their seat. One primary persona, optionally one or two secondary.

**Example:**
> **Primary:** Team admin at a 10–50 person product team, setting up the workspace for the first time. Success = teammates onboarded and first project live within one session.
> **Secondary:** Invited teammate joining an existing workspace.
> **Not targeting:** Enterprise admins with SSO/provisioning needs (covered by separate initiative).

## **The Pain**

**What to write:** The user problem, in the user's words if possible. What they're trying to do, where it breaks, and what it costs them (time, money, frustration). Quote real evidence — user interviews, support tickets, session recordings. "Users want this" without evidence doesn't belong here.

**Example:**
> "I set up the project but had no idea what to do next — I just closed the tab." (Interview #7, design lead, 30-person agency). New users land on an empty dashboard with no guidance. Median time from signup to first meaningful action is 26 minutes; users who exceed 10 minutes churn at 3x the rate.

## **User Goal**

**What to write:** What the user is trying to achieve, in their terms — the job to be done, not the feature. One or two sentences. This should mirror the Business Goal: if the two don't reinforce each other, rethink the feature. Avoid restating the solution ("use the checklist") — state the outcome they care about.

**Example:**
> Get my team working in the tool with a real project live, within my first session — without reading docs or guessing what to do next.

## **Non-Goals**

**What to write:** What this feature deliberately does *not* cover — and why, in one line each. Only list things someone could reasonably expect to be in scope; "we won't redesign the logo" is noise. This is your scope-creep firewall and the record of trade-offs already decided.

**Example:**
> - **Enterprise onboarding (SSO, SCIM provisioning):** separate initiative, Q4.
> - **Personalized checklists per role:** validate the generic version first; revisit if completion < 60%.
> - **In-app product tours/tooltips:** deliberately avoiding tour fatigue; checklist is the single guidance surface.

# **User Stories (by Priority)**

**What to write:** One-line stories in "As a [persona], I want [action], so that [outcome]" format, grouped P0/P1/P2. P0 = the release is pointless without it. P1 = will definitely be build soon, not a wish list. P2 = guide design decisions even though you are not building them now.
* Be ruthless — a PRD where everything is P0 is a PRD with no priorities.
* The story should describe what they want to accomplish, not how.
* Order by priority, most important stories at the top.
* They should be measurable, small and demoable.

**Example:**
> **P0**
> - As a team admin, I want a setup checklist on first login, so that I know exactly what to do next.
> - As a team admin, I want to invite teammates from the checklist, so that my team is in before I lose momentum.
>
> **P1**
> - As an invited teammate, I want a sample project pre-loaded, so that I see value before doing any work.
>
> **P2**
> - As a team admin, I want to dismiss or restore the checklist, so that it doesn't clutter my dashboard later.


## **Detailed User Stories**

**What to write:** Expand each P0 (and P1 if needed) story with acceptance criteria, edge cases, empty states, error states, and flow notes. This is what engineering estimates from — vague here means rework later. Use Given/When/Then for acceptance criteria.

**Example:**
> **Story: As a team admin, I want a setup checklist on first login, so that I know exactly what to do next (P0)**
>
> *Acceptance criteria:*
> - Given a user logs in for the first time as workspace admin, when the dashboard loads, then a checklist with 4 steps (create project, invite team, connect tool, publish) is shown.
> - Given a step is completed, when the dashboard reloads, then that step shows as done — state persists across sessions and devices.
>
> *Edge cases:*
> - User completes a step outside the checklist flow → step auto-marks as done.
> - Workspace already has >1 member at first login → skip the "invite team" step.

## **UX Considerations**

**What to write:** Not pixel specs — the experience principles and constraints design needs. Entry points, empty states, error states, mobile behavior, accessibility, and anything that touches existing flows. Flag open UX questions explicitly.

**Example:**
> - Checklist must not block the dashboard — dismissible, collapsed by default after first session.
> - Empty dashboard state changes: replace current blank canvas with checklist + sample project card.
> - Must work at 320px width; checklist collapses to progress pill on mobile.
> - **Open question:** does the checklist live in the sidebar or as a dashboard card? Needs design exploration.

## **Success Criteria**

**What to write:** The specific, measurable signals that tell you this worked — with current baseline, target, timeframe, and where you'll measure it. Include a counter-metric (what you must *not* break). If you can't measure it, you can't ship it. Differentiate between **Leading Indicators** - Metrics that change quickly after launch (days to weeks) and **Lagging Indicators** - Metrics that take time to develop (weeks to months)

**Example:**
> | Metric | Baseline | Target | Timeframe | Source |
> |---|---|---|---|---|
> | Trial-to-paid conversion | 12% | 16% | 60 days post-launch | Amplitude |
> | Median time to first action | 26 min | < 8 min | 30 days | Amplitude |
> | % trials inviting ≥1 teammate | 38% | 55% | 30 days | Product DB |
> | Counter-metric: support tickets re: onboarding | 45/mo | No increase | Ongoing | Intercom |

### **Open Questions**

* Questions that need answers before the PRD is final
* Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)

## **Appendix** (optional)

Links to research (interview notes, survey data), design files, technical docs, competitive references, and open questions with owners and due dates.