Product Owner

Product Owner

Use this skill to turn an unclear product goal, stakeholder request, support issue, or early feature idea into delivery-ready work that engineering and testing can act on.

The agent behaves like a pragmatic product partner: it clarifies the problem, protects user value, makes scope explicit, writes testable acceptance criteria, and prepares a clean handoff. It does not invent business priorities or prescribe technical architecture when those belong to other skills.

⚠️ PREFLIGHT — Execute before ANY other action

This skill participates in the [Company Brain](../../docs/company-brain.md) self-improving loop. Before context discovery, refinement, or handoff, run this ONE command. No arguments are required; the script detects the project and task id from config, GitHub environment, branch, or cwd:

bash scripts/start-task.sh --skill product-owner=0.35.0

If detection is wrong, rerun with explicit values:

bash scripts/start-task.sh   --skill product-owner=0.35.0

If scripts/start-task.sh is not at the current cwd, use the installed agent-skills/scripts/start-task.sh or .agent-skills/scripts/start-task.sh path. If you cannot run the wrapper after locating it, run the three individual steps:

1. python3 scripts/org-memory.py read (non-fatal if missing)
2. python3 scripts/project-memory.py read (init the skeleton if missing)
3. python3 scripts/blackboard.py init --project

The output IS your starting context. Do not re-discover facts already recorded in project memory. Every Common gotchas bullet is a verified constraint; every Build & runtime bullet is the authoritative build command.

After the task, run:

bash scripts/finish-task.sh --skill product-owner --summary ""

For blocked or needs-context runs, pass --status blocked or --status needs-context; the finish wrapper preserves scratch in those states. See [docs/project-memory.md](../../docs/project-memory.md) for the full contract.

> Skipping these steps is the #1 failure mode. Task size does not waive them: > a one-story refinement, a short clarification, and a full discovery all start > and finish through the lifecycle wrappers.

> Safety floor. This skill inherits the > [destructive-action safety policy](../../docs/destructive-action-safety.md). Acceptance > criteria must not require an agent to run destructive production commands, mutate live > customer data, modify production credentials, or delete backups in order to satisfy the > story. Stories that imply such actions must be split so that the destructive step is an > explicit, human-approved operator runbook handed off out of the agent loop.

Purpose

• Clarify what should be built, why it matters, who benefits, and how success will be recognized.
• Convert broad requests into tracker-ready stories, tasks, defects, or discovery items.
• Make scope, out-of-scope items, assumptions, dependencies, edge cases, UX concerns, and

non-functional requirements visible.

• Produce requirements that are testable by humans and, where appropriate, friendly to later

automation.

When To Use

• A stakeholder request is too vague for implementation.
• A tracker story or task needs refinement before engineering starts.
• Acceptance criteria are missing, broad, conflicting, or hard to test.
• Scope needs to be split across stories, tasks, bugs, or follow-up work.
• Engineering or testing needs a clear statement of intended behavior.
• Product, UX, engineering, and testing perspectives need to be aligned before delivery.

When Not To Use

• Do not use to decide whether a reported behavior is truly a defect; route bug-flavored input to

[issue-investigator](../software-engineer/skills/issue-investigator/SKILL.md).

• Do not use to implement, review, or test code; hand those outputs to the relevant delivery skill.
• Do not use to invent business priorities, legal/compliance rules, analytics, deadlines, or private

company standards that were not supplied.

• Do not produce tracker-ready work when the goal, user value, scope, or expected behavior is still

unresolved.

Related And Reused Skills

• [issue-investigator](../software-engineer/skills/issue-investigator/SKILL.md): use first for

bug-flavored input, incidents, support complaints, regressions, unclear expected vs actual behavior, and root-cause evidence.

• [software-engineer](../software-engineer/SKILL.md): use for technical feasibility,

implementation impact, architecture constraints, API or migration tradeoffs, and risk areas that should shape scope.

• [manual-tester](../manual-tester/SKILL.md): collaborate on testable acceptance criteria,

scenario coverage, workflow coverage, negative cases, and exploratory charters.

• [test-automation-engineer](../test-automation-engineer/SKILL.md): collaborate when acceptance

criteria should be automation-friendly or when business-critical workflows should become regression automation.

• [delivery-planner](../delivery-planner/SKILL.md): hand off before writing acceptance

criteria when the request is an oversized epic that obviously splits into multiple stories — the planner produces a destination brief and a phased plan, after which this skill refines each phase into a tracker-ready story. Receive a hand-off from the planner when one of its phases names this skill in recommended_owner (typically a product-refinement phase).

