ClawHub

Product Dev Ops Playbook — 10-Day Sprint & Cross-Team Alignment SOP

Dev Tools

🇺🇸 Your dev team ships features nobody asked for while user-reported bugs pile up for months. Operations blames engineering for ignoring users; engineering blames operations for not understanding technical constraints. This gives you the complete Product × Engineering × Operations alignment SOP — from unified backlog to 10-day sprint cadence to veto power rules. What's inside: • Dual-layer Kanban system (master backlog + sprint board with unified tagging) • 10-day sprint standard process (Day 1 dev → Day 6 testable build → Day 10 ship) • Issue template with reproducibility requirements (3x reported = auto-severe) • Tri-party alignment meetings (daily standup / sprint planning / sprint review) • Operations veto power on releases (P0 bug = block shipping) • User feedback → product iteration closed loop (beta testing + interview SOP) • Core metrics framework (acquisition → activation → retention → monetization → referral) • Technical debt management (20-30% sprint capacity reserved) • Ready-to-use templates: Bug Report, Sprint Planning, Responsibility Matrix Built from: Real product strategy meetings + beta testing frameworks. References Supabase sprint model, Manus/DeepSeek commercialization alignment. By @WeiYipei. 🇨🇳 你的研发团队在做没人要的新功能，用户反馈的 Bug 堆了三个月没人动。运营觉得研发不听用户，研发觉得运营不懂技术。这份 SOP 给你从统一看板到 10 天迭代节奏到一票否决权的完整产研运协同框架。 🇯🇵 開発チームは誰も求めていない機能を作り、ユーザーから報告されたバグは何ヶ月も放置。このSOPは、統一バックログから10日スプリント、リリース拒否権まで、プロダクト×エンジニアリング×オペレーションの完全な連携フレームワークを提供します。 🇰🇷 개발팀은 아무도 요청하지 않은 기능을 만들고, 사용자가 보고한 버그는 몇 달째 방치됩니다. 이 SOP는 통합 백로그부터 10일 스프린트, 릴리스 거부권까지 제품×개발×운영 완전 협업 프레임워크를 제공합니다. Triggers: "product ops" | "engineering operations" | "product development SOP" | "sprint planning" | "iteration management" | "cross-functional alignment" | "product engineering ops" | "dev ops collaboration" | "产研运协同" | "迭代管理" | "产品研发运营" | "プロダクト開発運営" | "제품개발운영"

Install

openclaw skills install product-dev-ops-playbook

🌍 Language / 语言: 中文 | English | 日本語 | 한국어

📦 Install

clawhub install product-dev-ops-playbook

What you get after installing:

  • Complete 10-day sprint cadence with tri-party alignment checkpoints
  • Issue template + severity auto-escalation rules (3x reported = must-fix)
  • Ready-to-use meeting templates for sprint planning, review, and daily standups

产品研发 × 运营协同 SOP

本 SOP 整合一场真实产品战略会议纪要、用户反馈录入模板、内测用户访谈体系，提炼出一套产品、研发、运营三方协同的通用工作框架。

核心原则： 一切面向商业化服务。一切为赚钱服务。

使用说明： 本文档为通用模板，将所有 [产品名称] / [项目代号] / [系统名称] 替换为对应信息即可直接使用。

一、核心问题诊断：为什么产研运总是协同不好？

1.1 几乎所有成长期产品都会遇到的三个矛盾

矛盾表现本质原因
新功能 vs 用户反馈开发团队总在追新功能，用户反馈的小 Bug 被无限搁置没有统一的优先级决策机制
研发想做什么 vs 运营要什么研发觉得运营不懂技术，运营觉得研发不听用户缺少共同目标
快 vs 稳产品形态还没稳定就急着增长，技术债越积越多没有明确的产品阶段判断

1.2 解决思路

来自真实会议洞察： 商业化变现做得好的公司（如 Manus、DeepSeek），COO 或运营负责人直接为商业化服务，产研运三方高度协同。

四大核心机制：

