Back to Details

product-operations

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product Operations

产品运营（Product Ops）

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
    )
涵盖内容
  • 定义明确责任范围、边界及“协作方式”的Product Ops章程
  • 构建助力产品经理（PM）高效工作的体系：运作节奏、标准化工件及决策支持（非决策制定）
  • 搭建跨职能协作接口（产品 ↔ 运营/销售/客户成功/研发/数据/客服），减少协作摩擦与意外情况
  • 建立洞察流程（定性+定量），确保产品团队在正确的时间获取正确的信号
  • 落地发布与赋能体系：发布就绪检查、内部沟通、培训及反馈闭环
适用场景
  • “我们需要搭建Product Ops——明确其定位与权责范围。”
  • “我们的产品团队正在扩张；需要标准化的路线图/同步会及更清晰的运作节奏。”
  • “产品经理深陷协调工作无法自拔；需要搭建一套体系来降低协作成本。”
  • “创建一套发布赋能流程（就绪检查、沟通、培训、反馈）。”
  • “我们需要一套跨产品/客户成功/销售的可复用洞察→决策流程。”
不适用场景
  • 你需要决定“要构建什么”（请使用
    prioritizing-roadmap
    / 
    defining-product-vision
    ）
  • 你需要从零开始定义指标/OKR（请使用
    writing-north-star-metrics
    / 
    setting-okrs-goals
    ）
  • 你需要撰写可用于决策的PRD（请使用
    writing-prds
    ）或可用于研发的规格文档（请使用
    writing-specs-designs
    ）
  • 你需要开展深度客户调研、访谈或可用性测试（请使用
    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.
必填信息
  • 产品团队背景：发展阶段、团队架构、核心协作痛点（“规模化过程中遇到哪些问题？”）
  • 当前规划/发布节奏（若有）：路线图/OKR周期、发布流程、沟通触点
  • 核心利益相关方：产品/研发/数据/运营/销售/客户成功/客服 + 决策负责人
  • 期望成果：Product Ops落地后，哪些环节应变得更简单/高效/清晰
  • 约束条件：合规/隐私要求、工具限制、资源配置、时间节点
缺失信息处理策略
  • 可从references/INTAKE.md中选取最多5个问题进行询问。
  • 若无法获取答案，基于明确假设推进工作，并标注未知信息。

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
产出一套Markdown格式的Product Ops操作系统包（可在对话中直接输出；若用户要求，也可作为文件交付）：
  1. Product Ops章程（使命、范围、非目标、成功指标）
  2. 运营模式（协作模式、RACI权责矩阵、嵌入式 vs 集中式架构）
  3. 运作节奏与例行机制（关键评审/同步会的日历安排，含议程与输出要求）
  4. 标准化工件集（路线图更新、决策日志、产品更新、发布赋能等模板）
  5. 洞察流程（数据来源、分类体系、收集/分流机制、仪表盘、反馈闭环）
  6. 发布赋能体系（就绪检查清单、沟通计划、培训方案、发布后信息收集机制）
  7. 30/60/90天实施计划（试点、推广、度量、迭代）
  8. 风险/待解决问题/下一步行动（必填项）
模板参考：references/TEMPLATES.md
扩展指引：references/WORKFLOW.md

Workflow (8 steps)

工作流程（8步）

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

1) 需求收集与问题梳理（规模化过程中遇到哪些痛点？）

  • 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>.”
  • 输入信息：用户需求；references/INTAKE.md
  • 行动：明确团队发展阶段、Top3协作痛点、利益相关方、现有运作节奏及期望成果
  • 输出：背景快照 + 待解决核心问题（已排序）
  • 校验：需能用一句话总结问题：“Product Ops的存在是为了减少<协作摩擦>，提升<团队成果>，服务于<目标团队>。”

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

2) 定义Product Ops章程（边界与成功标准）

  • 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.
  • 输入信息：背景快照；约束条件；利益相关方
  • 行动：起草使命、范围、非目标及成功指标。需明确说明：Product Ops仅提供决策支持；产品经理保留最终决策权
  • 输出：Product Ops章程（v1版本）
  • 校验：章程需明确回答：权责范围、非权责范围、协作方式及价值度量标准

3) Map interfaces + ownership (make collaboration explicit)

3) 映射跨职能接口与权责（明确协作规则）

  • 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.
  • 输入信息：现有工作流程；利益相关方图谱
  • 行动：梳理跨职能协作接口（产品 ↔ 研发/数据/运营/销售/客户成功/客服），定义规划、发布、沟通、洞察环节的RACI权责矩阵与“决策主体”
  • 输出：运营模式草案 + RACI权责矩阵
  • 校验：无“模糊权责”——所有重复决策/工件均有明确负责人与升级路径

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

4) 设计运作节奏（产出明确成果的例行机制）

  • 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.
  • 输入信息：章程；RACI矩阵；现有日历安排
  • 行动：定义最小化运作节奏集合（周/双周/月/季度），含议程、参会人员及必填输出
  • 输出：运作节奏日历 + 会议输出规范
  • 校验：每个例行机制均需产出具体工件/更新；仅为“开会而开会”的环节需被移除或重构

5) Standardize artifacts (make product work legible)

5) 标准化工件（让产品工作可被清晰感知）

  • 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)

6) 搭建洞察流程（正确信号→正确决策场景）

  • 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)

7) 落地发布与赋能体系（发布就绪系统）

  • 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)

8) 实施与迭代（试点→推广→度量）

  • 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).
  • 输入信息：完整草案包；资源配置；时间节点
  • 行动：制定30/60/90天计划，选择试点区域，运行2-4个周期的运作节奏，收集反馈并调整
  • 输出：30/60/90天计划 + 度量计划 + 迭代待办清单
  • 校验：需至少设定1项可度量的改进目标（如周期时间缩短、利益相关方满意度提升、意外情况减少、产品经理协作成本降低）

Quality gate (required)

质量校验门（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 参考references/CHECKLISTS.md及references/RUBRIC.md进行校验。
  • 必须包含：风险、待解决问题、下一步行动。

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.
示例1（团队规模化）：“我们的PM团队从6人扩张到18人，现在协作混乱。请搭建Product Ops运作节奏、标准化路线图更新机制及洞察流程。”
预期输出：章程 + 运作节奏 + 模板 + 30/60/90天推广计划。
示例2（发布与赋能）：“我们的产品发布总是让客服和销售措手不及。请创建一套包含就绪检查与沟通工作流的发布赋能体系。”
预期输出：发布等级划分 + 就绪检查清单 + 赋能包模板 + 发布后信息收集闭环。
边界示例：“决定下季度我们应优先推进哪些项目。”
回应：请先使用
prioritizing-roadmap
；之后可运用本技能将选定的计划落地执行。