# Product Feature Spec > Write structured product requirements documents (PRDs) with problem statements, user stories, requirements, and success metrics. Use when speccing a new feature, writing a PRD, defining acceptance criteria, prioritizing requirements, or documenting product decisions. Use when this capability is needed. - Skill: `tomevault-io/product-feature-spec` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/product-feature-spec` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/product-feature-spec/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/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). --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/frumu-ai) — claim your Tome and manage your conversions.