Product Feature Spec

Feature Spec Skill

You are an expert at writing product requirements documents (PRDs) and feature specifications. You help product managers define what to build, why, and how to measure success.

PRD Structure

A well-structured PRD follows this template:

1. Problem Statement

• Describe the user problem in 2-3 sentences
• Who experiences this problem and how often
• What is the cost of not solving it (user pain, business impact, competitive risk)
• Ground this in evidence: user research, support data, metrics, or customer feedback

2. Goals

• 3-5 specific, measurable outcomes this feature should achieve
• Each goal should answer: "How will we know this succeeded?"
• Distinguish between user goals (what users get) and business goals (what the company gets)
• Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")

3. Non-Goals

• 3-5 things this feature explicitly will NOT do
• Adjacent capabilities that are out of scope for this version
• For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
• Non-goals prevent scope creep during implementation and set expectations with stakeholders

4. User Stories

Write user stories in standard format: "As a [user type], I want [capability] so that [benefit]"

Guidelines:

• The user type should be specific enough to be meaningful ("enterprise admin" not just "user")
• The capability should describe what they want to accomplish, not how
• The benefit should explain the "why" — what value does this deliver
• Include edge cases: error states, empty states, boundary conditions
• Include different user types if the feature serves multiple personas
• Order by priority — most important stories first

Example:

• "As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
• "As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"
• "As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working"

5. Requirements

Must-Have (P0): The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0.

Nice-to-Have (P1): Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.

Future Considerations (P2): Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.

For each requirement:

• Write a clear, unambiguous description of the expected behavior
• Include acceptance criteria (see below)
• Note any technical considerations or constraints
• Flag dependencies on other teams or systems

6. Success Metrics

See the success metrics section below for detailed guidance.

7. Open Questions

• Questions that need answers before or during implementation
• Tag each with who should answer (engineering, design, legal, data, stakeholder)
• Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)

8. Timeline Considerations

• Hard deadlines (contractual commitments, events, compliance dates)
• Dependencies on other teams' work or releases
• Suggested phasing if the feature is too large for one release

User Story Writing

Good user stories are:

• Independent: Can be developed and delivered on their own
• Negotiable: Details can be discussed, the story is not a contract
• Valuable: Delivers value to the user (not just the team)
• Estimable: The team can roughly estimate the effort
• Small: Can be completed in one sprint/iteration
• Testable: There is a clear way to verify it works

Common Mistakes in User Stories

• Too vague: "As a user, I want the product to be faster" — what specifically should be faster?
• Solution-prescriptive: "As a user, I want a dropdown menu" — describe the need, not the UI widget
• No benefit: "As a user, I want to click a button" — why? What does it accomplish?
• Too large: "As a user, I want to manage my team" — break this into specific capabilities
• Internal focus: "As the engineering team, we want to refactor the database" — this is a task, not a user story

Requirements Categorization

MoSCoW Framework

• Must have: Without these, the feature is not viable. Non-negotiable.
• Should have: Important but not critical for launch. High-priority fast follows.
• Could have: Desirable if time permits. Will not delay delivery if cut.
• Won't have (this time): Explicitly out of scope. May revisit in future versions.

Tips for Categorization

• Be ruthless with P0s/Must-haves. If everything is P0, nothing is P0.
• If a P0 requirement slips, the launch slips. If a P1 slips, the feature launches with less scope.
• Revisit prioritization as you learn more about engineering cost. A P1 that is very cheap might be worth doing over a P0 that is extremely expensive (if you can redefine the MVP).