#机制说明
1统一看板用户反馈和产品需求进同一个池子，用同一套标签体系
2共同目标每次迭代有明确的商业化指标（如"注册→付费转化率从 4.5% → 7%"）
3运营有一票否决权直接伤害用户体验或付费转化的问题，运营可以直接提议推迟发版
4每个迭代前三方对齐产研运负责人共同决定做什么、哪些先做、哪些放下一期

二、统一协作载体：看板体系设计

2.1 两层看板结构

来自真实经验： 不要只有每个迭代的小看板，一定要有总看板。所有原始 Issue 先进总池子，再流向下游各个迭代。

层级名称内容负责人
第一层：总需求池[产品名称] 总 backlog所有来源的原始 Issue（用户反馈/竞品分析/战略需求）产品负责人
第二层：迭代看板[版本号] - [目标描述]本次迭代确认要做的需求 + 必须修的 Bug迭代 owner

流向逻辑：

总需求池（所有来源的 Issue）
    ↓ 经过评审，认为可以形成方案
形成方案的需求
    ↓ 经过排期会议决策
进入某个迭代的项目
    ↓ 迭代内开发
发布上线 / 回滚到需求池 / 延到下一期

2.2 Issue 录入模板（通用格式）

关键原则： 运营提的每个 Issue 必须包含可复现信息，否则研发无法 fix。

字段说明示例
Issue 标题简明描述问题"iOS 版本排盘结果与 Android 不一致"
来源渠道用户反馈 / 竞品 / 战略用户反馈
反馈次数同一问题被反馈几次3次以上 → 打严重标签
系统/平台Web / iOS / Android / Self-hostiOS
版本号具体版本v2.3.1
复现步骤能复现才能修1. 打开合盘 2. 选择XX 3. 查看结果
预期行为用户期望是什么两版排盘结果应一致
实际行为当前实际表现iOS 显示顺序与 Android 相反
截图/录屏附上证据[附件]
影响评估对体验/付费的影响导致1名用户申请退款
标签Bug / Feature Request / UX优化Bug
优先级建议运营侧判断（高/中/低）高

运营侧特殊规则： 同一 Issue 被反馈 3 次以上，自动打 severe 标签，必须在最近一个迭代中解决。

2.3 Bug 与 Feature Request 分流处理

类型定义处理方式
Bug现有功能行为与预期不符直接进入 Bug 看板，研发评估工时后修复
Feature Request用户需要新功能进入总需求池，产品出方案后才能进入迭代
UX优化不影响核心功能，但影响体验与 Bug 同级，运营可以推动优先级

三、迭代节奏设计

3.1 迭代周期选择

产品阶段推荐迭代周期说明
早期 PMF 验证1-2 周快节奏，快速试错
增长期3-4 周平衡速度与稳定性
稳定期6-8 周稳定性优先，可以做大版本

⚠️ 提醒： 现代 Web 开发节奏下建议压缩到 10 天~2 周。过长的迭代周期会导致团队失去紧迫感。

3.2 10 天迭代标准流程

天次研发动作运营动作产出物
第 1 天开始开发——
第 6 天提交可测试版本领取测试版本，半天内测完测试报告（Bug 列表 + 优先级）
第 7 天根据优先级修复 P0/P1运营×研发对齐会（20-30 分钟）本迭代范围确认
第 8 天继续修复 + 出第二测试版第二轮测试（如有必要）—
第 9 天最终修复准备发布物料（截图/官网/社媒）物料就绪
第 10 天发布上线同步发布内容到各渠道发布完成

3.3 发布节奏红线

来自真实教训： 绝对不要在周五或周末发版。

四、三方对齐会议机制

4.1 日常站会（每日，15 分钟）

参与人： 产品 / 研发 / 运营全体

  • 站着开，限时 15 分钟以内
  • 每人只说三件事：①昨天做了什么 ②今天在做什么 ③有没有 blocker
  • 运营侧必须通报：昨日用户投诉热点、新发现的高频 Bug
  • 超过 1 小时的会一定有人摸鱼

4.2 迭代规划会（每迭代开始，30-60 分钟）

参与人： 产研运三方负责人

议题1：复盘上一迭代（20分钟）
  - 核心指标完成情况（对比目标）
  - 有哪些没做完？为什么？
  - 用户反馈集中在哪里？

