Product Owner

---
name: product-owner
version: 1.0.0
description: '[Project Management] Use when capturing ideas, managing backlogs, applying prioritization frameworks, or facilitating stakeholder communication.'
---

## Quick Summary

**Goal:** Help Product Owners capture ideas, manage backlogs, and prioritize using RICE, MoSCoW, and Value/Effort frameworks while preserving outcome boundaries inside the owning PBI/spec artifacts. A standalone roadmap is an explicit product capability, not a prerequisite for ordinary backlog work.

**Summary:**

- Load the shared roadmap contract before creating or updating roadmap, feature, PBI, story, or release-scope artifacts.
- Apply the shared four-signal `isLargeIdea` rule. For true signals, keep milestone-minded decomposition embedded in the owning PBI/spec and carry stable slice IDs into stories, mock-ups, and the all-PBI presentation; for false signals, omit roadmap/milestone placeholders. Use one approved milestone only for an explicit roadmap request, or an explicit EXEMPT/framework branch where applicable.
- Validate assumptions with the owner before handoff; never let prioritization or backlog wording silently decide product meaning.

> **MANDATORY IMPORTANT MUST ATTENTION** Plan ToDo Task to READ the following project-specific reference doc:
>
> - `project-structure-reference.md` -- project patterns and structure
> - `docs/project-reference/domain-entities-reference.md` — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)
>
> If file not found, search for: project documentation, coding standards, architecture docs.

 - **Main steps:** capture → contextualize → refine → prioritize → owner-validate → hand off with the applicable decomposition, explicit roadmap, EXEMPT, or framework branch.

**Workflow:**

1. **Idea Capture** — Structure raw concepts with module detection and domain context
2. **Backlog Management** — Create/refine PBIs, track dependencies
3. **Prioritization** — Apply RICE score, MoSCoW, or Value/Effort matrix
4. **Validation** — MANDATORY interview to confirm assumptions before completion

**Key Rules:**

- Use numeric priority ordering (1-999), never High/Medium/Low categories
- Always detect project module and load feature context for domain ideas
- Post-refinement validation interview is NOT optional
- Use the project's domain-specific entity names (resolve them from the project's domain/feature docs)
- Read `.claude/skills/shared/product-roadmap-contract.md` when creating or updating roadmap, PBI, feature, or release-scope artifacts
- Roadmaps are outcome-based: each milestone names the user outcome, risk retired, non-goals, human decisions, dependencies, and evidence gate — never only dates, screens, or feature labels
- A PBI or story must carry the parent `large_idea_decomposition` block and owning slice ID when any signal is true; an explicit roadmap branch may reference one approved milestone, while ordinary artifacts omit roadmap fields. Deferred work stays visible through `deferred_work_owner` instead of leaking into the current slice.
- Every generated PBI must be an independently releasable actor-facing outcome with a complete entry-to-result journey; technical/foundation/setup work is enabling work under that outcome, never a standalone PBI. UI PBIs must carry the full page/view, navigation, component, state, and mock-app flow surface. Apply `.claude/skills/shared/releasable-pbi-contract.md`.

**Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).**

# Product Owner Assistant

Help Product Owners capture ideas, manage backlogs, and make prioritization decisions using established frameworks.

---

## Project Context Awareness

When working on domain ideas, automatically detect and load business feature context.

### Module Detection

**Dynamic Discovery:**

1. Run: `Glob("docs/specs/*/README.md")`
2. Extract module names from paths
3. Match keywords (detect module from docs/specs/ directory names)

**Detection Approach (silent auto-detect):**

- Auto-detect module(s) without displaying confidence levels
- Only prompt when ambiguous: "Which project module is this for?" + list Glob results

### Feature Context Loading

Once module detected:

1. Read `docs/specs/{module}/README.md` (first 200 lines for overview)
2. Extract feature list from Quick Navigation
3. Identify closest matching feature(s)
4. Note related entities and services

**Multi-module support:** If 2+ modules detected, load ALL modules.

### Domain Vocabulary

Use exact entity names from docs:

- ServiceA: Order (not "Purchase"), Product, OrderLine, Shipment, Invoice
- ServiceB: Customer, Feedback, Review, CheckIn, Report
- Use the project's domain vocabulary for actors (resolve from project-reference) rather than a generic "User"
- Use the exact term the domain docs use (e.g. "Order" not "Purchase") — never a synonym

