Skill: ivangdavila/product-owner (version 1.0.1)

--- name: Product Owner slug: product-owner version: 1.0.1 changelog: Improved setup flow with natural conversation guidelines homepage: https://clawic.com/skills/product-owner description: Manage backlogs, write user stories, define acceptance criteria, and maximize product value. metadata: {"clawdbot":{"emoji":"📋","requires":{"bins":[]},"os":["linux","darwin","win32"]}} --- ## Setup On first use, read `setup.md` for onboarding guidelines. ## When to Use User needs backlog management, user story writing, sprint prioritization, or stakeholder alignment. Agent handles Scrum artifacts, acceptance criteria, value maximization, and delivery coordination. ## Architecture Memory lives in `~/product-owner/`. See `memory-template.md` for structure. ``` ~/product-owner/ ├── memory.md # Product context, stakeholders, priorities ├── backlog/ # Per-product backlogs │ └── {product}.md # Stories, priorities, acceptance criteria └── sprints/ # Sprint history and retrospectives ``` ## Quick Reference | Topic | File | |-------|------| | Setup process | `setup.md` | | Memory template | `memory-template.md` | | Story patterns | `stories.md` | | Prioritization | `prioritization.md` | ## Core Rules ### 1. Value Over Features - Every story must connect to business value - Ask "what outcome does this enable?" before writing - Prioritize by value/effort ratio, not stakeholder volume ### 2. INVEST in Stories User stories must be: | Criterion | Question | |-----------|----------| | Independent | Can be delivered alone? | | Negotiable | Details can evolve? | | Valuable | Delivers user/business value? | | Estimable | Team can estimate effort? | | Small | Fits in one sprint? | | Testable | Clear pass/fail criteria? | ### 3. Acceptance Criteria Format Write criteria as Given/When/Then: ``` Given [context] When [action] Then [expected outcome] ``` Multiple criteria per story. Each must be independently verifiable. ### 4. Backlog Grooming Cadence - Top 20% of backlog: fully refined, ready for sprint - Next 30%: roughly estimated, needs refinement - Bottom 50%: parking lot, review quarterly ### 5. Stakeholder Management - One voice to development team - Translate stakeholder requests into stories - Say no to scope creep, offer alternatives - Document decisions and rationale in memory ### 6. Sprint Boundaries - Committed scope is sacred - New requests go to backlog, not current sprint - Only PO can adjust sprint scope (with team agreement) ### 7. Definition of Done Maintain explicit DoD. Every story must meet DoD before acceptance. Update DoD when team matures. ## Common Traps - Writing solutions instead of problems in stories - Accepting vague requirements without clarification - Overloading sprints with "just one more thing" - Prioritizing by who shouts loudest - Skipping acceptance criteria because "it's obvious" - Treating estimates as commitments ## Prioritization Frameworks | Framework | Best For | |-----------|----------| | WSJF (Weighted Shortest Job First) | SAFe environments, cost of delay matters | | MoSCoW | Quick categorization, stakeholder alignment | | RICE | Data-driven teams, scoring objectivity | | Kano Model | Feature differentiation, user delight | | Value/Effort Matrix | Simple visualization, quick decisions | See `prioritization.md` for detailed guidance. ## Story Templates ### Standard User Story ``` As a [user type] I want [capability] So that [benefit] Acceptance Criteria: - Given... When... Then... - Given... When... Then... ``` ### Technical Story ``` As a [team role] I need [technical capability] So that [technical benefit enabling user value] ``` ### Bug Fix ``` Current: [what happens] Expected: [what should happen] Impact: [users affected, severity] ``` ## Metrics to Track | Metric | Why | |--------|-----| | Velocity | Predictability | | Cycle Time | Flow efficiency | | Escaped Defects | Quality | | Sprint Goal Achievement | Commitment reliability | | Stakeholder Satisfaction | Value delivery | ## Related Skills Install with `clawhub install <slug>` if user confirms: - `product-manager` — Product strategy and roadmap - `cpo` — Chief Product Officer leadership - `delegate` — Task delegation patterns - `business` — Business strategy fundamentals ## Feedback - If useful: `clawhub star product-owner` - Stay updated: `clawhub sync`

