product-dev-ops-playbook

🌍 言語 / 言語: 中国語 | English | 日本語 | 한국어

📦 インストール

clawhub install product-dev-ops-playbook

インストール後に利用できるもの：

• 三者間の認識合わせチェックポイントを含む、10日間のスプリントサイクル一式
• Issue テンプレート＋重大度の自動エスカレーションルール（3回報告されたら必ず修正）
• スプリント計画、レビュー、毎日のスタンドアップにすぐ使えるミーティングテンプレート

---

プロダクト開発 × 運営連携 SOP

本 SOP は、実際のプロダクト戦略会議の議事録、ユーザーフィードバック登録テンプレート、ベータテストユーザーへのインタビュー体系を統合し、プロダクト・開発・運営の三者連携のための汎用的な作業フレームワークをまとめたものです。

基本原則： あらゆることは商業化サービスを目指します。あらゆることは収益につなげるために行います。

使用方法： 本ドキュメントは汎用テンプレートです。すべての [製品名称] / [プロジェクトコード名] / [システム名称] を該当する情報に置き換えれば、そのまま使用できます。

---

一、主な課題の診断：なぜプロダクト・開発・運営の連携はうまくいかないのか？

1.1 成長段階にあるほぼすべてのプロダクトが直面する3つの対立

対立	現れ方	根本原因
新機能 vs ユーザーフィードバック	開発チームは新機能ばかり追い、ユーザーから報告された小さなバグは無期限に先送りされます	優先順位を統一して決める仕組みがない
開発がやりたいこと vs 運営が求めること	開発側は運営が技術を理解していないと感じ、運営側は開発がユーザーの声を聞かないと感じます	共通の目標がない
速さ vs 安定性	プロダクトの形がまだ定まっていないのに成長を急ぎ、技術的負債が積み重なります	プロダクトの段階を明確に判断できていない

1.2 解決の考え方

実際の会議から得られた知見： 商業化に成功している企業（Manus、DeepSeek など）では、COO または運営責任者が商業化に直接取り組み、プロダクト・開発・運営の三者が高度に連携しています。

4つの基本的な仕組み：

#	仕組み	説明
1	統合ボード	ユーザーフィードバックとプロダクト要件を同じプールに集め、同じタグ体系を使います
2	共通の目標	各イテレーションに明確な商業化指標を設定します（例：「登録→有料転換率を4.5% → 7%にする」）
3	運営に拒否権を持たせる	ユーザー体験や有料転換に直接悪影響を与える問題について、運営はリリース延期を直接提案できます
4	各イテレーション前に三者で認識を合わせる	プロダクト・開発・運営の責任者が、何を行うか、何を優先するか、何を次回に回すかを共同で決定します

---

二、統一された協業基盤：ボード体系の設計

2.1 2層のボード構造

実際の経験から： 各イテレーションの小さなボードだけではなく、必ず全体ボードを用意してください。すべての元の Issue をまず全体プールに入れ、その後、下流の各イテレーションに振り分けます。

階層	名称	内容	担当者
第1層：全体要件プール	[製品名称] 全体 backlog	あらゆる情報源からの元の Issue（ユーザーフィードバック／競合分析／戦略的要件）	プロダクト責任者
第2層：イテレーションボード	[バージョン番号] - [目標の説明]	今回のイテレーションで実施すると決まった要件＋必ず修正するバグ	イテレーション owner

流れ：

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

2.2 Issue 登録テンプレート（汎用形式）

重要な原則： 運営が提起するすべての Issue には再現可能な情報が必要です。そうでなければ、開発側は修正できません。

フィールド	説明	例
Issue タイトル	問題を簡潔に説明します	「iOS 版の鑑定結果が Android と一致しない」
報告元	ユーザーフィードバック／競合／戦略	ユーザーフィードバック
報告回数	同じ問題が何回報告されたか	3回以上 → 重大タグを付与
システム／プラットフォーム	Web / iOS / Android / Self-host	iOS
バージョン番号	具体的なバージョン	v2.3.1
再現手順	再現できなければ修正できません	1. 相性診断を開く 2. XX を選択する 3. 結果を確認する
期待される動作	ユーザーが期待する動作	2つの版の鑑定結果は一致するべきです
実際の動作	現在の実際の動作	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日目	テスト可能なバージョンを提出	テスト版を受け取り、半日以内にテストを完了	テストレポート（バグ一覧＋優先度）
7日目	優先度に基づいて P0/P1 を修正	運営×開発の認識合わせ会議（20〜30分）	今回のイテレーションの範囲を確定
8日目	修正を続け、2つ目のテスト版を作成	2回目のテスト（必要な場合）	—
9日目	最終修正	リリース素材（スクリーンショット／公式サイト／SNS）を準備	素材の準備完了
10日目	リリース	各チャネルでコンテンツを同時に公開	リリース完了

3.3 リリースの厳守事項

実際の失敗から得た教訓： 金曜日や週末にリリースすることは絶対に避けてください。

---

四、三者間の認識合わせ会議の仕組み

4.1 日次スタンドアップ（毎日、15分）

参加者： プロダクト／開発／運営の全員

• 立ったまま行い、15分以内に終わらせます
• 各自が話すのは3点だけです：①昨日何をしたか ②今日何をするか ③ blocker があるか
• 運営側は必ず報告します：前日のユーザーからの苦情で多かった内容、新たに見つかった頻発バグ
• 1時間を超える会議では、必ず誰かがサボります

4.2 イテレーション計画会議（各イテレーションの開始時、30〜60分）

参加者： プロダクト・開発・運営の三者の責任者

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

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

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

4.3 イテレーション受け入れ会議（各イテレーションの終了時、30分）

主な確認事項：

1. 今回のイテレーションの目標指標は達成できたか？
2. 未修正の P0 バグはあるか？リリースに影響するか？
3. 次のイテレーションに延期する機能はどれか？
4. 次のイテレーションで運営が重点的に取り組むことは何か？

4.4 会議頻度の一覧

会議	頻度	時間	目的
日次スタンドアップ	毎日	15分	進捗を共有し、blocker を見つけます
イテレーション計画会議	各イテレーションの開始時	30〜60分	今回のイテレーションで何を行うか決定します
イテレーション受け入れ会議	各イテレーションの終了時	30分	振り返り＋次のイテレーションの準備
月次レビュー	毎月	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 整合自真实产品战略会议纪要、用户反馈录入模板、内测用户访谈体系。适用于所有需要在产品、研发、运营三方之间建立协同机制的产品团队。