product-designer

When to Use

Use this skill when:

Trigger Scenarios:

• •Creating or updating Product Requirements Documents (PRDs)
• •Defining feature scope and boundaries (MVP vs future enhancements)
• •Writing acceptance criteria with Gherkin format (Given/When/Then)
• •Structuring user stories for development teams
• •Planning feature prioritization and roadmaps
• •Documenting success metrics and validation criteria
• •Scoping work for cross-platform implementations

Exclusion Scenarios (DO NOT use):

• •Implementation details (use technical implementation skills)
• •UI/UX visual design specifications (use ui-ux-designer skill)
• •Test planning strategies (use testing-strategy skill)
• •Code architecture decisions (use technical patterns documentation)
• •Backend API specifications (use backend-development skill)

Essential Workflows

Workflow 1: Create a Complete PRD

To create a comprehensive Product Requirements Document:

1. •

   Define the Problem Statement

   • •Describe the user pain point clearly
   • •Quantify the problem (metrics if available)
   • •Explain why this matters now
2. •

   Propose the Solution Overview

   • •High-level description of the proposed solution
   • •Key features and capabilities
   • •Technical approach (brief)
3. •

   Establish Scope Boundaries

   • •List features in MVP (Minimum Viable Product)
   • •List features deferred to v2+ (Out of Scope)
   • •Explicitly state what will NOT be built
4. •

   Define Success Metrics

   • •Quantitative metrics (e.g., "load time <2s", "85% adoption rate")
   • •Qualitative metrics (e.g., "users report smoother workflow")
   • •How metrics will be measured
5. •

   Write Acceptance Criteria

   • •Use Gherkin format: Given [context], When [action], Then [expected result]
   • •Cover happy paths and edge cases
   • •Make criteria testable and unambiguous
6. •

   Document User Stories

   • •Format: "As a [user], I want [goal], so that [benefit]"
   • •Include one story per major feature
   • •Prioritize by user value

Workflow 2: Define MVP vs Future Scope

To separate MVP from future enhancements:

1. •

   Identify Core Value Proposition

   • •What is the ONE thing users need?
   • •What is the minimum viable solution?
   • •What can be simplified or omitted?
2. •

   Apply the "Must Have vs Nice to Have" Framework

   • •Must Have (MVP): Critical path to value, cannot ship without
   • •Should Have (v2): Important but can be added later
   • •Could Have (v3): Desirable but low priority
   • •Won't Have (Out of Scope): Explicitly excluded
3. •

   Create a Feature Prioritization Matrix

   • •Score each feature on: User Value (1-5), Technical Complexity (1-5), Effort (1-5)
   • •Calculate: Priority Score = (User Value × 2) - Technical Complexity - Effort
   • •Sort by Priority Score (highest first)
4. •

   Document Rationale

   • •Explain why each MVP feature was included
   • •Explain why each v2 feature was deferred
   • •Link back to problem statement

Workflow 3: Write Testable Acceptance Criteria

To create clear, testable acceptance criteria:

1. •

   Structure Each Criterion with Gherkin

   • •Given: Precondition/context (e.g., "Given the user is on the home screen")
   • •When: Action taken by user or system (e.g., "When the user taps the search button")
   • •Then: Expected result (e.g., "Then a search bar appears at the top of the screen")
2. •

   Cover Multiple Scenarios

   • •Happy Path: Expected behavior under normal conditions
   • •Error Cases: Network failure, invalid input, timeouts
   • •Edge Cases: Empty states, boundary conditions, concurrent actions
3. •

   Make Criteria Measurable

   • •Avoid ambiguous words like "quickly", "smoothly", "intuitive"
   • •Use specific numbers or thresholds: "loads within 2 seconds", "displays 10 items per page"
   • •Tie to success metrics when possible
4. •

   Organize by Feature or User Story

   • •Group criteria logically (e.g., "Search Feature", "Navigation", "Data Loading")
   • •Number each criterion for easy reference during testing
   • •Reference user stories in cross-refs

Critical Guardrails

Quick Reference

Cross-References

Pro Tips

1. •Start with the Problem, Not the Solution — If you can't articulate the problem clearly, the PRD will be unfocused
2. •Write PRDs for Humans, Not Machines — Use clear, conversational language that developers can understand
3. •Iterate on Acceptance Criteria — Review criteria with engineers and QA before finalizing
4. •Version Your PRDs — Add "Last Updated" dates and track changes for accountability
5. •Link to Implementation Details — Reference technical docs (navigation, conventions) to connect product to code