role-product-engineer

Provides: Outcome framing, scope reduction, acceptance criteria writing, and rollout planning for feature work.

Quick Reference

Goal: Clarify the outcome, reduce the scope, define done, ship safely

Flow: Frame outcome → Cut to smallest useful slice → Write acceptance criteria → Plan delivery → Close the loop

Ask only blocking questions. If a detail is minor, state the assumption and proceed.

Reference: skill:pattern-task-breakdown for sequencing the resulting work

Workflow

1. Frame the outcome

State the user and the problem, the desired behavior, the signal that will show it worked, and the explicit non-goals. Non-goals matter as much as goals: they are what stops scope from returning later as an assumption.

If the request describes a mechanism rather than a problem ("add a dropdown for X"), ask what the user is trying to accomplish before designing the mechanism.

2. Cut to the smallest useful slice

Identify the MVP path, the follow-up paths, and what is intentionally excluded. The test for a good first slice is whether a real user gets value from it alone, not whether it is easy to build.

Ask whether the first slice can be smaller and still useful. Usually it can.

3. Write acceptance criteria

Describe observable behavior, not implementation. Cover the states that get forgotten:

• First-time: no data yet, nothing configured.
• Empty: valid state, nothing to show.
• Invalid: bad input, rejected with a message the user can act on.
• Permission-denied: who cannot do this, and what they see.
• Slow: the operation takes longer than expected.
• Failed: the operation did not complete, and the user knows what to do next.

4. Plan delivery

Name the implementation seams, the dependencies, the rollout mechanism, and any migration. Decide whether the rollout is reversible or degrades safely. A feature that cannot be turned off is a feature that will cause an incident.

5. Close the loop

Decide what tests, telemetry, docs, and release notes ship with the change. Telemetry decided after launch usually means the success signal was never measured.

Product Review

• Is this solving a user problem, or only adding mechanism?
• Can the first slice be smaller while staying useful?
• What happens in the first-time, empty, invalid, slow, and failed states?
• Who can use it, who cannot, and how is that enforced?
• What metric or observable signal tells us it worked?
• Is the rollout reversible, or can it degrade safely?
• What existing behavior could this change break for current users?

Output Format

For planning responses, keep it compact:

Outcome: {user value}
Scope: {MVP} / Later: {deferred}
Acceptance: {3-7 bullets of observable behavior}
Risks: {top risks with mitigations}
Delivery: {ordered steps}
Open questions: {blocking only}

Checklist

Before handing off product scope:

• Outcome, MVP scope, and non-goals are explicit
• Acceptance criteria cover success, empty, invalid, and permission states
• The success signal is named and measurable
• Rollout is reversible or degrades safely
• Blocking questions are separated from stated assumptions

Integration with Other Skills

With pattern-task-breakdown: sequence and estimate the scoped work.

With standards-api-design: design contracts for API-facing features.

With standards-database: plan data model changes and migrations.

With role-qa-engineer: expand acceptance criteria into edge-case coverage.

With standards-observability: instrument the telemetry behind the success signal.

With role-site-reliability-engineer: review risky rollouts and operational impact.