议题2：本迭代目标设定（20分钟）
  - 运营侧：本迭代最需要解决的问题（关联商业化目标）
  - 产品侧：本迭代主推的新功能/优化
  - 研发侧：技术债/重构需求
  - 共同决策：本迭代的 Top 3 目标

议题3：资源与排期确认（20分钟）
  - 各方投入多少人天？
  - 哪些功能确定进迭代？哪些 hold？
  - 是否有模块需要重构？

4.3 迭代验收会（每迭代结束，30 分钟）

核心问题：

  1. 本迭代的目标指标达成情况？
  2. 有哪些 P0 Bug 没修完？是否影响发版？
  3. 哪些功能决定推迟到下个迭代？
  4. 下个迭代的运营重点是什么？

4.4 会议频率总览

会议频率时长目的
每日站会每天15 分钟同步进度，发现 blocker
迭代规划会每迭代开始30-60 分钟决定这个迭代做什么
迭代验收会每迭代结束30 分钟复盘 + 为下个迭代做准备
月度 Review每月60-90 分钟核心指标复盘 + 方向调整

五、运营侧在协同中的角色

5.1 运营是用户和研发之间的"翻译官"

职责具体动作频率
用户声音收集整理用户反馈，提炼高频问题，归类 Bug / Feature每日
Bug 初筛确认每个 Issue 可复现，补充复现步骤每日
优先级建议站在用户体验和商业化角度打优先级每迭代
版本验收测试第 6 天开始，半天内测完并出报告每迭代
发布物料准备App Store 更新、官网更新、社媒发布内容每迭代

5.2 运营对发版的一票否决权

触发条件： 如果上线前发现影响用户体验或付费转化的 P0 Bug 未修复，运营可以提议推迟发版。

P0 Bug 标准（运营侧判断）：

Bug 类型例子是否 P0
付费相关支付失败、重复扣款✅ P0
核心功能不可用无法注册、无法生成结果✅ P0
数据错误排盘结果与其他平台不一致✅ P0
界面错乱但功能可用按钮位置偏移⚠️ P1
文案/翻译错误英文拼写错误❌ P2

六、用户反馈驱动产品迭代

6.1 反馈→优化闭环

用户使用产品 → 产生问题/建议
        ↓
运营收集（整理/分类/初筛）
        ↓
录入 Issue 到总看板（附复现步骤）
        ↓
同一问题被反馈3次以上 → 打 severe 标签
        ↓
每迭代规划会重点讨论 severe 项
        ↓
进入迭代开发
        ↓
上线后运营验证问题是否解决
        ↓
通知用户问题已修复（增强被重视感）

6.2 内测用户访谈机制

阶段时间动作负责人
用户筛选内测前 1 周从活跃用户中筛选 10-15 人运营
测试账号发放内测前 3 天发放测试账号 + 积分运营
用户自测内测期间基于真实需求使用产品用户
深度访谈内测期间30-40 分钟/场运营
每日汇总每日结束后整理高频 Bug + 核心需求运营
周维度 Review每周判断是否适合发布产研运共同

访谈结构（30-40 分钟）：

时间模块核心问题
5 分钟用户背景当前做什么？用什么工具？最大问题？
20 分钟产品测试复盘哪步最顺？哪步最卡？有没有 Bug？
10 分钟优化建议最希望优先优化什么？
5 分钟收尾确认是否愿意继续参与？愿意推荐吗？

核心原则： 不讨论抽象感受，只讨论真实使用过程。

七、核心指标体系

7.1 每个迭代的目标指标模板

本迭代目标：[具体描述]
- 起始值：XX%
- 目标值：XX%
- 验证方式：[数据来源/查询方式]
- 负责人：产品/运营/研发

7.2 商业化核心链路指标

阶段指标说明
获取新增注册用户数按渠道拆分（自然/社媒/投放/KOL）
激活Onboarding 完成率分模块看：信息输入/功能体验/得到结果
留存次日/7日/30日留存率按用户来源拆分
付费注册→付费转化率按渠道/用户属性拆分
推荐K 因子（NPS/推荐意愿）邀请机制参与率

7.3 迭代健康度自检

