Feature Spec / PRD Writer

Write feature specifications and product requirements documents that are clear, complete, and actionable. Turn vague ideas into structured documents with problem statements, goals, non-goals, success metrics, and acceptance criteria.

Workflow

Step 1: Understand the Feature

Gather these inputs from the user:

1. What is the feature? Brief description of what should exist.
2. Why build it? What problem does it solve, or what opportunity does it capture?
3. Who is it for? Specific user segment or persona.
4. What triggered this? Customer request, data insight, strategic bet, competitive pressure.
5. What exists today? Current state, workarounds, or related features.
6. How big is this? Initial sense of scope: small (days), medium (sprint), large (quarter).

If the user has only a vague idea, help them think through these questions rather than asking all at once.

Step 2: Define the Problem

Write a crisp problem statement:

### Problem Statement

**Who**: [Specific user segment]
**What**: [The problem they face]
**When/Where**: [The context in which it occurs]
**Impact**: [Quantified consequence -- time lost, revenue at risk, user drop-off]
**Evidence**: [Data, research, or customer quotes supporting this]

A good problem statement is specific enough that two product managers would agree on whether a proposed solution addresses it.

Step 3: Set Goals and Non-Goals

Goals (what this feature must achieve):

1. [Goal with measurable outcome]
2. [Goal with measurable outcome]
3. [Goal with measurable outcome]

Non-goals (what this feature explicitly will not do):

1. [Non-goal]: [Why it is out of scope]
2. [Non-goal]: [Why it is out of scope]

Non-goals are as important as goals. They prevent scope creep and set expectations with stakeholders.

Step 4: Define Success Metrics

Include:

• Primary metric: The one number that determines if this feature succeeded
• Secondary metrics: Supporting indicators
• Guardrail metrics: Metrics that must not regress (e.g., page load time, error rate)

Step 5: Describe the Solution

### Solution Overview
[2-3 paragraphs describing the proposed solution at a level of detail appropriate for engineering to begin design]

### User Flow
1. [Step 1]: [What the user does and sees]
2. [Step 2]: [What the user does and sees]
3. [Step 3]: [What the user does and sees]

### Key Decisions
| Decision | Options | Recommendation | Rationale |
|----------|---------|---------------|-----------|
| [Decision] | A, B, C | B | [Why] |

### Edge Cases
- [Edge case 1]: [How to handle it]
- [Edge case 2]: [How to handle it]

Step 6: Write Acceptance Criteria

For each user story or major behavior, write acceptance criteria in Given/When/Then format:

### Feature: [Name]

**Story**: As a [user], I want to [action] so that [benefit].

**Acceptance Criteria**:
- Given [precondition], when [action], then [expected result]
- Given [precondition], when [action], then [expected result]
- Given [edge case], when [action], then [expected result]

**Out of scope for this story**:
- [What is not included]

Step 7: Compile the Spec

## Feature Spec: [Feature Name]
Author: [Name] | Date: [Date] | Status: [Draft/Review/Approved]

### 1. Problem Statement
[From Step 2]

### 2. Goals and Non-Goals
[From Step 3]

### 3. Success Metrics
[From Step 4]

### 4. Solution Overview
[From Step 5]

### 5. Detailed Requirements
[User flows, acceptance criteria from Step 6]

### 6. Technical Considerations
- Dependencies: [Systems, APIs, teams]
- Performance: [Latency, throughput requirements]
- Security: [Auth, data handling, compliance]
- Scalability: [Expected load, growth considerations]

### 7. Rollout Plan
- Phase 1: [What ships first, to whom]
- Phase 2: [What comes next]
- Rollback plan: [How to revert if issues arise]

### 8. Open Questions
- [Question 1]: [Owner] | Due: [Date]
- [Question 2]: [Owner] | Due: [Date]

### 9. Appendix
- [Mockups, data analysis, research links]

Examples

Example 1: New Feature

User: "We need to add team permissions to our app." Response: Start with the problem: "Why? What goes wrong without permissions?" Define the user segment (admins, team leads). Scope: what permission levels (view, edit, admin)? What entities get permissions? Write the spec with acceptance criteria for each permission level.

Example 2: Improvement

User: "Our search is slow and users complain." Response: Quantify the problem: current latency, user complaints, drop-off rate. Set a measurable goal (p95 search latency under 500ms). Define the solution approach. Include both functional (relevant results) and non-functional (performance) acceptance criteria.

Example 3: Vague Request

User: "Customers want better reporting." Response: Push back constructively: "Which customers, what reports, what is missing?" Help the user narrow from "better reporting" to a specific, specifiable feature like "scheduled email reports with custom date ranges for admin users."

Best Practices

1. Problem before solution. Spend time validating the problem is real and worth solving before describing the solution. A well-defined problem constrains the solution space.
2. Specific non-goals. Vague specs grow scope. Explicit non-goals like "We will not support custom branding in this phase" prevent scope creep.
3. Measurable success. If you cannot measure whether the feature succeeded, you cannot learn from it. Define metrics before building.
4. Edge cases are requirements. "What happens when the user has no data?" is not a detail; it is a core UX question. Surface edge cases early.
5. Phase the work. Large features should be broken into shippable increments. Each phase should deliver user value, not just technical progress.
6. Living document. The spec evolves during development. Update it when decisions change rather than letting it become stale.
7. Write for the engineer. The spec should be detailed enough that an engineer unfamiliar with the context can build the right thing. Ambiguity in the spec becomes bugs in the product.
8. Include what you do not know. Open questions with owners and due dates prevent blockers from being discovered mid-sprint.