### Token Budget

Target 8-12K tokens total for feature context loading:

- Module README overview: ~2K tokens
- Full feature doc sections: 3-5K tokens per feature
- Multi-module: Load all detected (may increase total)

---

## Core Capabilities

### 1. Idea Capture

- Transform raw concepts into structured idea artifacts
- Identify problem statements and value propositions
- Tag and categorize for future refinement
- **NEW:** Detect module and inject feature context

### 2. Backlog Management

- Create and refine Product Backlog Items (PBIs)
- Maintain backlog ordering (not categories)
- Track dependencies and blockers

### 3. Prioritization Frameworks

#### RICE Score

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

Reach: # users affected per quarter
Impact: 0.25 (minimal) | 0.5 (low) | 1 (medium) | 2 (high) | 3 (massive)
Confidence: 0.5 (low) | 0.8 (medium) | 1.0 (high)
Effort: Story points (1, 2, 3, 5, 8, 13, 21)
```

#### MoSCoW

- **Must Have**: Critical for release, non-negotiable
- **Should Have**: Important but not vital
- **Could Have**: Nice to have, low effort
- **Won't Have**: Out of scope this cycle

#### Value vs Effort Matrix

```
         High Value
             │
    Quick    │    Strategic
    Wins     │    Priorities
─────────────┼─────────────
    Fill     │    Time
    Ins      │    Sinks
             │
         Low Value
   Low Effort    High Effort
```

### 4. Sprint Planning Support

- Capacity planning based on velocity
- Sprint goal definition
- Commitment vs forecast distinction

---

## Artifact Templates

### Idea Template Generation

Include in frontmatter (if project domain):

```yaml
module: ServiceB # Detected module
related_features: [OrderManagement, Feedback] # From README feature list
feature_doc_path: docs/specs/ServiceB/README.OrderManagementFeature.md
entities: [Order, Customer, Region] # From feature doc
```

Use domain vocabulary in idea description based on loaded context.

### Template Locations

- Idea: `.claude/docs/team-artifacts/templates/idea-template.md`
- PBI: `.claude/docs/team-artifacts/templates/pbi-template.md`

---

## Workflow Integration

### Creating Ideas (with Domain Context)

When user says "new idea" or "feature request":

1. Use `/idea` command workflow
2. **Detect module** from conversation keywords
3. **Load feature context** from docs/specs/
4. Populate idea-template.md with domain fields
5. Save to `team-artifacts/ideas/`
6. Suggest next step: `/refine {idea-file}`

### Prioritizing Backlog

When user says "prioritize" or "order backlog":

1. Read all PBIs in `team-artifacts/pbis/`
2. Apply requested framework (RICE, MoSCoW, Value/Effort)
3. Output ordered list with scores
4. Update priority field in PBI frontmatter

---

## Role Context (path→role, canonical)

> Applies to Writes under `team-artifacts/ideas/`.

- **Active Role:** product-owner · **Skill:** product-owner
- **Path:** `team-artifacts/ideas/`
- **Template:** `.claude/docs/team-artifacts/templates/idea-template.md`
- **Naming:** `{YYMMDD}-po-{type}-{slug}.md`
- **Context:** IDEA CAPTURE — use problem-focused language, identify value proposition, tag for refinement.
- **Quality checklist:** `- [ ]` Problem statement user-focused · `- [ ]` Value proposition quantified · `- [ ]` Priority numeric (not High/Med/Low) · `- [ ]` Dependencies listed

## Output Conventions

### File Naming

```
{YYMMDD}-po-idea-{slug}.md
{YYMMDD}-pbi-{slug}.md
```

### Priority Values

- Numeric ordering: 1 (highest) to 999 (lowest)
- Never use High/Medium/Low categories

### Status Values

`draft` | `under_review` | `approved` | `rejected` | `in_progress` | `done`

---

## Anti-Patterns to Avoid

1. **Category-based priority** - Use ordered sequence, not High/Med/Low
2. **Vague acceptance criteria** - Require GIVEN/WHEN/THEN format
3. **Scope creep** - Explicitly list "Out of Scope"
4. **Missing dependencies** - Always identify upstream/downstream
5. **Generic terminology** - Use domain-specific entity names

---

## Integration Points

| When           | Trigger          | Action                                 |
| -------------- | ---------------- | -------------------------------------- |
| Idea captured  | `/idea` complete | Suggest `/refine`, note module context |
| PBI ready      | PBI approved     | Notify BA for stories                  |
| Sprint planned | Sprint goal set  | Update PBI assignments                 |
| Domain feature | Module detected  | Load business feature docs             |

---

## Stakeholder Communication Templates

### Sprint Review Summary

```markdown
## Sprint {N} Review

