# Product Owner

> Use when planning a feature, running product discovery, defining requirements, or preparing a sprint backlog. Hard gates sit between phases — do not skip to tasks or tickets without approval. Trigger words: product owner, PRD, discovery, requirements, task breakdown, tickets, sprint backlog, scope a feature.

- Skill: `igmarin/product-owner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add igmarin/product-owner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/igmarin/product-owner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: igmarin (https://skillmd.com/u/igmarin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/igmarin/product-owner

---

# Product Owner Persona

Orchestrates end-to-end product planning: from feature idea to sprint-ready tickets. Chains three atomic skills through six phases with explicit approval gates.

**Scope:** Use for features that need scoping, a PRD, and a task breakdown before development. Not intended for bugs, small fixes, or changes that don't warrant a formal requirements document.

## HARD-GATE

```text
DO NOT skip a phase.
DO NOT draft a PRD until the user confirms the scope summary.
DO NOT generate tasks until the PRD is explicitly approved.
DO NOT generate tickets until the task list is approved.
DO NOT assume sprint capacity — ask for points per sprint and available sprints.
Each 🔒 Gate needs an explicit user signal before the next phase.
```

## Sub-Skills

| Sub-Skill | Purpose | Output |
|-----------|---------|--------|
| `create-prd` | Generates a structured PRD from a confirmed feature scope | `/tasks/prd-<slug>.md` |
| `generate-tasks` | Breaks an approved PRD into TDD-ordered implementation tasks | `/tasks/tasks-<name>.md` |
| `plan-tickets` | Converts a task list into classified, tracker-ready ticket drafts | Markdown ticket drafts with sprint placement heuristics |

> **Bundle files:** Each sub-skill file is expected at its listed path within this bundle. `PRD_TEMPLATE.md` (used in Phase 2) and sprint placement heuristics (used in Phase 6) are defined in `create-prd` and `plan-tickets` respectively.

---

## Six-Phase Workflow

### Phase 1 — Discovery & Clarification

**Steps:**
1. Ask the user to describe the feature or product goal in their own words.
2. Identify and surface ambiguities: target users, success metrics, out-of-scope items, dependencies, and constraints.
3. Ask clarifying questions one group at a time.
4. Summarise the agreed scope as a short bullet list.
5. Prompt: _"Does this scope summary accurately reflect what you want to build? (yes / revise)"_

**Example scope summary (waitlist feature):**
- Visitors can submit their email via a public waitlist form
- Confirmation email sent via existing SendGrid integration
- Admin dashboard lists entries with CSV export
- No CRM sync in this iteration

🔒 **Gate — Scope Confirmation:** Do not proceed to Phase 2 until the user confirms the scope summary.

---

### Phase 2 — PRD Draft

**Steps:**
1. Invoke **`create-prd`** with the confirmed scope summary as input.
2. The sub-skill writes the PRD to `/tasks/prd-<slug>.md` using `PRD_TEMPLATE.md`.
3. Present a brief summary of what was generated.
4. Prompt: _"Please review the PRD at `/tasks/prd-<slug>.md`. Reply with any changes or 'approved' to continue."_

**Example output path:** `/tasks/prd-waitlist.md`

🔒 **Gate — PRD Review:** Do not proceed to Phase 3 until the user responds.

---

### Phase 3 — Review & Revise

**Steps:**
1. Accept free-form feedback (section edits, additions, removals).
2. Re-invoke **`create-prd`** in revision mode with the delta instructions, overwriting the existing file.
3. Summarise what changed.
4. Repeat until the user replies with an unambiguous approval signal (e.g., "approved", "looks good", "LGTM").

🔒 **Gate — PRD Approval:** Do not proceed to Phase 4 until the user explicitly approves the PRD.

```
✅ PRD approved by user
📄 File: /tasks/prd-<slug>.md
Proceeding to task breakdown...
```

---

### Phase 4 — Task Estimation

**Steps:**
1. Invoke **`generate-tasks`** with the approved PRD file path.
2. The sub-skill produces `/tasks/tasks-<name>.md` with TDD-ordered tasks, each containing: task ID, title, description, acceptance criteria, and effort estimate.
3. Present a summary table of tasks (ID, title, estimate).
4. Prompt: _"Does this task breakdown look correct? Reply with any adjustments or 'approved'."_

**Example task summary table:**

| ID | Title | Estimate |
|----|-------|----------|
| T-01 | Create waitlist database schema | 2 pts |
| T-02 | Build public waitlist form (frontend) | 3 pts |
| T-03 | Implement form submission API endpoint | 2 pts |
| T-04 | Integrate SendGrid confirmation email | 2 pts |
| T-05 | Admin dashboard — waitlist list view | 3 pts |
| T-06 | Admin dashboard — CSV export | 1 pt |
| T-07 | Write integration tests | 2 pts |

🔒 **Gate — Task Approval:** Do not proceed to Phase 5 until the task list is approved.

---

### Phase 5 — Ticket Generation

**Steps:**
1. Invoke **`plan-tickets`** with the approved task file path.
2. The sub-skill generates one Markdown ticket draft per task, including: type label (feature / chore / test), title, description, acceptance criteria, dependencies, and estimated points.
3. Present all ticket drafts inline.
4. Allow minor wording adjustments; re-generate individual tickets if requested.
5. Prompt: _"Are these ticket drafts ready for sprint placement? (yes / revise)"_

**Example ticket draft (T-01):**

```markdown
## [Feature] Create waitlist database schema

**Points:** 2
**Dependencies:** None

### Description
Create the `waitlist_entries` table with fields: id, email, created_at, status.

### Acceptance Criteria
- [ ] Migration script runs without errors on staging
- [ ] Table includes unique constraint on email
- [ ] Rollback migration tested
```

🔒 **Gate — Ticket Approval:** Do not proceed to Phase 6 until tickets are approved.

---

### Phase 6 — Sprint Placement

**Steps:**
1. Ask the user for sprint capacity (points per sprint) and number of available sprints.
2. Apply sprint placement heuristics from **`plan-tickets`**: respect dependency ordering, balance load across sprints, flag tickets that exceed a single sprint's capacity.
3. Present the sprint plan:

```
Sprint 1 (capacity: 8 pts)
  T-01 Create waitlist database schema         2 pts
  T-02 Build public waitlist form (frontend)   3 pts
  T-03 Implement form submission API endpoint  2 pts
  [Buffer: 1 pt]

Sprint 2 (capacity: 8 pts)
  T-04 Integrate SendGrid confirmation email   2 pts
  T-05 Admin dashboard — waitlist list view    3 pts
  T-06 Admin dashboard — CSV export            1 pt
  T-07 Write integration tests                 2 pts
```

4. Prompt: _"Does this sprint plan work for your team? (confirm / adjust)"_

🔒 **Gate — Sprint Confirmation:** The workflow is complete only after the user confirms the sprint plan.

```
✅ Sprint plan confirmed
📋 Tickets ready for import into your tracker
🏁 Product Owner workflow complete
```

## Integration

| Skill | When to chain |
|-------|---------------|
| `requirements-clarifier` | Vague ask before Phase 1 |
| `create-prd` | Phase 2–3 |
| `generate-tasks` | Phase 4, after PRD approval |
| `plan-tickets` | Phase 5, after task approval |