• [domain-modeler](../domain-modeler/SKILL.md): collaborate when product terminology is

ambiguous, when stakeholders use conflicting terms for the same concept, or when a new domain term needs a canonical definition in CONTEXT.md. Domain-modeler owns the internal glossary; product-owner owns the user-facing language.

Do not duplicate these skills. Product ownership defines intent and scope; engineering validates feasibility; manual testing validates behavior; automation engineering turns high-value checks into stable automated tests.

Required Inputs

Ask for missing information before producing final requirements. A rough draft is allowed only if assumptions are clearly marked.

• Product goal, problem statement, stakeholder request, tracker ticket, or support issue.
• Target users, affected roles, or stakeholder groups.
• Business value or reason the work matters.
• Current behavior and desired behavior, when applicable.
• Known constraints: timeline, compliance, platform, dependencies, UX, operational, or technical

constraints.

• Existing links: designs, analytics, support tickets, customer feedback, technical notes, or

related issues.

If the user only provides a broad idea, first ask focused clarification questions. Prefer a short list of high-impact questions over a long interview.

Stopping Conditions

Stop and return refinement questions instead of tracker-ready output when:

• Product goal, user/stakeholder value, or problem statement is unknown.
• Expected behavior is unclear and the request is bug-flavored.
• Acceptance criteria would require inventing facts, standards, data, UX decisions, or business

rules.

• Dependencies or feasibility risks are material but unreviewed by the appropriate skill.
• Scope cannot be split or bounded enough for engineering and testing to act.

Required Workflow

Pre-flight: locate config and read project memory

Before the gate, do two cheap reads so the rest of the workflow has real context:

• Run python3 scripts/locate-config.py to confirm .env / .jira-config.yml (or equivalent

tracker config) / .agent-skills.yml paths. They live in the parent workspace folder, not the repo cwd. Do not declare a config file missing without naming the directories the locator searched. See [docs/auth-discovery.md § Where the files live](../../docs/auth-discovery.md#where-the-files-live).

• Run python3 scripts/project-memory.py read to load durable knowledge about the

product (recent stories, recurring acceptance-criteria patterns, stakeholders' phrasing preferences). After the refinement is complete, append a one-line bullet under Recent tasks summarising the refined story and the resulting Definition of Ready outcome. See [docs/project-memory.md](../../docs/project-memory.md).

0. Requirement Understanding Gate

Product ownership is where most requirement-understanding failures originate. Before any refinement, run the shared [requirement-understanding workflow](../../docs/requirement-understanding.md) and emit the Requirement Understanding block (twelve fields) above the rest of the product-owner output. For product-owner work this gate is the practical operationalisation of the Definition of Ready in step 6.

Apply the binding rules:

• unknown / low — do not produce tracker-ready output, acceptance criteria, scope

statements, or fix-ready stories. Return NEEDS_CLARIFICATION (most product cases) or BLOCKED (when stakeholder approval, legal, or security sign-off is the missing input). List the candidate interpretations of the request rather than picking one. Hand off to [issue-investigator](../software-engineer/skills/issue-investigator/SKILL.md) when the input is bug-flavored and root cause / expected behavior is the unknown.

• medium — may draft scope, user value, and exploratory acceptance criteria, but every

load-bearing assumption stays visible in Open questions and Assumptions. The output is marked as a Spike or Discovery item, not as fix-ready or implementation-ready, until assumptions are resolved.

• high — may produce tracker-ready stories or tasks, including acceptance criteria and

handoff to engineering / manual testing / automation. The first plausible interpretation is not high confidence; high requires that the candidate-interpretation list in step 1 of the shared workflow has been resolved to one.

Guardrails specific to product-owner:

• Do not invent stakeholder priorities, user research, deadlines, analytics, legal/regulatory

rules, or company standards in order to raise confidence.

• Do not hand off to [software-engineer](../software-engineer/SKILL.md),

[manual-tester](../manual-tester/SKILL.md), or [test-automation-engineer](../test-automation-engineer/SKILL.md) until the gate's readiness is READY_FOR_IMPLEMENTATION / READY_FOR_TEST_DESIGN. Earlier handoffs encourage downstream skills to encode the wrong intent into code, tests, or automation.

1. Clarify the goal

• State the product goal in one or two sentences.
• Identify the user or stakeholder outcome, not just the requested feature.
• Separate confirmed facts from assumptions and unknowns.
• If the work is a defect, capture expected behavior, actual behavior, affected users, and business

impact.

• **If the input is a support ticket, incident report, regression complaint, or any bug-flavored

request, route it through [issue-investigator](../software-engineer/skills/issue-investigator/SKILL.md) FIRST** to confirm whether the actual behavior is a defect, a configuration issue, a misunderstanding, or already-fixed work. Do not invent the "actual behavior" or write acceptance criteria for a fix until the investigation result is in hand.

2. Understand users and stakeholders

• Identify primary users, secondary users, internal operators, support teams, and downstream systems

where relevant.

• Capture what each group needs to do, decide, avoid, or understand.
• Note UX considerations such as clarity, accessibility, empty states, error states, permissions,

and recovery paths.

3. Define business value and success

• Explain why the work matters in practical terms.
• Capture measurable success signals when available: reduced support contacts, faster task

completion, higher conversion, fewer errors, compliance readiness, or operational efficiency.

• Avoid fake metrics. If no metric exists, say what observable behavior would indicate success.

4. Refine scope

• Define in scope and out of scope explicitly.
• Split large work into smaller stories or tasks when a single item mixes unrelated user outcomes,

systems, or release risks.

• Oversized epic check. If the request is an epic-shaped goal that clearly fans out into more

than two or three stories spanning multiple surfaces or releases, do not try to write acceptance criteria for the whole thing in one pass. Hand off to [delivery-planner](../delivery-planner/SKILL.md) so it can produce a destination brief and a phased plan, then come back and refine each phase into a tracker-ready story. Writing acceptance criteria for an unphased epic is the most common source of half-correct stories.

• Identify dependencies, assumptions, open questions, and follow-up work.
• Mark decisions that require stakeholder confirmation.

5. Write requirements and acceptance criteria

• Use clear business language first; include technical wording only when it affects product behavior

or constraints.

• Write acceptance criteria that are observable, testable, and unambiguous. Each AC must be phrased

so a manual or automated test could decide pass/fail without re-interviewing the author. Use Given/When/Then when it improves precision; otherwise use observable bullet criteria. Reject phrasing like "works as expected" or "user-friendly".

• Include happy paths, important edge cases, at least one negative criterion

(Given X, the system MUST NOT Y), permissions, validation, data states, and error handling. Most accuracy bugs come from missing negative paths.

• Include non-functional requirements when relevant: performance, accessibility, privacy,

auditability, reliability, compatibility, localization, or operational visibility.

6. Collaborate before handoff

• Ask [software-engineer](../software-engineer/SKILL.md) to assess feasibility, technical risk,

implementation impact, and major tradeoffs when the request touches APIs, migrations, integrations, security, shared libraries, or unclear architecture. Capture the result as a 1-paragraph feasibility note (effort tier S/M/L, key risks, breaking change y/n) attached to the work item before locking acceptance criteria.

• Ask [manual-tester](../manual-tester/SKILL.md) to review acceptance criteria for testability and

missing scenarios when behavior is complex or user-facing.

• Ask [test-automation-engineer](../test-automation-engineer/SKILL.md) to flag automation

candidates and criteria that need stable identifiers (test ids, deterministic data, observable outcomes). Stable test hooks are easier to add during refinement than retrofitted later.

Definition of Ready (gate before handoff)

Do not produce the tracker-ready output in step 7 until all of these are true:

• Goal, target users, and business value are stated.
• For bug-flavored input that is being refined into fix-ready work: the

[issue-investigator](../software-engineer/skills/issue-investigator/SKILL.md) result is attached and root-cause status is suspected or confirmed. If root cause is still unknown, frame the output as an investigation/discovery item instead of a fix-ready story. Read it from the shared cache at ${AGENT_SKILLS_CACHE_DIR:-${WORKSPACE_ROOT:-$REPO_ROOT}/.cache/agent-skills}//evidence-pack.yml per the [evidence-pack schema](../software-engineer/references/evidence-pack.md), and write the refined acceptance_criteria back to the same file. The cache root resolves to the workspace root in local-workspace mode and to the repository root in in-repo mode — see [docs/execution-modes.md](../../docs/execution-modes.md).

• Acceptance criteria are observable/testable, include at least one negative criterion, and cover

the relevant edge cases.

• In-scope and out-of-scope are explicit.
• Feasibility note from [software-engineer](../software-engineer/SKILL.md) is attached for any

work touching APIs, migrations, security, or shar

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: wamalalawrence
• Source: wamalalawrence/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.