检查项健康值预警信号
P0 Bug 平均修复时长≤2 天> 3 天
功能按时上线率≥80%<60%
用户反馈平均响应时长≤24 小时> 48 小时
同一 Bug 重复反馈次数≤2 次≥3 次
测试报告提交及时率100% 在 Day 6.5 前超过半天

八、技术债与产品重构管理

8.1 触发重构的信号

信号说明
同一模块 Bug 反复出现（≥5 个相关 Issue）模块设计有根本性问题
新功能开发成本越来越高底层架构限制了扩展性
多端数据不一致实体抽象不统一
技术选型已过时需要升级技术栈

8.2 资源分配建议

类型建议占比说明
新功能开发50-60%直接服务商业化目标
Bug 修复20-30%保障基础体验
技术债/重构20-30%保障长期可持续性

8.3 重构类需求处理

  • 重构类需求单独建 Project，周期 1-3 个月
  • 重构期间不影响正常迭代发版（两套体系并行）
  • 重构完成后需要完整的回归测试（建议 3-5 名核心用户参与）

九、阶段性重点

阶段重点说明
冷启动期（<PMF）跑通协同流程2-3 个迭代把流程跑通，深度访谈 20-30 名用户
增长前期明确核心指标Onboarding 完成率 / 转化率 / 留存曲线
快速增长期提升研发效率压缩迭代到 10 天，建立 in-house 增长团队

十、工具推荐

用途工具说明
项目管理Linear / Jira / 飞书多维表格所有 Issue 统一入口
数据分析PostHog / Amplitude / Mixpanel核心链路埋点 + 漏斗分析
用户反馈收集GitHub Issue / Linear / 飞书多维表格用户可直接提交
会议纪要飞书智能纪要访谈记录自动整理
内部沟通飞书 / Slack按项目建频道
内容管理Notion / 飞书云文档SOP、模板、知识库

附录一：Bug Report 模板

## Issue 标题
[简明描述问题]

## 基本信息
- **来源渠道**：[用户反馈 / 客服 / 社媒 / 内测]
- **反馈次数**：[N] 次（≥3次请标注 severe）
- **系统/平台**：[Web / iOS / Android / Self-host]
- **版本号**：[如 v2.3.1]

## 复现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]

## 预期行为
[用户期望应该是什么样的]

## 实际行为
[当前实际发生的情况]

## 证据
[截图 / 录屏链接]

## 影响评估
[对用户体验/付费转化/留存的影响]

## 标签
[Bug / Feature Request / UX优化]

## 优先级建议（运营侧）
[P0（立即修）/ P1（本迭代修）/ P2（下个迭代修）]

附录二：迭代规划会模板

# [迭代名称] 规划会议纪要
**日期：**
**参与人：**

## 一、上迭代复盘
| 目标指标 | 起始值 | 结果值 | 完成情况 |
|---------|-------|-------|---------|
| | | | |

**未完成项：**
1.
2.

## 二、本迭代目标
| # | 目标 | 对应商业化价值 | 负责人 |
|---|-----|------------|-------|
| 1 | | | |
| 2 | | | |
| 3 | | | |

## 三、运营侧需求
| 需求 | 背景/用户反馈来源 | 建议优先级 |
|-----|----------------|----------|
| | | |

## 四、研发侧评估
| 需求 | 技术方案 | 工时估计 | 本迭代可完成？ |
|-----|---------|--------|-------------|
| | | | |

## 五、最终确认范围
**进入迭代：**
**延到下期：**
**技术债安排：**

附录三：产研运职责边界

事项决策方建议方执行方
功能要不要做产品 + 运营运营（需求）、研发（可行性）研发
Bug 修不修产品 + 运营运营（反馈集中度）研发
发版时间产研运三方共同——
用户访谈发现的优先级运营—产品 + 研发
增长策略运营 + 产品研发（数据支持）运营
技术架构/重构研发 + 产品运营（体验影响）研发

本 SOP 整合自真实产品战略会议纪要、用户反馈录入模板、内测用户访谈体系。适用于所有需要在产品、研发、运营三方之间建立协同机制的产品团队。

More in Dev Tools