path: memory-template.md
content: # Memory Template — Product Owner

Create `~/product-owner/memory.md` with this structure:

```markdown
# Product Owner Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending

## Product Context
<!-- Product name, description, target users -->
<!-- Business model, key metrics -->

## Team Context
<!-- Sprint length, velocity, Definition of Done -->
<!-- Team size, roles -->

## Stakeholders
<!-- Key stakeholders and their priorities -->
<!-- Decision-making dynamics -->

## Standing Priorities
<!-- Long-term goals, constraints -->
<!-- Things that always matter -->

## Notes
<!-- Observations, patterns, things to remember -->

---
*Updated: YYYY-MM-DD*
```

## Backlog File Template

Create `~/product-owner/backlog/{product}.md`:

```markdown
# {Product} Backlog

## Ready for Sprint
<!-- Fully refined, acceptance criteria complete -->

### [STORY-001] Story Title
**As a** [user type]
**I want** [capability]
**So that** [benefit]

**Acceptance Criteria:**
- Given [context], when [action], then [outcome]
- Given [context], when [action], then [outcome]

**Estimate:** [points or size]
**Priority:** [1-5 or MoSCoW]

---

## Needs Refinement
<!-- Stories that need more detail -->

## Parking Lot
<!-- Future ideas, not yet prioritized -->

---
*Last groomed: YYYY-MM-DD*
```

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Learning product context | Gather info opportunistically |
| `complete` | Full context captured | Work normally |
| `paused` | User said "not now" | Don't ask, work with what you have |
| `never_ask` | User said stop | Never ask for more context |

## Key Principles

- **No config keys visible** — use natural language
- **Learn from behavior** — don't interrogate for context
- **Most products stay `ongoing`** — always learning, that's fine
- Update `last` on each use


path: prioritization.md
content: # Prioritization Frameworks — Product Owner

## Value/Effort Matrix

Simplest approach. Plot stories on 2x2:

```
        High Value
             │
    Quick    │    Big Bets
    Wins     │    (plan carefully)
             │
─────────────┼─────────────
             │
    Fill     │    Money Pit
    Ins      │    (avoid)
             │
        Low Value
    Low Effort ─────── High Effort
```

**Quick Wins** — Do first. High value, low effort.
**Big Bets** — Plan carefully. High value, high effort.
**Fill Ins** — Do when nothing else. Low value, low effort.
**Money Pit** — Avoid. Low value, high effort.

## MoSCoW

Fast categorization for stakeholder alignment:

| Category | Meaning | Guideline |
|----------|---------|-----------|
| Must | Critical, non-negotiable | ~60% of capacity |
| Should | Important but not critical | ~20% of capacity |
| Could | Nice to have | ~10% of capacity |
| Won't | Not this time | Explicitly excluded |

### Usage
1. Stakeholders categorize independently
2. Discuss disagreements
3. PO makes final call
4. Document rationale

## RICE

Data-driven scoring:

```
RICE Score = (Reach × Impact × Confidence) / Effort
```

| Factor | Definition | Scale |
|--------|------------|-------|
| Reach | Users affected per quarter | Actual number |
| Impact | Effect on each user | 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal |
| Confidence | How sure are we? | 100%=high, 80%=medium, 50%=low |
| Effort | Person-months | Actual estimate |

### Example
```
Feature: One-click checkout
Reach: 10,000 users/quarter
Impact: 2 (high)
Confidence: 80%
Effort: 2 person-months

RICE = (10000 × 2 × 0.8) / 2 = 8,000
```

## WSJF (Weighted Shortest Job First)

Best when cost of delay matters:

```
WSJF = Cost of Delay / Job Size
```

Cost of Delay = User Value + Time Criticality + Risk Reduction

| Factor | 1 | 2 | 3 | 5 | 8 | 13 | 20 |
|--------|---|---|---|---|---|----|----|
| User Value | Minimal | Some | Significant | High | Critical | — | — |
| Time Criticality | Can wait | Somewhat urgent | Deadline approaching | Fixed date | Immediate | — | — |
| Risk Reduction | None | Minor | Moderate | Significant | Critical | — | — |

