product-operations-and-governance

Product Operations and Governance

Define and operate the recurring product governance system: who decides what, with what evidence, on what cadence, and what happens when decisions are contested or evidence is missing. This skill owns the product-level operating model — the connective tissue between product strategy, portfolio choices, experimentation, adoption, and lifecycle learning. It does not own executive governance or technical delivery gates.

Governance Boundary (Read First)

This skill owns product governance: the recurring system for intake, portfolio review, roadmap decisions, experiment review, launch decisions, and lifecycle/health review. Product governance answers: what are we building, in what order, with what evidence, reviewed by whom, on what cadence?

This skill explicitly does not own:

• Executive governance — capital allocation, org structure, strategic bets at the company level, M&A evaluation. Route to chief-of-staff-methodology for decision-memo and executive-office methods, and strategy-frameworks for strategic planning frameworks.
• Technical delivery gates — CI/CD pipelines, release approval workflows, deployment checklists, infrastructure change review. Route to release-engineering for release mechanics and spec-driven-development for specification-phase gates.

The three governance layers — product, executive, and delivery — are distinct. A product governance decision ("approve this experiment to proceed to launch review") is not an executive decision ("allocate $2M to the payments platform") and not a delivery gate ("the deployment pipeline must pass integration tests"). See references/discovery-brief.md for the full boundary analysis.

Core Framework

Two Operating Modes

This skill supports two modes; choose one explicitly for every engagement. The mode determines evidence requirements, review formality, and escalation thresholds.

The mode is a configuration choice, not a maturity level. A startup building a non-regulated consumer app operates in lightweight mode. A medical-device team of 8 operates in high-assurance mode. A 200-person platform team may operate parts of its portfolio in lightweight mode and parts in high-assurance.

Configurable Governance Patterns

No single org chart or governance model is imposed. The skill provides configurable patterns; select and adapt:

Every pattern requires the same outputs: a decision-rights map, review cadences with evidence standards, and escalation paths. Use templates/operating-model.md to capture the selected pattern and configuration.

Decision Rights

A decision-rights map answers five questions for every decision type:

1. Who decides? Named role (not "engineering" or "leadership" — a specific accountable owner).
2. Who must be consulted? Roles or individuals whose input is required before the decision.
3. Who must be informed? Roles or individuals who are notified after the decision.
4. What evidence is required? The minimum evidence standard for this decision type (varies by mode).
5. What is the escalation path? Who resolves it when the accountable owner cannot decide or the decision is contested.

Decision types the skill covers:

Use templates/decision-rights-map.md to document the map for a specific product or portfolio.

Review Cadences

Six recurring reviews form the product governance rhythm. Each review has a defined purpose, participants, inputs, outputs, and decision authority.

Use templates/review-cadence.md to configure cadences for a specific operating model. Routes to product-roadmapping-and-portfolio for roadmap review mechanics, product-experimentation for experiment review methods, and product-lifecycle-learning (prose — same-wave skill, directory not yet created) for lifecycle/health review evidence.

Evidence Standards

Every decision type has a minimum evidence standard. The standard scales with the operating mode. Evidence is classified into four categories in every artifact:

• Observed — measured, verified, reproducible data.
• Inferred — conclusion from observed data with stated assumptions and confidence.
• Asserted — stakeholder claim not yet verified; treated as an assumption.
• Committed — a decision with consequences for reversal; recorded with accountable owner and revisit trigger.

Missing required evidence is not a reason to skip a review — it is a reason to escalate. A review that proceeds without required evidence must produce an exception record, not silent approval.

Exceptions and Escalations

Exception Record

When a governance requirement is waived or deferred, record the exception. Without a record, the exception becomes the new default.

Fields: what was excepted, why, who approved, date approved, when to revisit (specific date or trigger condition), and what evidence (if any) substitutes for the waived requirement.

Use templates/exception-record.md.

Escalation Record

When a decision cannot be resolved at its designated level — because evidence is missing, stakeholders are deadlocked, or the accountable owner cannot decide — escalate. Escalation is not failure; it is the governance system working as designed.

Fields: what was escalated, to whom, why the lower level could not resolve, resolution, date resolved, and closure evidence.

Use templates/escalation-record.md.

Loading Guide

Load only the file relevant to the current task. Do not load everything at once.

Working Method

1. Select the operating mode

Start every engagement by choosing lightweight or high-assurance mode. Do not default to one. Ask: is this product regulated, safety-critical, or subject to external compliance obligations? If yes, high-assurance. If the team is small and the product is non-regulated, lightweight.

2. Choose the governance pattern

Select from single accountable owner, product council, tiered review, or delegated authority with escalation. Adapt, don't copy. Document the choice in the operating model template.

3. Map decision rights

For every decision type in scope, fill the decision-rights map: who decides, who is consulted, who is informed, what evidence is required, and where to escalate. Use templates/decision-rights-map.md.

4. Configure review cadences

Set the purpose, participants, inputs, outputs, and decision authority for each review. Adjust frequency to match the operating mode. Use templates/review-cadence.md.

5. Establish evidence standards

Define the minimum evidence standard per decision type, scaled to the operating mode. Record the standard in the decision-rights map. Evidence standards are not aspirational — they gate the decision.

6. Record exceptions and escalations

Every exception and escalation gets a dated record with accountable owner and revisit trigger. Exception records prevent waiver-by-neglect. Escalation records make the governance system observable and improvable.

Routing Table

When Not to Use

Do not load this skill for:

• Executive governance. Capital allocation, org structure decisions, strategic bets at the company level, or M&A evaluation — route to chief-of-staff-methodology or strategy-frameworks.
• Technical delivery gates. CI/CD pipelines, release approval workflows, deployment checklists, or infrastructure change review — route to release-engineering or spec-driven-development.
• Imposing a universal org chart. The governance patterns are configurable templates, not a mandated structure. If the ask is to design an org chart from scratch, this skill is the wrong tool.
• Single decisions without a recurring system. If you need to make one decision (not design the system for making decisions over time), use product-methodology for decision logs or adr-authoring for architecture decisions.