Product Operations

Scope

Covers

• Defining a Product Ops charter that clarifies accountability, boundaries, and “how we work”
• Building systems that help PMs thrive: cadences, standardized artifacts, and decision support (not decision-making)
• Creating cross-functional interfaces (Product ↔ Ops/Sales/CS/Eng/Data/Support) to reduce friction and surprises
• Standing up an insights pipeline (qual + quant) so product teams get the right signals at the right time
• Operationalizing shipping + enablement: release readiness, internal comms, training, and feedback loops

When to use

• “We need Product Ops—define what it is here and what it owns.”
• “Our product team is scaling; we need standard roadmaps/check-ins and better operating cadence.”
• “PMs are drowning in coordination; set up a system to reduce overhead.”
• “Create a release enablement process (readiness, comms, training, feedback).”
• “We need a repeatable insights → decisions pipeline across Product/CS/Sales.”

When NOT to use

• You need to choose what to build (use prioritizing-roadmap / defining-product-vision)
• You need to define metrics/OKRs from scratch (use writing-north-star-metrics / setting-okrs-goals)
• You need to write a decision-ready PRD (use writing-prds) or build-ready spec (use writing-specs-designs)
• You need deep customer discovery, interviews, or usability testing (use conducting-user-interviews / usability-testing)
• You need to design a single team's rituals (standup, retro, planning) rather than an org-wide operating system (use team-rituals)
• You need to improve one specific meeting's format and facilitation (use running-effective-meetings)
• You need to plan and execute a specific product launch (use shipping-products)

Inputs

Minimum required

• Product org context: stage, team shape, main frictions (“what’s breaking at scale?”)
• Current planning/shipping rhythm (if any): roadmap/OKR cadence, release process, comms touchpoints
• Primary stakeholders: Product/Eng/Data/Ops/Sales/CS/Support + decision owners
• Desired outcomes: what should be easier/faster/clearer after Product Ops exists
• Constraints: compliance/privacy, tooling limits, resourcing, timelines

Missing-info strategy

• Ask up to 5 questions from references/INTAKE.md.
• If answers aren’t available, proceed with explicit assumptions and label unknowns.

Outputs (deliverables)

Produce a Product Ops Operating System Pack in Markdown (in-chat; or as files if the user requests):

1. Product Ops charter (mission, scope, non-goals, success metrics)
2. Operating model (engagement model, RACI/ownership, embedded vs centralized approach)
3. Cadences + rituals (calendar of key reviews/check-ins with agendas + outputs)
4. Standard artifact set (templates for roadmap updates, decision logs, product updates, launch enablement)
5. Insights pipeline (sources, taxonomy, intake/triage, dashboards, feedback loops)
6. Release enablement system (readiness checklist, comms plan, training, post-launch capture)
7. 30/60/90 implementation plan (pilot, rollout, measurement, iteration)
8. Risks / Open questions / Next steps (always included)

Templates: references/TEMPLATES.md
Expanded guidance: references/WORKFLOW.md

Workflow (8 steps)

1) Intake + problem framing (what’s breaking at scale?)

• Inputs: User request; references/INTAKE.md.
• Actions: Clarify: org stage, top 3 friction points, stakeholders, existing cadences, and desired outcomes.
• Outputs: Context snapshot + top problems to solve (ranked).
• Checks: You can state a 1-sentence problem: “Product Ops exists to reduce <friction> and improve <outcome> for <teams>.”

2) Define the Product Ops charter (boundaries + success)

• Inputs: Context snapshot; constraints; stakeholders.
• Actions: Draft mission, scope, non-goals, and success metrics. Explicitly state: Product Ops informs decisions; PMs keep decision rights.
• Outputs: Product Ops charter (v1).
• Checks: Charter answers: what we own, what we don’t, how to engage, and how we measure value.

3) Map interfaces + ownership (make collaboration explicit)

• Inputs: Current workflow; stakeholder map.
• Actions: Map interfaces (Product ↔ Eng/Data/Ops/Sales/CS/Support). Define RACI and “who decides what” for planning, releases, comms, and insights.
• Outputs: Operating model (draft) + RACI table.
• Checks: No “shadow ownership”: every recurring decision/artifact has a clear owner and escalation path.

