Advisor Product Champion

An autonomous agent that guides product management decisions — defining product vision, writing PRDs, prioritizing features with data-driven frameworks, running discovery processes, and aligning stakeholders around product strategy.

When to Use This Agent

Choose Advisor Product Champion when:

• You need to write Product Requirements Documents (PRDs) with clear acceptance criteria
• You want to prioritize a backlog using RICE, ICE, or weighted scoring frameworks
• You need to run product discovery to validate assumptions before building
• Stakeholders need alignment on product vision and roadmap

Consider alternatives when:

• You need market research and competitive intelligence (use a market researcher agent)
• You need project management and sprint planning (use a project manager agent)
• You need UX design and wireframing (use a UX designer)

Quick Start

Copy
# .claude/agents/product-champion.yml
name: advisor-product-champion
description: Guide product management decisions and strategy
agent_prompt: |
  You are a Product Champion. Help product teams:

  1. Define product vision and strategic objectives
  2. Write PRDs with user stories and acceptance criteria
  3. Prioritize features using data-driven frameworks
  4. Run product discovery with hypothesis validation
  5. Create roadmaps aligned with business goals
  6. Facilitate stakeholder alignment and decision-making

  Product principles:
  - Outcome over output (measure impact, not features shipped)
  - Evidence over opinion (validate with data, not HiPPO)
  - Customer problems over solutions (understand the "why")
  - Small bets over big bets (iterate, don't waterfall)

Example invocation:

Copy
claude "Write a PRD for adding a team collaboration feature with real-time commenting and @mentions"

Core Concepts

Product Discovery Framework

Phase	Method	Output
Problem Discovery	User interviews, support tickets, analytics	Problem statements
Solution Discovery	Prototyping, design sprints, concept testing	Solution hypotheses
Validation	A/B tests, fake door tests, Wizard of Oz	Validated/invalidated
Specification	PRD writing, technical design	Build-ready specs

PRD Template

Copy
## Feature: Real-Time Collaboration

### Problem Statement
Teams working on shared documents waste 30 minutes/day resolving
conflicts and communicating changes through separate channels.

### Hypothesis
If we add real-time commenting with @mentions, teams will reduce
context-switching by 40% and resolve questions 3x faster.

### Success Metrics
- Metric 1: Comments per document increases by 50%
- Metric 2: Time to resolve questions decreases from 4hrs to 1hr
- Metric 3: DAU/MAU ratio increases by 10%

### User Stories
US-1: As a team member, I want to leave a comment on a specific
paragraph so that my feedback is contextual and actionable.

US-2: As a reviewer, I want to @mention a colleague so that they
are notified and can respond to my question directly.

### Acceptance Criteria
- Comments appear in real-time for all viewers (< 2s latency)
- @mentions trigger push notification and email
- Comments can be resolved/archived (not deleted)
- Comment history is preserved for audit

### Out of Scope (v1)
- Threaded replies (v2)
- Emoji reactions (v2)
- Comment permissions (v2)

Prioritization Framework (RICE)

Feature                Reach  Impact  Confidence  Effort  RICE Score
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Real-time comments     8000   3       0.8         2       9600
@mentions              8000   2       0.9         1       14400  ← Priority
Comment threads        3000   1       0.7         2       1050
Emoji reactions        5000   0.5     0.6         0.5     3000

Configuration

Option	Type	Default	Description
framework	string	"rice"	Prioritization: rice, ice, weighted, moscow
prdFormat	string	"lean"	PRD format: lean, detailed, one-pager
includeMetrics	boolean	true	Define success metrics for each feature
discoveryMethod	string	"hypothesis"	Discovery: hypothesis, design-sprint, lean
roadmapTimeframe	string	"quarterly"	Roadmap horizon: monthly, quarterly, annual
stakeholderAlignment	boolean	true	Include alignment exercises

Best Practices

1. Define the problem before the solution — Write a clear problem statement with evidence (user quotes, support ticket volume, drop-off data) before describing any feature. If you cannot articulate the problem, you are not ready to build the solution. "Users want collaboration" is not a problem statement. "Teams lose 30 minutes/day to change coordination" is.

2. Set measurable success criteria before building — Define exactly how you will know the feature succeeded. "Increase engagement" is unmeasurable. "Increase DAU/MAU ratio from 35% to 45% within 60 days of launch" is measurable. If you cannot measure it, you cannot learn from it.

3. Use RICE scoring to depoliticize prioritization — When multiple stakeholders push for their favorite features, RICE scoring provides an objective framework. The feature with the highest score wins, regardless of who advocates for it. This reduces decision-making conflict and focuses discussion on the scoring inputs rather than opinions.

4. Scope ruthlessly for v1 — List everything the feature could include, then cut 60% for v1. Ship the minimum feature that validates the hypothesis. If users do not adopt the core feature, the additional features would not have helped. The features you cut become v2 candidates informed by v1 learning.

5. Write acceptance criteria in Given/When/Then format — This format eliminates ambiguity and makes criteria directly testable. "Comments should work" is ambiguous. "Given a user viewing a document, when they click a paragraph and type a comment, then all other viewers see the comment within 2 seconds" is unambiguous and testable.

Common Issues

PRD becomes a 30-page specification nobody reads — Long PRDs signal insufficient problem understanding (compensated with detail) or fear of leaving things out. Keep PRDs to 2-3 pages. Link to separate documents for technical design, research findings, and edge case analysis. The PRD should answer: What problem? Why now? How will we measure success? What is v1 scope?

Feature prioritization changes every week — Stakeholders constantly reprioritize based on the latest customer conversation or competitor move. Set a quarterly prioritization cycle with clear criteria. Between cycles, only P0 issues (customer-impacting bugs, revenue-threatening problems) can change the priority order. This provides stability for engineering to execute.

Product discovery is skipped due to timeline pressure — "We don't have time to validate, just build it." This results in shipping features that nobody uses. Even a 3-day discovery cycle (5 user interviews + a prototype test) catches major assumption errors. Frame discovery as risk reduction: spending 3 days now prevents 3 weeks of building the wrong thing.