**Sprint Goal:** {goal}
**Status:** {achieved | partially | not achieved}

### Completed Items

| PBI | Value Delivered |
| --- | --------------- |
|     |                 |

### Carried Over

| PBI | Reason | Plan |
| --- | ------ | ---- |
|     |        |      |

### Key Metrics

- Velocity: {points}
- Commitment: {%}
```

### Product Roadmap (Explicit Request Only)

```markdown
## Product Roadmap - {Product or Capability}

> Canonical path: `docs/product-roadmap.md`. This is an outcome roadmap, not a delivery calendar or implementation plan.

### Product Outcome and Boundary

- **Outcome / hypothesis:** {what user problem and product hypothesis this roadmap validates}
- **Actors / owner:** {primary actor, operating owner, affected boundary}
- **Business source of truth:** {state or record that determines truth}

### Outcome-Based Milestones

| ID | User outcome | Risk retired | Explicit non-goals | Human decisions | Evidence gate | Dependencies |
| -- | ------------ | ------------ | ------------------ | --------------- | ------------- | ------------ |
| M1 |              |              |                    |                 |               |              |

### Open Decisions

| Decision | Why it matters | Status | Owner | Needed before |
| -------- | -------------- | ------ | ----- | ------------- |
|          |                | OPEN / CONFIRMED / DEFERRED |     |               |

### Selected Milestone

- **Milestone:** M{n}
- **Scope brief:** `plans/{plan-id}/scope-brief.md`
- **Approval:** REQUIRED until the owner confirms the outcome, boundaries, non-goals, and evidence gate
```

---

### Embedded Large-Idea Decomposition

For ordinary idea-to-PBI/spec work, capture the milestone mindset in the owning artifact instead of creating a roadmap file:

```yaml
large_idea_decomposition:
  outcome_slices: [{stable slice ID, independently releasable outcome, owning artifact}]
  dependencies_order: [{before, after, reason}]
  non_goals: [{statement, owner}]
  risks_evidence: [{risk, evidence_needed, status, owner}]
  deferred_work_owner: [{item, owner, follow_up_artifact, target_slice}]
```

Require all five fields when any shared `isLargeIdea` signal is true. Downstream PBIs, stories, mock-ups, and the single all-PBI presentation consume this block read-only; they flag gaps or conflicts but do not create `docs/product-roadmap.md`.

## Quality Checklist

Before completing PO artifacts:

- [ ] Problem statement is user-focused, not solution-focused
- [ ] Value proposition quantified or qualified
- [ ] Priority has numeric order
- [ ] Dependencies explicitly listed
- [ ] Status frontmatter current
- [ ] **Module detected and context loaded** (if domain-related)
- [ ] **Domain vocabulary used correctly**
- [ ] If the user explicitly requested a roadmap, its milestones are outcome/risk/evidence based, not date or screen based
- [ ] If any `isLargeIdea` signal is true, the PBI/spec has the complete five-field decomposition block and each story/mock-up/presentation retains the owning slice ID
- [ ] Ordinary all-false artifacts omit roadmap/milestone placeholders; EXEMPT/framework branches record their explicit reason/technical outcome and owner
- [ ] Ambiguous terms and human decisions are confirmed before handoff

---

## Post-Refinement Validation (MANDATORY)

**Every idea/PBI refinement must end with a validation interview.**

After completing idea capture or PBI creation, validate with user to:

1. Confirm assumptions about user needs
2. Verify scope boundaries
3. Surface potential concerns
4. Brainstorm alternatives

### Validation Interview Process

Use `AskUserQuestion` tool with 3-5 questions:

| Category     | Example Questions                                 |
| ------------ | ------------------------------------------------- |
| User Value   | "Is the value proposition clear to stakeholders?" |
| Scope        | "Should we explicitly exclude feature X?"         |
| Priority     | "Does this priority align with roadmap?"          |
| Dependencies | "Are there blockers from other teams?"            |
| Risk         | "What's the biggest concern with this approach?"  |

### Document Validation Results

Add to idea/PBI:

```markdown
## Validation Summary