4) Design the operating cadence (rituals that produce artifacts)

• Inputs: Charter; RACI; current calendar.
• Actions: Define a minimal cadence set (weekly/biweekly/monthly/quarterly) with agendas, attendees, and required outputs.
• Outputs: Cadence calendar + meeting output spec(s).
• Checks: Each ritual produces a concrete artifact/update; anything that’s “just a meeting” gets removed or redesigned.

5) Standardize artifacts (make product work legible)

• Inputs: Existing docs; stakeholder needs; cadence outputs.
• Actions: Define the standard artifact set (roadmap update, decision log, weekly product update, launch brief, enablement bundle). Provide templates + ownership.
• Outputs: Artifact library + templates list.
• Checks: Artifacts are lightweight, repeatable, and tailored to the audiences that consume them.

6) Build the insights pipeline (right signal → right forum)

• Inputs: Data sources; feedback channels; research process.
• Actions: Create intake/triage, taxonomy, and routing to the right forum (product area owners, planning cycle, release retro). Specify dashboards/recurring reporting.
• Outputs: Insights pipeline spec + backlog triage mechanism.
• Checks: New signal has an owner, a place to land, and a defined “decision path” (no orphan feedback).

7) Operationalize shipping + enablement (release readiness system)

• Inputs: Current release process; artifact set.
• Actions: Define readiness checklist, comms/enablement workflow, and post-launch capture (escapes, support load, learning). Keep it proportionate to release tier.
• Outputs: Release enablement system + checklists + comms template(s).
• Checks: For any release, you can answer: who needs to know, what changes, how we monitor, and how we roll back/mitigate.

8) Implement + iterate (pilot → rollout → measure)

• Inputs: Full draft pack; resourcing; timeline.
• Actions: Create 30/60/90 plan, choose a pilot area, run the cadence for 2–4 cycles, gather feedback, and adjust.
• Outputs: 30/60/90 plan + measurement plan + iteration backlog.
• Checks: At least 1 measurable improvement is targeted (cycle time, stakeholder satisfaction, fewer surprises, less PM overhead).

Anti-patterns (common failure modes)

1. Process for process's sake. Introducing cadences, templates, and review meetings without tying each to a concrete friction point. The team spends more time on process overhead than on the problems it was meant to solve.
2. Shadow decision-making. Product Ops starts making product decisions (prioritization, roadmap calls) instead of supporting PMs. The charter says “inform” but the operating model creates a bottleneck.
3. Template graveyard. Standardizing 15 artifact templates that nobody uses because they don't match real workflows. Adoption fails silently and teams revert to ad-hoc docs.
4. Insights pipeline without routing. Collecting feedback from Sales, CS, and Support into a central repository but never routing it to the right product area owner. Signal accumulates but never drives decisions.
5. Big-bang rollout. Launching the entire Product Ops operating system to all teams simultaneously instead of piloting with one team. Change fatigue causes rejection before value is demonstrated.

Quality gate (required)

• Use references/CHECKLISTS.md and references/RUBRIC.md.
• Always include: Risks, Open questions, Next steps.

Examples

Example 1 (scaling): “We grew from 6 to 18 PMs and things feel chaotic. Set up a Product Ops operating cadence, standardized roadmap updates, and an insights pipeline.” Expected: charter + cadences + templates + 30/60/90 rollout plan.

Example 2 (shipping + enablement): “Our launches surprise Support and Sales. Create a release enablement system with readiness checks and a comms workflow.” Expected: release tiering + readiness checklist + enablement bundle template + post-launch capture loop.

Boundary example (team rituals): “Help us design a better standup and retro for our product squad.” Response: use team-rituals for designing individual team ceremonies; this skill is for org-wide operating systems, not single-team rituals.

Boundary example (single launch): “Plan the rollout for our v2.0 release next month.” Response: use shipping-products for a specific launch; this skill is for building the repeatable release enablement system across launches.

Boundary example (roadmap): “Decide which initiatives we should prioritize next quarter.” Response: use prioritizing-roadmap first; then apply this skill to operationalize the chosen plan.