### Example
```
Feature: GDPR compliance
User Value: 5 (critical for EU users)
Time Criticality: 13 (regulatory deadline)
Risk Reduction: 8 (significant legal risk)
Cost of Delay: 26

Job Size: 5

WSJF = 26 / 5 = 5.2
```

Higher WSJF = do first.

## Kano Model

For feature differentiation:

| Category | User Expectation | Effect |
|----------|------------------|--------|
| Basic | Expected, not delighted | Absent = angry |
| Performance | More is better | Linear satisfaction |
| Delighters | Unexpected | Present = wow |
| Indifferent | Don't care | No effect |
| Reverse | Don't want | Present = unhappy |

### How to Identify
Ask two questions per feature:
1. "How would you feel if we HAD this feature?"
2. "How would you feel if we DIDN'T have this feature?"

| With Feature → | Like | Expect | Neutral | Tolerate | Dislike |
|----------------|------|--------|---------|----------|---------|
| **Without ↓** | | | | | |
| Like | ? | Reverse | Reverse | Reverse | Reverse |
| Expect | Delighter | Indifferent | Indifferent | Indifferent | Reverse |
| Neutral | Delighter | Indifferent | Indifferent | Indifferent | Reverse |
| Tolerate | Delighter | Performance | Performance | Indifferent | Reverse |
| Dislike | Delighter | Performance | Performance | Basic | ? |

### Prioritization
1. **Basics first** — Must have or users leave
2. **Performance next** — Competitive differentiation
3. **Delighters sparingly** — Surprise and retention

## Opportunity Scoring

From Outcome-Driven Innovation:

```
Opportunity = Importance + (Importance - Satisfaction)
```

Survey users:
- "How important is [outcome]?" (1-10)
- "How satisfied are you with current solution?" (1-10)

| Outcome | Importance | Satisfaction | Opportunity |
|---------|------------|--------------|-------------|
| Fast checkout | 9 | 4 | 9 + (9-4) = 14 |
| Pretty UI | 6 | 7 | 6 + (6-7) = 5 |
| Mobile app | 8 | 3 | 8 + (8-3) = 13 |

Higher opportunity = bigger gap to fill.

## Choosing a Framework

| Situation | Best Framework |
|-----------|----------------|
| Quick decision needed | Value/Effort Matrix |
| Stakeholder alignment | MoSCoW |
| Data-driven culture | RICE |
| Cost of delay matters | WSJF |
| Feature differentiation | Kano |
| User research available | Opportunity Scoring |

## Common Mistakes

- Using the same framework for everything
- Letting the framework replace judgment
- Ignoring qualitative insights
- Over-engineering the scoring
- Not revisiting priorities regularly
- Prioritizing by who shouts loudest


path: setup.md
content: # Setup — Product Owner

Read this on first use when `~/product-owner/` doesn't exist.

## Your Attitude

You're a strategic partner, not a scribe. Help the user feel their product work just got easier — backlogs will be clean, stories will be sharp, priorities will be clear.

## Priority Order

### 1. First: Integration

Early in the conversation, ask:
- "Should I help whenever you're working on backlogs or user stories?"
- "Want me to assist with sprint planning proactively, or only when you ask?"

### 2. Then: Understand Their Product

Ask open questions about the big picture:
- What are they building?
- Who are their users?
- What's their team setup?

After each response:
- Reflect back what you understood
- Connect it to how you'll help them prioritize
- Then ask the next question

### 3. Finally: Details (only if they want)

Some POs want detailed frameworks (WSJF, RICE). Others just want help writing stories. Adapt.

## Feedback After Each Response

Don't just jump to the next question. After the user shares something:
1. Acknowledge what they said
2. Show how you'll use it to help their backlog
3. Then continue

## Data Storage

All data is stored locally in `~/product-owner/`:

| Location | Content |
|----------|---------|
| `memory.md` | Product name, team context, priorities |
| `backlog/{product}.md` | Stories as they develop |
| `sprints/` | Sprint history |

No data is sent externally.

## When "Done"

Once you know:
1. When to activate (integration preference)
2. What product they're working on

...you're ready to help. Everything else builds over time.


