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 (usewriting-specs-designs) - You need deep customer discovery, interviews, or usability testing (use
conducting-user-interviews/usability-testing)
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):
- Product Ops charter (mission, scope, non-goals, success metrics)
- Operating model (engagement model, RACI/ownership, embedded vs centralized approach)
- Cadences + rituals (calendar of key reviews/check-ins with agendas + outputs)
- Standard artifact set (templates for roadmap updates, decision logs, product updates, launch enablement)
- Insights pipeline (sources, taxonomy, intake/triage, dashboards, feedback loops)
- Release enablement system (readiness checklist, comms plan, training, post-launch capture)
- 30/60/90 implementation plan (pilot, rollout, measurement, iteration)
- 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 and improve for.”
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).
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: “Decide which initiatives we should prioritize next quarter.” Response: use prioritizing-roadmap first; then apply this skill to operationalize the chosen plan.