Product capability

Product capability

A spec answers "what should we build?" — this answers "what exactly must be true before implementation starts?" It's the layer between PRD and engineering execution, and it's where hidden assumptions surface.

Use this after /role-pm:spec-draft is directionally approved, before engineering invests real hours. If used in the other order, engineering discovers the blockers at implementation time, which is the most expensive place to find them.

Four phases

1. Restate

One precise statement of the capability. No marketing language, no aspiration — just what this is.

Good: "The capability lets an authenticated user upload a PDF up to 50 MB, have it processed asynchronously, and download a structured JSON extraction within 10 minutes."

Bad: "An AI-powered document intelligence feature that empowers users to unlock insights from their documents."

2. Resolve constraints

Surface every constraint that must hold before or during implementation. Each constraint either has a documented resolution or becomes an open question the spec owner must resolve before engineering starts.

Categories to check:

• Business rules — what's allowed, what's forbidden, rate limits, tier restrictions
• Scope boundaries — what this is NOT (reiterate the non-goals from the spec in constraint form)
• Data ownership — who creates, owns, transitions, archives, deletes each data entity
• Lifecycle transitions — states and the events that move between them
• Security — authN, authZ, data classification, audit logging, encryption at rest / in transit
• Billing / policy — does this affect pricing tiers? usage limits? compliance posture?
• Dependencies — external services, internal capabilities, third-party SDKs
• Performance SLOs — latency, throughput, availability targets

For each constraint, write: what it is → why → how it must be satisfied. If the "how" is unknown, it becomes an open question.

3. Define the implementation contract

The interface engineering will build against. Not implementation — contract.

Include:

• Inputs — what goes in, from where, with what validation
• Outputs — what comes out, in what shape, with what guarantees
• Error modes — what can fail, how failures surface, what the caller does
• Invariants — statements that must always be true (e.g. "a user never sees another user's extraction")
• State machine — if the capability has states, the states and transitions, explicitly

This section is the answer to "what do we need to agree on before writing code?"

4. Translate to execution

Hand off notes:

• Non-goals (reconfirmed) — things engineering should NOT build even if tempted
• Open questions blocking implementation — each with an owner and a by-when
• Next step — usually /team-core:task-breakdown or /role-pgm:project-planner depending on size

Output

# Capability: <name>

**Spec link:** <Notion PRD>
**Owner:** <PM>
**Status:** Ready for engineering review | Open questions blocking

## Capability statement (one sentence)
<precise restatement>

## Constraints

### Business rules
- <rule> — why — how satisfied
- ...

### Scope boundaries (non-goals)
- This does NOT <X>
- This does NOT <Y>

### Data
- <entity> — owner — lifecycle (created → ... → archived)
- ...

### Security
- <constraint> — how satisfied
- ...

### Performance SLOs
- <SLO> — target — measured how

### Dependencies
- <dependency> — owner — risk

## Implementation contract

### Inputs
- <input> — from — validation rules

### Outputs
- <output> — shape — guarantees

### Error modes
- <error> — trigger — caller action

### Invariants
- <invariant that must always hold>

### State machine (if applicable)
<states and transitions>

## Non-goals (reconfirmed)
- <non-goal>

## Open questions blocking implementation
- [ ] <question> — owner: <person> — needed by: <date>

## Next step
<task-breakdown | project-planner | revise spec>

When not to use

• If there's no spec yet, start with /role-pm:spec-draft. This skill translates a spec, doesn't replace it.
• If the capability is tiny (single file, single team, no cross-cutting concerns), this is overkill — go straight to /team-core:task-breakdown.
• If the spec is still directionally unclear, go up a level to /role-pm:product-lens diagnostic or /role-ceo:office-hours.

Don't

• Don't paste the PRD here. Restate in capability language.
• Don't soften open questions into "considerations." If it blocks implementation, it's a blocker — name it that way.
• Don't skip the state machine if the capability has states. State machines hide the bugs that appear at implementation time.
• Don't list constraints you didn't verify. If security/billing/performance requirements come from another team, link to their source rather than guessing.

---

Methodology inspired by the Affaan M "product-capability" skill.