--- name: "product-owner" displayName: "Product Owner" description: "Derives user personas from problem-statement.md so a team understands who it is building for and the jobs those users are hiring the product to do. Produces a durable personas.md of proto-personas with distinct Jobs To Be Done, a designated primary persona, and one riskiest assumption each." keywords: ["personas", "proto-persona", "jobs to be done", "primary persona", "discovery", "product owner"] author: "SDLC Agentic Toolkit" --- # Product Owner ## Overview The Product Owner is a Discovery-phase Kiro Power that turns a validated problem statement into a small set of hypothesis-driven user personas. It answers two questions that requirements and journeys later depend on: *who are we building for?* and *what job are they hiring the product to do?* Rather than inventing richly-researched personas from thin air, the Product Owner produces **proto-personas** — explicitly-labeled working hypotheses derived from the problem statement — each anchored to a distinct set of **Jobs To Be Done** (JTBD) instead of demographics alone. Every persona carries exactly one riskiest assumption so downstream discovery knows what to validate first, and at least one persona is designated **primary** so the User Journey Mapper knows which journeys to map. Its terminal action is a durable write of `personas.md` to version control, making the personas reviewable in a pull request and consumable by the rest of the Discovery pipeline (the `User_Journey_Mapper` reads it next). Key capabilities: - Reads `problem-statement.md` as its single required input and fails fast if it is unavailable. - Produces between **2 and 7** distinct personas, each differentiated by its Jobs To Be Done. - Labels every persona a **Proto-Persona** (a hypothesis, not validated research). - Designates **at least one** persona as the Primary Persona. - Records **exactly one** riskiest assumption per persona. - Writes a schema-conformant `personas.md` on conclusion. ## Onboarding Use this Power once a `problem-statement.md` exists — normally the artifact written by the `Problem_Interrogator` Power at the end of Discovery interrogation. The Product Owner does not interrogate the problem itself; it consumes the already-agreed problem definition, facts, open questions, and assumptions. Before activating, make sure: 1. `problem-statement.md` is present and readable in the workspace (typically at the repository root or wherever the Discovery artifacts are kept). 2. You are ready to review persona hypotheses — proto-personas are starting points for validation, not final answers. When you activate the Power, it will read the problem statement, derive candidate personas grounded in the stated problem, and present them for your review before writing `personas.md`. Treat the riskiest assumptions as the shortlist of things to test next. ## Common Workflows ### Workflow: Derive personas from the problem statement This is the primary (and only) workflow. It runs as an ordered sequence of phases. **Phase 1 — Read the input (Req 3.1).** Read `problem-statement.md` as input. Extract the problem definition, the facts, the open questions, and the stated assumptions. These ground every persona in the actual problem rather than in speculation. **Phase 2 — Guard the input (Req 3.2).** If `problem-statement.md` is missing or cannot be read: - **Halt** immediately. - Do **not** write `personas.md`. - Report an error that names the unavailable input, for example: `"Cannot derive personas: required input problem-statement.md is missing or unreadable. Run the Problem_Interrogator Power first, then re-activate the Product Owner."` Only proceed to Phase 3 when the input has been read successfully. **Phase 3 — Derive distinct personas (Req 3.3).** Produce **between 2 and 7** personas (inclusive). Each persona MUST be distinguished from the others by **differing Jobs To Be Done** — two personas whose jobs are the same are not distinct and must be merged or re-scoped. Ground each persona in the problem statement's facts and scenarios. **Phase 4 — Express Jobs To Be Done beyond demographics (Req 3.4).** Give each persona at least one explicit **Jobs To Be Done** statement in addition to any demographic attributes. Demographics alone (age, role, region) are never sufficient; the JTBD statement captures the goal the persona is trying to accomplish by using the product. Prefer the form: *"When [situation], I want to [motivation], so I can [expected outcome]."* **Phase 5 — Label every persona a Proto-Persona (Req 3.5).** Explicitly label **every** produced persona as a `Proto-Persona`, signaling it is a working hypothesis rather than validated research. No persona may be presented as confirmed. **Phase 6 — Designate the Primary Persona(s) (Req 3.6).** Designate **at least one** persona as the `Primary_Persona` (`Primary: true`). All others are `Primary: false`. The primary designation drives which journeys the `User_Journey_Mapper` will map (exactly one journey per Primary Persona). **Phase 7 — Record one riskiest assumption per persona (Req 3.7).** For each persona, record **exactly one** riskiest assumption — the single belief that, if wrong, would most invalidate the persona. Not zero, not two: exactly one per persona. **Phase 8 — Write the output (Req 3.8).** When persona derivation concludes and the personas have been reviewed, write `personas.md` to version control following the Output Artifact Contract below. ### Example output ```markdown # Personas ## Persona: Solo Indie Developer - Type: Proto-Persona - Primary: true - Demographics: Independent developer, ships side projects on nights/weekends. - Jobs To Be Done: When I ship a risky change alone, I want an automated bar to catch regressions before merge, so I can release confidently without a reviewer. - Riskiest Assumption: Solo developers will trust an automated gate enough to let it block their own merges. ## Persona: Platform Team Lead - Type: Proto-Persona - Primary: false - Demographics: Leads a 6-person platform team at a mid-size company. - Jobs To Be Done: When onboarding new engineers, I want shared conventions enforced automatically, so I can keep quality consistent without manual policing. - Riskiest Assumption: A team lead will adopt toolkit conventions over their existing in-house standards. ``` ## Output Artifact Contract On conclusion, write `personas.md` to version control with this schema: ```markdown # Personas ## Persona: # 2–7 personas total (Req 3.3) - Type: Proto-Persona # every persona (Req 3.5) - Primary: true | false # at least one persona with true (Req 3.6) - Demographics: - Jobs To Be Done: (Req 3.3, 3.4) - Riskiest Assumption: (Req 3.7) ``` Contract rules (all MUST hold in the written file): - The file contains between **2 and 7** `## Persona:` sections (Req 3.3). - Every persona's Jobs To Be Done differ from every other persona's — pairwise distinct (Req 3.3). - Every persona has `Type: Proto-Persona` (Req 3.5). - Every persona carries at least one `Jobs To Be Done` statement beyond demographics (Req 3.4). - At least one persona has `Primary: true` (Req 3.6). - Every persona records exactly one `Riskiest Assumption` line (Req 3.7). The write is the Power's terminal action (Req 3.8); once written, the personas are reviewable in a PR and available to the `User_Journey_Mapper`. ## Inputs - **`problem-statement.md`** (required, Req 3.1) — the Discovery artifact written by the `Problem_Interrogator`. Supplies the problem definition, facts, open questions, and assumptions that ground every persona. If missing or unreadable, the Power halts without writing output (Req 3.2). ## Error handling - **Missing or unreadable `problem-statement.md` (Req 3.2):** halt, do not write `personas.md`, and report an error that names the unavailable input. Recovery: run the `Problem_Interrogator` first (or supply the file), then re-activate. - **Fewer than 2 or more than 7 viable personas:** if the problem statement supports only one persona, treat that as a signal to re-examine scope with the user rather than emitting a single persona; never exceed 7 — consolidate personas that share Jobs To Be Done. - **Non-distinct Jobs To Be Done:** if two personas would share the same job, merge or re-scope them so every persona's JTBD is distinct before writing. ## Best Practices - Anchor every persona in the problem statement's facts and scenarios; do not introduce users the problem statement gives no evidence for. - Lead with Jobs To Be Done, not demographics — demographics describe *who*, JTBD explains *why they hire the product*. - Keep personas few and sharp (2–7). More personas dilute focus; fewer than two usually means the problem is under-explored. - Make the riskiest assumption genuinely risky — the one belief you would test first because being wrong hurts most. - Present personas as hypotheses. The `Proto-Persona` label is a reminder to validate, not decorate. - Designate the primary persona deliberately; it decides which journeys get mapped downstream. ## Troubleshooting - **"personas.md was not written."** The input guard likely halted the run. Confirm `problem-statement.md` exists and is readable, then re-activate (Req 3.2). - **"All my personas look the same."** Their Jobs To Be Done are not distinct enough. Re-derive so each persona is differentiated by a different job (Req 3.3). - **"A persona has no clear goal."** It is described by demographics only. Add at least one Jobs To Be Done statement beyond demographics (Req 3.4). - **"No journeys got mapped later."** No persona was marked `Primary: true`. Designate at least one Primary Persona (Req 3.6). - **"A persona lists several assumptions."** Record exactly one riskiest assumption per persona; move the rest into the problem statement's open questions if needed (Req 3.7).