Proposal: Product Owner Agent

[CaseyMargell]

Problem

Engineering agents are excellent at execution — clean code, passing tests, good architecture. But nothing in the current workflow validates whether work aligns with project-specific product strategy after the human steps away.

I've run into this repeatedly with agentic workflows: lots of execution cycles but nothing steering the WHAT and WHY the way a product manager would. Specifically around things like product functionality tradeoffs where Simplicity says it's over-engineering but it's critical functionality for our target audience.

Spending time up front on planning and goals pays off. It pays off even more when there's something in the workflow enforcing that alignment autonomously.

Proposal

A product-owner agent that reads a project-level PRODUCT.md (target users, P0-P4 strategic priorities, product principles, domain knowledge) and validates work against those requirements at each phase of the lifecycle.

I've been using this in my workflows and have found it helpful.

Lifecycle integration

graph LR
    PM[PRODUCT.md] --> PO[product-owner]
    PO -->|strategic validation| A[ce:brainstorm]
    PO -->|strategic validation| B[ce:plan]
    PO -->|kickoff + checkpoints| C[ce:work]
    PO -->|conditional review| D[ce:review]
    PO -->|learning capture| E[ce:compound]
    E -.->|product learnings| PM

Loading

Phase	What product-owner does
ce:brainstorm	Validates idea against strategic priorities before investing brainstorm time
ce:plan	Validates feature alignment before research and planning
ce:work	Kickoff validation + decision/milestone checkpoints during execution
ce:review	Conditional product review alongside technical reviewers
ce:compound	Detects product learnings and proposes PRODUCT.md updates

Plus a standalone product-acceptance skill for on-demand product review of PRs, branches, or current changes.

Key design decisions

• Conditional on PRODUCT.md existing. Every integration checks for PRODUCT.md first and gracefully skips if absent. Zero impact on projects that don't use it.
• Complements product-lens-reviewer, doesn't replace it. product-lens challenges premises from first principles (no project context). product-owner validates against stated product requirements (reads PRODUCT.md). Different inputs, different questions — one is discovery ("should we?"), the other is enforcement ("did we?").
• PRODUCT.md as a convention. Similar to how CLAUDE.md carries engineering context, PRODUCT.md carries product context. A templates/PRODUCT.md starter template and docs/PRODUCT_OWNER_SETUP.md guide are included.

Implementation

I have a working fork with this fully implemented on top of current upstream main (4 commits, 0 behind yesterday and 16 today 🤦‍♂️ ):

1. product-owner agent definition (agents/review/)
2. Skill integrations (ce:brainstorm, ce:plan, ce:work, ce:compound, ce:review)
3. product-acceptance standalone skill
4. Documentation (setup guide with lifecycle diagram, README updates, PRODUCT.md template)

bun run release:validate passes — 50 agents, 43 skills, in sync.

Happy to open a PR if this aligns with the plugin's direction, or reshape the approach based on feedback.

[tmchow]

Thanks for the proposal.

We have #614 which is introducing ce-strategy and ce-product-pulse soon.

The result will be:

ce-strategy -> writes docs/strategy.md as the upstream anchor
ce-ideate / ce-brainstorm / ce-plan -> read it as grounding
ce-product-pulse -> closes the loop with outcome/usage signal

That makes a separate PRODUCT.md + product-owner concept feel duplicative. I wouldn't want to introduce 2 product canon files (docs/strategy.md vs PRODUCT.md) or two PM-ish abstractions. That is exactly how ceremony creeps in: every workflow starts reading one more doc, asking one more “alignment” question, and nobody knows which product artifact wins.