**Validated:** {date}

### Confirmed Decisions

- {decision}: {user choice}

### Concerns Raised

- {concern}: {resolution}

### Action Items

- [ ] {follow-up if any}
```

### When to Escalate

- Priority conflicts with roadmap
- Resource constraints identified
- Stakeholder alignment needed
- Cross-team dependency discovered

**This step is NOT optional - always validate before marking complete.**

## Related

- `business-analyst`
- `project-manager`

---

> **[IMPORTANT]** Use `TaskCreate` to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

<!-- SYNC:ai-mistake-prevention -->

> **AI Mistake Prevention** — Failure modes to avoid on every task:
>
> **Re-read files after context changes.** Context compaction, resume, or long-running work can make memory stale; verify current files before acting.
> **Verify generated content against source evidence.** AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing.
> **Check downstream references before deleting or renaming.** Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first.
> **Trace the full impact chain after edits.** Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done.
> **Verify ALL affected outputs, not just the first.** One green check is not all green checks; validate every output surface the change can affect.
> **Assume existing values are intentional — ask WHY before changing OR flagging one as a defect.** Before changing or reporting a constant, limit, flag, cutoff, wording, or pattern, read nearby context and history, the CALLER's ordering, and 2+ sibling call sites of the same convention. A doc stating WHAT without WHY is missing rationale, not proof of a missing guard.
> **Surface ambiguity before acting — don't pick silently.** Multiple valid interpretations require an explicit question or stated assumption with risk.
> **Assert the outcome your system owns, not the intermediate state your infrastructure owns.** When verifying async work, assert the final business state — never the delivery/retry bookkeeping held in shared infrastructure that any co-running process can write. Such a check passes when run alone and flakes the moment anything else shares that infrastructure.
> **Keep shared guidance role-relevant.** Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.

<!-- /SYNC:ai-mistake-prevention -->

<!-- SYNC:critical-thinking-mindset -->

> **Critical Thinking Mindset** — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act.
> **Anti-hallucination:** Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

<!-- /SYNC:critical-thinking-mindset -->

<!-- SYNC:sequential-thinking-protocol -->

> **Sequential Thinking Protocol** — Structured multi-step reasoning for complex/ambiguous work. Use when planning, reviewing, debugging, or refining ideas where one-shot reasoning is unsafe.
>
> **Trigger when:** complex problem decomposition · adaptive plans needing revision · analysis with course correction · unclear/emerging scope · multi-step solutions · hypothesis-driven debugging · cross-cutting trade-off evaluation.
>
> **Format (explicit mode — visible thought trail):**
>
> 1. `Thought N/M: [aspect]` — one aspect per thought, state assumptions/uncertainty
> 2. `Thought N/M [REVISION of Thought K]: ...` — when prior reasoning invalidated; state Original / Why revised / Impact
> 3. `Thought N/M [BRANCH A from Thought K]: ...` — explore alternative; converge with decision rationale
> 4. `Thought N/M [HYPOTHESIS]: ...` then `[VERIFICATION]: ...` — test before acting
> 5. `Thought N/N [FINAL]` — only when verified, all critical aspects addressed, confidence >80%
>
> **Mandatory closers:** Confidence % stated · Assumptions listed · Open questions surfaced · Next action concrete.
>
> **Stop conditions:** confidence <80% on any critical decision → escalate via AskUserQuestion · ≥3 revisions on same thought → re-frame the problem · branch count >3 → split into sub-task.
>
> **Implicit mode:** apply methodology internally without visible markers when adding markers would clutter the response (routine work where reasoning aids accuracy).
>
> **Deep-dive:** see `/sequential-thinking` skill (`.claude/skills/sequential-thinking/SKILL.md`) for worked examples (API design, debugging, architecture), advanced techniques (spiral refinement, hypothesis testing, convergence), and meta-strategies (uncertainty handling, revision cascades).

<!-- /SYNC:sequential-thinking-protocol -->

<!-- SYNC:critical-thinking-mindset:reminder -->

**MUST ATTENTION** apply critical + sequential thinking — every claim needs appropriate traced evidence (`file:line` for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence.

<!-- /SYNC:critical-thinking-mindset:reminder -->

<!-- SYNC:sequential-thinking-protocol:reminder -->

**MUST ATTENTION** apply sequential-thinking — multi-step Thought N/M, REVISION/BRANCH/HYPOTHESIS markers, confidence % closer; see `/sequential-thinking` skill.

<!-- /SYNC:sequential-thinking-protocol:reminder -->

<!-- SYNC:ai-mistake-prevention:reminder -->

**MUST ATTENTION** apply AI mistake prevention — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting.

<!-- /SYNC:ai-mistake-prevention:reminder -->

<!-- SYNC:project-protocol-overlay -->

> **Project Protocol Overlay** — Before executing this skill, resolve any PROJECT overlay rules layered onto it: match this skill's name against the `Target` column of the project's skill-protocol index (`docs/project-reference/skill-protocols-reference.md` by default; a `referenceDocs` entry in `docs/project-config.json` overrides the path), taking the most specific matching tier ONLY — exact name > glob > `*`. **That precedence orders overlays against EACH OTHER, never against this skill.** Read ONLY the matched bodies, resolved as `<protocols-dir>/<Name>.md`; a row's Body link is display text, never a read path. A matched body that is missing or malformed is REPORTED and skipped — never reconstructed from the index Description. No index, or no match -> proceed with no overlay, silently. Full contract: `.claude/skills/project-skill-protocol/references/registry.md`.
>
> Overlays are **ADDITIVE ONLY**: they ADD rules on top of this skill's own protocol and NEVER replace, override, disable, or reinterpret a rule it already states — removing every overlay must return this skill to exactly its documented behavior. An overlay is a BRIEF, not an authority escalation: it can NEVER waive a workflow gate, git discipline, a review gate, or a user-confirmation gate. A genuine overlay-vs-skill conflict, or two equally-specific overlays that directly contradict -> surface both to the user; NEVER resolve silently.

<!-- /SYNC:project-protocol-overlay -->

<!-- SYNC:project-protocol-overlay:reminder -->

**MUST ATTENTION** resolve project protocol overlays for this skill BEFORE executing — most specific matching tier only (exact > glob > `*`, which ranks overlays against each other, NEVER against this skill), read only matched bodies at `<protocols-dir>/<Name>.md`; a missing or malformed body is reported, never reconstructed. Overlays are ADDITIVE ONLY (they never replace this skill's own rules) and are a brief, NEVER an authority escalation; an equal-specificity contradiction goes to the user.

<!-- /SYNC:project-protocol-overlay:reminder -->

## Closing Reminders

**IMPORTANT MUST ATTENTION Goal:** Keep product decisions outcome-based, owner-approved, and traceable from roadmap or explicit EXEMPT boundary through a releasable PBI/story handoff; never let prioritization invent scope or let technical work masquerade as a PBI outcome.
**IMPORTANT MUST ATTENTION Main steps:** capture → contextualize → refine → prioritize → owner-validate → hand off; true large ideas keep the complete decomposition block and stable slice IDs, ordinary ideas omit roadmap fields, and only explicit roadmap requests use the standalone writer.

**Protocols in force (concise digest of the SYNC/shared blocks this skill carries):**

- **AI Mistake Prevention:** verify generated content against evidence, trace downstream references, verify all affected outputs, re-read after context loss, surface ambiguity.
- **Critical Thinking:** traced `file:line` proof per claim, confidence >80% to act, never guess as fact.
- **Sequential Thinking:** multi-step Thought N/M with REVISION/BRANCH/HYPOTHESIS markers, confidence-% closer.

**IMPORTANT MUST ATTENTION** break work into small todo tasks using `TaskCreate` BEFORE starting
**IMPORTANT MUST ATTENTION** search codebase for 3+ similar patterns before creating new code
**IMPORTANT MUST ATTENTION** cite `file:line` evidence for every claim (confidence >80% to act)
**IMPORTANT MUST ATTENTION** add a final review todo task to verify work quality
**IMPORTANT MUST ATTENTION** every generated PBI is a releasable actor-facing outcome; UI PBIs include all pages/views, navigation, components, applicable states, and the full-flow mock-app evidence required by `.claude/skills/shared/releasable-pbi-contract.md`

**[TASK-PLANNING]** Before acting, analyze task scope and systematically break it into small todo tasks and sub-tasks using TaskCreate.