path: stories.md
content: # User Story Patterns — Product Owner

## Standard User Story

The classic format that works for most features:

```
As a [user type]
I want [capability]
So that [benefit]

Acceptance Criteria:
- Given [context], when [action], then [outcome]
- Given [context], when [action], then [outcome]
```

### Good Example
```
As a mobile app user
I want to save articles for offline reading
So that I can read during my commute without internet

Acceptance Criteria:
- Given I'm viewing an article, when I tap "Save Offline", then the article downloads
- Given I have saved articles, when I open the app offline, then I can read them
- Given I'm online again, when I view a saved article, then it syncs any updates
```

### Bad Example
```
As a user
I want offline mode
So that it works offline
```
Problems: vague user, vague capability, circular benefit.

## Technical Story

For infrastructure, refactoring, or enabling work:

```
As a [team role]
I need [technical capability]
So that [technical benefit enabling user value]
```

### Example
```
As the development team
We need to upgrade the database to PostgreSQL 15
So that we can use JSON path queries for the search feature

Acceptance Criteria:
- Given the upgrade is complete, when running the test suite, then all tests pass
- Given production data, when migrated, then no data loss occurs
- Given the new version, when running queries, then performance equals or exceeds current
```

## Bug Fix Story

For defects that need tracking:

```
Current: [what happens now]
Expected: [what should happen]
Impact: [who is affected, severity]
Steps to Reproduce:
1. [step]
2. [step]
```

### Example
```
Current: Checkout button disappears on mobile Safari
Expected: Checkout button visible and functional
Impact: 15% of mobile users cannot complete purchase (Critical)
Steps to Reproduce:
1. Open cart on iPhone Safari
2. Scroll down to view all items
3. Scroll back up
4. Button is gone
```

## Spike Story

For research and exploration:

```
Spike: [question to answer]
Timebox: [max time]
Output: [deliverable]
```

### Example
```
Spike: Can we integrate with Stripe Connect for marketplace payments?
Timebox: 2 days
Output: Technical feasibility doc with API requirements and effort estimate
```

## Epic Structure

For large features that span multiple sprints:

```
Epic: [name]
Goal: [outcome]
Success Metric: [how we'll know it worked]

Stories:
1. [Story title] — [brief description]
2. [Story title] — [brief description]
3. [Story title] — [brief description]
```

## Acceptance Criteria Patterns

### Given/When/Then (Gherkin)
Best for behavior-driven scenarios:
```
Given I am logged in as an admin
When I click "Delete User"
Then a confirmation dialog appears
And the user is not deleted until confirmed
```

### Checklist Style
Best for simple validations:
```
Acceptance Criteria:
- [ ] Form validates email format
- [ ] Error message shows for invalid input
- [ ] Success message shows after submission
- [ ] Data appears in admin dashboard
```

### Rules-Based
Best for complex business logic:
```
Acceptance Criteria:
- Discount applies only to orders over $100
- Maximum discount is 30%
- Discount codes are single-use
- Expired codes show "Code expired" message
```

## Anti-Patterns to Avoid

| Anti-Pattern | Problem | Fix |
|--------------|---------|-----|
| Solution masquerading as story | "Add a button" instead of "enable action" | Focus on user need |
| Vague user | "As a user" | Specify user type |
| No benefit | "So that I can do X" (circular) | Connect to real outcome |
| Too big | Can't fit in sprint | Split into smaller stories |
| No acceptance criteria | "We'll know it when we see it" | Define testable criteria |
| Implementation details | "Using React and Redux" | Focus on behavior |

## Splitting Large Stories

When a story is too big, split by:

| Split By | Example |
|----------|---------|
| User type | Admin vs regular user |
| Action | Create vs edit vs delete |
| Data | One item vs bulk |
| Platform | Web vs mobile |
| Scenario | Happy path vs error handling |
| Performance | Basic vs optimized |

### Example Split
**Original:** "As a user, I want to manage my profile"

**Split:**
1. As a user, I want to view my profile
2. As a user, I want to edit my name and email
3. As a user, I want to upload a profile photo
4. As a user, I want to change my password
5. As a user, I want to delete my account


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)