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)