Product Requirements Svpg

---
name: product-requirements-svpg
description: "Guides product requirements definition using SVPG principles. Use when defining product requirements, transforming feature requests into problems, or assessing product opportunities. Focuses on problem-first thinking, four-risks assessment, and separating problems from solutions."
---

# Product Requirements (SVPG Framework)

## Purpose
This skill applies Silicon Valley Product Group (SVPG) principles—particularly Marty Cagan's frameworks—to guide product requirements definition. It helps product managers, product leaders, and teams move from solution-centric feature requests to problem-first thinking, ensuring rigorous discovery and outcome-focused work.

## Core SVPG Principles (Adapted for Agentic Era)

### Empowered Teams Over Feature Teams
- **Feature teams**: Given features to build; minimal discovery needed
- **Empowered teams**: Given problems to solve; discovery identifies valuable solutions
- This skill assumes you're working toward empowered team practices
- **With AI agents**: Teams can explore more opportunities and validate ideas faster

### Outcomes Over Output
- Features are output; business results and customer value are outcomes
- Requirements should focus on problems to solve, not features to ship
- Discovery work validates what creates value before building
- **With AI agents**: Fast prototyping doesn't justify building more—still focus on valuable outcomes

### Four Big Risks
Every product effort faces four risks that must be assessed:
1. **Value risk**: Will customers buy/use this?
2. **Viability risk**: Does this work for our business?
3. **Usability risk**: Can users figure out how to use it?
4. **Feasibility risk**: Can we build it with time/technology/skills available?
   - **Now split into**: Prototype feasibility (usually LOW with agents) vs Production feasibility (still varies)

Product managers own value and viability risks explicitly.

### Discovery Before Delivery (Accelerated by Agents)
- Rapid prototyping and testing protect revenue and brand
- **Agent advantage**: Functional prototypes in days enable faster customer validation
- Multiple solution approaches beat single-solution anchoring
- **Agent advantage**: 10x cheaper to prototype alternatives—explore 3-4 options
- Qualitative learning (customer conversations) complements quantitative data
- Instrument everything for continuous insight
- **Timeline shift**: Discovery cycles compress from weeks to days

## How This Skill Works

### Interview-First Approach (One Question at a Time)

**CRITICAL**: This skill uses a conversational, iterative approach. Ask ONE question at a time, wait for the answer, then ask the next question based on what you learn. Do NOT dump a long list of questions on the user.

When you request help defining requirements, this skill will:

1. **Understand your context** through targeted questions (asked sequentially):
   - What problem are you trying to solve?
   - Who experiences this problem?
   - What outcome are you seeking?
   - What constraints exist?
   - What discovery has been done?

2. **Challenge solution-centric framing** (one probe at a time):
   - If you present features, we'll explore the underlying problem
   - If you have single solutions, we'll generate alternatives
   - If risks are unassessed, we'll evaluate all four

3. **Guide collaborative exploration** (iteratively):
   - Build problem statements together through dialogue
   - Assess risks systematically, one at a time
   - Separate problems from potential solutions
   - Suggest discovery activities based on answers

4. **Deliver structured outputs** (only after gathering sufficient context):
   - Problem statement (clear, measurable, customer-focused)
   - Four-risks assessment
   - Requirements document (problems and solutions clearly separated)

### Interview Style
- Start with the most important question first
- Listen to the answer and adapt your next question accordingly
- Build understanding incrementally
- Don't overwhelm with a questionnaire
- Have a conversation, not an interrogation

## When to Use This Skill

**Activate this skill when:**
- Defining new product requirements or opportunities
- Someone presents a feature request to evaluate
- Building a PRD or product brief
- Challenged to justify why you're building something
- Transforming stakeholder requests into product work
- Starting product discovery for a new initiative

**Don't use this skill for:**
- Pure technical implementation details (after requirements are clear)
- Design execution (UI/UX specifics)
- Project management and delivery tracking
- General product strategy (use broader product strategy skills)

## Workflow Overview

```
1. Initial Context Gathering
   ↓
2. Problem Exploration (transform features → problems)
   ↓
3. Discovery Assessment (what do we know/not know?)
   ↓
4. Four-Risks Evaluation
   ↓
5. Generate Structured Outputs:
   - Problem Statement
   - Risks Assessment
   - Requirements Document
```

## Red Flags This Skill Helps Avoid

Based on SVPG's "More PM Problem Areas" and related articles:

- **Single-solution anchoring**: Fixating on one feature idea without exploring alternatives
- **Playing defense**: Risk aversion and fear-based decision-making vs proactive innovation
- **Confusing optimization with discovery**: A/B testing tweaks vs creating new value
- **Neglecting qualitative learning**: Over-reliance on data without customer conversations
- **Narrow risk assessment**: Focusing only on usability/feasibility, ignoring value/viability
- **Product management theater**: Administrative coordination instead of strategic problem-solving

## Key Resources

This skill includes reference materials in subdirectories:

### Frameworks
- `frameworks/four-risks.md` - Detailed guidance on assessing each risk type (updated for prototype vs production feasibility)
- `frameworks/discovery-techniques.md` - SVPG-aligned discovery approaches
- `frameworks/agent-accelerated-discovery.md` - **NEW**: How AI agents change discovery timelines and economics

### Templates
- `templates/problem-statement.md` - Structure and examples for problem statements
- `templates/opportunity-assessment.md` - Format for evaluating opportunities (updated with agent-accelerated timelines)
- `templates/requirements-document.md` - Separating problems from solutions

### Reference
- `reference/feature-to-problem.md` - Examples of transforming feature requests
- `reference/good-vs-bad-requirements.md` - Quality criteria and red flags

## Output Standards

### Problem Statements
- Focus on customer/business problems, not solutions
- Measurable and specific
- Explain why this problem matters (impact)
- Avoid jumping to "how" before clarifying "what" and "why"

### Four-Risks Assessments
- All four risks addressed explicitly
- Evidence cited for each assessment (data, customer feedback, prototypes)
- Honest evaluation of what's unknown
- Recommendations for de-risking activities

### Requirements Documents
Clear separation:
- **Problem Space**: What problem exists, who has it, why it matters
- **Solution Space**: Potential approaches, with pros/cons and open questions
- **Discovery Plan**: What needs to be learned before committing to build

## Remember

As Marty Cagan emphasizes:
- "Feature teams deliver output, but product teams deliver outcomes"
- "Good teams draw inspiration from objectives, customer observation, data, and technology"
- "The product manager's job is to ensure what gets built is both valuable and viable"

This skill helps you work like an empowered product team, not a feature factory.

**In the agentic era**: AI coding agents amplify empowered teams by making discovery faster and cheaper. But the fundamentals remain:
- **Discovery validates value first** (agents make building faster, not validation)
- **Outcomes still matter most** (speed doesn't justify building the wrong things)
- **Human judgment is irreplaceable** (agents augment the product trio, don't replace it)
- **Customer learning remains essential** (prototype quickly, test with customers constantly)