product-operations

产品运营

范围

涵盖

• 制定产品运营章程，明确责任归属、职责边界和“我们的工作方式”
• 构建帮助 PM 发挥所长的体系：节奏、标准化文档和决策支持（而非代替决策）
• 建立跨职能协作接口（产品 ↔ 运营/销售/客户成功/工程/数据/支持），减少摩擦和意外
• 搭建洞察流水线（定性 + 定量），确保产品团队在恰当时机获得恰当信号
• 将发布 + 赋能流程化：发布准备、内部沟通、培训和反馈闭环

适用场景

• “我们需要产品运营——明确它在这里的定位和职责。”
• “我们的产品团队正在扩张；我们需要标准化路线图/定期沟通，并优化运营节奏。”
• “PM 被协调工作压得喘不过气；建立一套体系来减少额外负担。”
• “创建一个发布赋能流程（准备、沟通、培训、反馈）。”
• “我们需要一条可重复的洞察 → 决策流水线，供产品/客户成功/销售团队使用。”

不适用场景

• 需要决定要构建什么（使用 prioritizing-roadmap / defining-product-vision）
• 需要从头定义指标/OKR（使用 writing-north-star-metrics / setting-okrs-goals）
• 需要编写可用于决策的 PRD（使用 writing-prds）或可用于构建的规格说明（使用 writing-specs-designs）
• 需要深入开展客户探索、访谈或可用性测试（使用 conducting-user-interviews / usability-testing）

输入

最低要求

• 产品组织背景：所处阶段、团队构成、主要摩擦点（“规模扩大后，哪些地方开始出问题？”）
• 当前规划/发布节奏（如有）：路线图/OKR 节奏、发布流程、沟通节点
• 主要利益相关者：产品/工程/数据/运营/销售/客户成功/支持团队 + 决策负责人
• 期望成果：产品运营建立后，哪些事情应该更容易/更快/更清晰
• 约束条件：合规/隐私、工具限制、资源、时间安排

缺少信息时的处理策略

• 从 references/INTAKE.md 中提出最多 5 个问题。
• 如果无法获得答案，基于明确的假设继续推进，并标注未知项。

输出（交付成果）

以 Markdown 形式（在聊天中；或用户要求时以文件形式）生成一份产品运营运营体系包：

1. 产品运营章程（使命、范围、非目标、成功指标）
2. 运营模式（协作模式、RACI/职责归属、嵌入式或集中式方案）
3. 节奏 + 例行活动（关键评审/定期沟通的日历，附议程 + 产出）
4. 标准文档集（路线图更新、决策日志、产品更新、发布赋能模板）
5. 洞察流水线（来源、分类体系、收集/分流、仪表板、反馈闭环）
6. 发布赋能体系（准备情况检查清单、沟通计划、培训、发布后信息收集）
7. 30/60/90 天实施计划（试点、推广、衡量、迭代）
8. 风险 / 待解决问题 / 后续步骤（始终包含）

模板：references/TEMPLATES.md
扩展指南：references/WORKFLOW.md

工作流（8 个步骤）

1) 信息收集 + 问题界定（规模扩大后，哪些地方开始出问题？）

• 输入： 用户请求；references/INTAKE.md。
• 行动： 明确组织阶段、最突出的 3 个摩擦点、利益相关者、现有节奏和期望成果。
• 输出： 背景概览 + 待解决的主要问题（按优先级排序）。
• 检查： 能用一句话描述问题：“产品运营旨在减少 <摩擦>，并为 <团队> 改善 <成果>。”

2) 定义产品运营章程（职责边界 + 成效）

• 输入： 背景概览；约束条件；利益相关者。
• 行动： 起草使命、范围、非目标和成功指标。明确说明：产品运营为决策提供信息；决策权仍由 PM 掌握。
• 输出： 产品运营章程（v1）。
• 检查： 章程需说明：我们负责什么、不负责什么、如何参与，以及如何衡量价值。

3) 梳理接口与职责归属（明确协作方式）

• 输入： 当前工作流；利益相关者图谱。
• 操作： 梳理接口（产品 ↔ 工程/数据/运营/销售/客户成功/支持）。为规划、发布、沟通和洞察定义 RACI，以及“谁决定什么”。
• 输出： 运营模式（草案）+ RACI 表。
• 检查： 不存在“隐性职责归属”：每项定期进行的决策/产出物都有明确的负责人和升级路径。

4) 设计运营节奏（产出具体成果的例行活动）

• 输入： 章程；RACI；当前日历。
• 操作： 定义一套精简的例行活动（每周/每两周/每月/每季度），并明确议程、参会者和必需产出。
• 输出： 运营节奏日历 + 会议产出规范。
• 检查： 每项例行活动都会产出具体成果/更新；任何“只是开会”的活动都要取消或重新设计。

5) 标准化产出物（让产品工作清晰可见）

• 输入： 现有文档；利益相关者需求；例行活动的产出。
• 操作： 定义标准产出物集（路线图更新、决策日志、每周产品动态、发布简报、赋能资料包）。提供模板并明确负责人。
• 输出： 产出物库 + 模板清单。
• 检查： 产出物轻量、可重复使用，并根据使用对象进行定制。

6) 构建洞察管道（将正确的信号送到合适的讨论场合）

• 输入： 数据来源；反馈渠道；研究流程。
• 操作： 创建受理/分流流程、分类体系，以及流转到合适讨论场合的机制（产品领域负责人、规划周期、发布复盘）。明确仪表板/定期报告。
• 输出： 洞察管道规范 + 待办事项分流机制。
• 检查： 每条新信号都有负责人、归属位置和明确的“决策路径”（不遗漏任何反馈）。

7) 将发布与赋能流程化（发布就绪系统）

• 输入： 当前发布流程；产出物集。
• 操作： 定义就绪检查清单、沟通/赋能工作流和发布后信息收集机制（意外问题、支持负载、经验总结）。根据发布等级合理调整工作量。
• 输出： 发布赋能系统 + 检查清单 + 沟通模板。
• 检查： 对于任何一次发布，都能回答：谁需要知晓、有哪些变化、如何监控，以及如何回滚/缓解。

8) 实施并迭代（试点 → 推广 → 衡量）

• 输入： 完整草案包；资源配置；时间表。
• 操作： 制定 30/60/90 天计划，选择试点领域，运行 2–4 个周期，收集反馈并进行调整。
• 输出： 30/60/90 天计划 + 衡量计划 + 迭代待办事项。
• 检查： 至少设定 1 项可衡量的改进目标（周期时间、利益相关者满意度、更少的意外、更少的 PM 管理开销）。

质量门槛（必需）

• 使用 references/CHECKLISTS.md 和 references/RUBRIC.md。
• 始终包含：风险、开放问题、后续步骤。

示例

示例 1（规模扩张）：“我们的 PM 从 6 人增加到 18 人，感觉一团混乱。建立 Product Ops 运营节奏，标准化路线图更新，并搭建洞察管道。”
预期：章程 + 运营节奏 + 模板 + 30/60/90 天推广计划。

示例 2（发布 + 赋能）：“我们的发布总是让支持和销售团队措手不及。建立包含就绪检查和沟通工作流的发布赋能系统。”
预期：发布分级 + 就绪检查清单 + 赋能资料包模板 + 发布后信息收集闭环。

边界示例：“决定下季度应该优先推进哪些计划。”
答复：先使用 prioritizing-roadmap；然后应用此技能，将选定计划流程化。