gr-product-dev-ops

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

🌍 Language: Chinese | English | Japanese | Korean

📦 Install

bash

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

bash

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

Product × Engineering × Operations Collaboration SOP

证据补充：避免“40 分功能”陷阱

Supplementary Evidence: Avoid the "40% Feature" Trap

本地播客逐字稿中的 AFFiNE 复盘指出：方案被想出来时，产品工作才刚开始。若团队不断追逐新点子，会留下大量只做到 40–60 分、没有验证激活和留存的功能。每次迭代规划必须回答：本期把哪个已有能力从“能用”磨到“可靠”，完成阈值是什么，以及为此明确停止什么。

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

核心原则： 一切面向商业化服务。一切为赚钱服务。
使用说明： 本文档为通用模板，将所有
[产品名称]
/
[项目代号]
/
[系统名称]
替换为对应信息即可直接使用。

A retrospective from AFFiNE in a local podcast transcript points out: Product work only starts when a solution is conceived. If the team keeps chasing new ideas, it will leave a large number of features that are only 40–60% complete, without verifying activation and retention. Each iteration planning must answer: Which existing capability will be polished from "usable" to "reliable" in this phase, what is the completion threshold, and what will be explicitly stopped for this purpose.

This SOP integrates minutes from a real product strategy meeting, user feedback entry templates, and beta user interview systems, and extracts a general work framework for tri-party collaboration between Product, Engineering, and Operations.

Core Principle: Everything serves commercialization. Everything serves profit generation.
Usage Instructions: This document is a general template. Replace all
[Product Name]
/
[Project Code]
/
[System Name]
with corresponding information to use it directly.

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

1. Core Problem Diagnosis: Why Can't Product, Engineering, and Operations Collaborate Well?

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

1.1 Three Conflicts Almost All Growth-Stage Products Face

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

Conflict	Manifestation	Root Cause
New Features vs User Feedback	The dev team always chases new features, while minor user-reported bugs are put off indefinitely	No unified priority decision-making mechanism
What Engineering Wants to Do vs What Operations Needs	Engineering thinks Operations doesn't understand technology; Operations thinks Engineering ignores users	Lack of shared goals
Speed vs Stability	Rushing for growth before the product form is stable, leading to accumulating technical debt	No clear judgment of product stages

1.2 解决思路

1.2 Solution Approach

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

四大核心机制：

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

Insight from Real Meetings: Companies with successful commercialization (e.g., Manus, DeepSeek) have COOs or operation leaders directly responsible for commercialization, with high-level collaboration among Product, Engineering, and Operations.

Four Core Mechanisms:

#	Mechanism	Description
1	Unified Kanban	User feedback and product requirements enter the same pool with a unified tagging system
2	Shared Goals	Each iteration has clear commercial metrics (e.g., "Signup-to-payment conversion rate from 4.5% → 7%")
3	Operations Veto Power	Operations can propose delaying releases for issues that directly harm user experience or payment conversion
4	Tri-party Alignment Before Each Iteration	Leaders of Product, Engineering, and Operations jointly decide what to do, what to prioritize, and what to defer to the next iteration

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

2. Unified Collaboration Carrier: Kanban System Design

2.1 两层看板结构

2.1 Two-layer Kanban Structure

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

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

流向逻辑：

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

Real Experience Insight: Don't only have small kanbans for each iteration; there must be a master kanban. All original Issues first enter the master pool, then flow to downstream iterations.

Layer	Name	Content	Owner
Layer 1: Master Backlog	`[Product Name] Master Backlog`	All original Issues from all sources (user feedback/competitor analysis/strategic requirements)	Product Owner
Layer 2: Iteration Kanban	`[Version Number] - [Goal Description]`	Confirmed requirements and must-fix bugs for this iteration	Iteration Owner

Flow Logic:

Master Backlog (Issues from all sources)
    ↓ Reviewed and approved to form a solution
Solutionized Requirements
    ↓ Scheduled via planning meeting
Enter an iteration project
    ↓ Developed within the iteration
Released / Rolled back to backlog / Deferred to next iteration

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

2.2 Issue Entry Template (General Format)

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

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

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

Key Principle: Every Issue submitted by Operations must include reproducible information, otherwise Engineering cannot fix it.

Field	Description	Example
Issue Title	Concise description of the problem	"iOS version layout results inconsistent with Android"
Source Channel	User feedback / Competitor / Strategic	User feedback
Number of Reports	How many times the same issue has been reported	3+ times → mark as severe
System/Platform	Web / iOS / Android / Self-host	iOS
Version Number	Specific version	v2.3.1
Reproduction Steps	Must be reproducible to fix	1. Open layout tool 2. Select XX 3. Check results
Expected Behavior	What users expect	Layout results should be consistent across both versions
Actual Behavior	Current actual performance	iOS display order is opposite to Android
Screenshot/Screen Recording	Attach evidence	[Attachment]
Impact Assessment	Impact on experience/payment	Caused 1 user to request a refund
Tags	Bug / Feature Request / UX Optimization	Bug
Priority Suggestion	Operations-side judgment (High/Medium/Low)	High

Special Rule for Operations: If the same Issue is reported 3+ times, automatically mark it with the
severe
tag and resolve it in the nearest iteration.

2.3 Bug 与 Feature Request 分流处理

2.3 Bug vs Feature Request Diversion Handling

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

Type	Definition	Handling Method
Bug	Existing function behaves differently from expected	Directly enter the Bug kanban; Engineering estimates effort and fixes it
Feature Request	Users need new features	Enter the master backlog; Product develops a solution before it can enter an iteration
UX Optimization	Does not affect core functions but impacts experience	Same priority as Bug; Operations can push for higher priority

三、迭代节奏设计

3. Iteration Cadence Design

3.1 迭代周期选择

3.1 Iteration Cycle Selection

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

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

Product Stage	Recommended Iteration Cycle	Description
Early PMF Validation	1-2 weeks	Fast-paced, rapid experimentation
Growth Stage	3-4 weeks	Balance speed and stability
Stable Stage	6-8 weeks	Prioritize stability; can release large versions

⚠️ Reminder: Under modern web development rhythms, it is recommended to compress to 10 days ~ 2 weeks. Overly long iteration cycles will cause the team to lose a sense of urgency.

3.2 10 天迭代标准流程

3.2 10-Day Iteration Standard Process

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

Day	Engineering Actions	Operations Actions	Deliverables
Day 1	Start development	—	—
Day 6	Submit testable build	Receive test build, complete beta testing in half a day	Test report (Bug list + priorities)
Day 7	Fix P0/P1 bugs based on priority	Alignment meeting between Operations and Engineering (20-30 minutes)	Confirm iteration scope
Day 8	Continue fixing + release second test build	Second round of testing (if necessary)	—
Day 9	Final fixes	Prepare release materials (screenshots/official website/social media)	Materials ready
Day 10	Release online	Sync release content to all channels	Release completed

3.3 发布节奏红线

3.3 Release Cadence Red Line

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

Real Lesson: Never release on Friday or weekends.

四、三方对齐会议机制

4. Tri-party Alignment Meeting Mechanism

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

4.1 Daily Standup (Daily, 15 minutes)

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

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

Participants: All Product / Engineering / Operations team members

Hold standing meetings, limited to 15 minutes or less
Each person only talks about three things: ① What did you do yesterday? ② What will you do today? ③ Are there any blockers?
Operations must report: Yesterday's user complaint hotspots, newly discovered high-frequency Bugs
Meetings longer than 1 hour will definitely have people slacking off

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

4.2 Iteration Planning Meeting (Start of each iteration, 30-60 minutes)

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

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

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

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

Participants: Leaders of Product, Engineering, and Operations

Agenda 1: Retrospect last iteration (20 minutes)
  - Core metric completion status (vs targets)
  - What wasn't completed? Why?
  - Where is user feedback concentrated?

Agenda 2: Set current iteration goals (20 minutes)
  - Operations side: Top issues to solve this iteration (linked to commercial goals)
  - Product side: New features/optimizations to promote this iteration
  - Engineering side: Technical debt/refactoring requirements
  - Joint decision: Top 3 goals for this iteration

Agenda 3: Confirm resources and schedule (20 minutes)
  - How many man-days will each party invest?
  - Which features are confirmed to enter the iteration? Which are on hold?
  - Are there modules that need refactoring?

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

4.3 Iteration Acceptance Meeting (End of each iteration, 30 minutes)

核心问题：

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

Core Questions:

Did we achieve the target metrics for this iteration?
Are there any unresolved P0 Bugs? Will they affect the release?
Which features will be deferred to the next iteration?
What are the Operations priorities for the next iteration?

4.4 会议频率总览

4.4 Meeting Frequency Overview

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

Meeting	Frequency	Duration	Purpose
Daily Standup	Daily	15 minutes	Sync progress, identify blockers
Iteration Planning Meeting	Start of each iteration	30-60 minutes	Decide what to do in this iteration
Iteration Acceptance Meeting	End of each iteration	30 minutes	Retrospect + prepare for next iteration
Monthly Review	Monthly	60-90 minutes	Retrospect core metrics + adjust direction

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

5. Operations Role in Collaboration

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

5.1 Operations as the "Translator" Between Users and Engineering

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

Responsibility	Specific Actions	Frequency
Collect User Voices	Organize user feedback, extract high-frequency issues, classify as Bug / Feature	Daily
Bug Initial Screening	Confirm each Issue is reproducible, supplement reproduction steps	Daily
Priority Suggestion	Assign priorities from user experience and commercial perspectives	Per iteration
Version Acceptance Testing	Start on Day 6, complete testing in half a day and submit report	Per iteration
Prepare Release Materials	App Store updates, official website updates, social media content	Per iteration

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

5.2 Operations Veto Power on Releases

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

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

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

Trigger Condition: If unresolved P0 Bugs that affect user experience or payment conversion are found before release, Operations can propose delaying the release.

P0 Bug Standards (Operations-side Judgment):

Bug Type	Example	Is it P0?
Payment-related	Payment failure, duplicate charges	✅ P0
Core function unavailable	Cannot sign up, cannot generate results	✅ P0
Data error	Layout results inconsistent with other platforms	✅ P0
UI glitch but functional	Button position offset	⚠️ P1
Copy/translation error	English spelling mistake	❌ P2

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

6. User Feedback-Driven Product Iteration

6.1 反馈→优化闭环

6.1 Feedback → Optimization Closed Loop

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

Users use the product → Raise issues/suggestions
        ↓
Operations collect (organize/classify/screen)
        ↓
Enter Issue into master kanban (with reproduction steps)
        ↓
Same issue reported 3+ times → Mark as severe
        ↓
Focus on severe items in iteration planning meeting
        ↓
Enter iteration development
        ↓
Operations verify if the issue is resolved after release
        ↓
Notify users the issue is fixed (enhance sense of being valued)

6.2 内测用户访谈机制

6.2 Beta User Interview Mechanism

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

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

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

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

Phase	Time	Actions	Owner
User Screening	1 week before beta	Select 10-15 users from active users	Operations
Test Account Distribution	3 days before beta	Distribute test accounts + points	Operations
User Self-Testing	During beta	Use the product based on real needs	Users
In-depth Interviews	During beta	30-40 minutes per session	Operations
Daily Summary	End of each day	Organize high-frequency Bugs + core requirements	Operations
Weekly Review	Weekly	Judge if it's ready for release	Jointly by Product, Engineering, and Operations

Interview Structure (30-40 minutes):

Time	Module	Core Questions
5 minutes	User Background	What do you do currently? What tools do you use? What's your biggest pain point?
20 minutes	Product Testing Retrospect	Which steps went smoothly? Which steps were stuck? Any Bugs?
10 minutes	Optimization Suggestions	What do you most want to prioritize optimizing?
5 minutes	Closing Confirmation	Are you willing to continue participating? Would you recommend the product?

Core Principle: Don't discuss abstract feelings; only discuss real usage processes.

七、核心指标体系

7. Core Metrics System

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

7.1 Iteration Target Metrics Template

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

Current Iteration Goal: [Specific Description]
- Starting Value: XX%
- Target Value: XX%
- Verification Method: [Data Source/Query Method]
- Owner: Product/Operations/Engineering

7.2 商业化核心链路指标

7.2 Commercial Core Link Metrics

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

Phase	Metric	Description
Acquisition	New registered users	Split by channel (organic/social media/ads/KOL)
Activation	Onboarding completion rate	Split by module: information input/function experience/result acquisition
Retention	1-day/7-day/30-day retention rate	Split by user source
Monetization	Signup-to-payment conversion rate	Split by channel/user attributes
Referral	K-factor (NPS/recommendation willingness)	Participation rate in invitation mechanism

7.3 迭代健康度自检

7.3 Iteration Health Self-Check

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

Check Item	Healthy Value	Warning Signal
Average P0 Bug fix time	≤2 days	> 3 days
Feature on-time release rate	≥80%	<60%
Average user feedback response time	≤24 hours	> 48 hours
Number of repeated reports for the same Bug	≤2 times	≥3 times
Test report submission timeliness	100% before Day 6.5	Over half a day late

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

8. Technical Debt and Product Refactoring Management

8.1 触发重构的信号

8.1 Signals Triggering Refactoring

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

Signal	Description
Repeated Bugs in the same module (≥5 related Issues)	Fundamental design flaws in the module
Increasing development cost for new features	Underlying architecture limits scalability
Inconsistent data across multiple ends	Ununified entity abstraction
Outdated technical selection	Need to upgrade tech stack

8.2 资源分配建议

8.2 Resource Allocation Suggestions

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

Type	Recommended Proportion	Description
New Feature Development	50-60%	Directly serves commercial goals
Bug Fixing	20-30%	Ensures basic experience
Technical Debt/Refactoring	20-30%	Ensures long-term sustainability

8.3 重构类需求处理

8.3 Refactoring Requirement Handling

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

Refactoring requirements are built as separate Projects, with a cycle of 1-3 months
Refactoring does not affect normal iteration releases (two systems run in parallel)
After refactoring, complete regression testing is required (recommend 3-5 core users to participate)

九、阶段性重点

9. Phase-specific Priorities

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

Phase	Priority	Description
Cold Start Phase (<PMF)	Run through collaboration processes	Run through the process in 2-3 iterations, conduct in-depth interviews with 20-30 users
Early Growth Phase	Clarify core metrics	Onboarding completion rate / conversion rate / retention curve
Rapid Growth Phase	Improve development efficiency	Compress iterations to 10 days, build an in-house growth team

十、工具推荐

10. Tool Recommendations

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

Purpose	Tool	Description
Project Management	Linear / Jira / Feishu Multi-dimensional Spreadsheet	Unified entry for all Issues
Data Analysis	PostHog / Amplitude / Mixpanel	Core link tracking + funnel analysis
User Feedback Collection	GitHub Issue / Linear / Feishu Multi-dimensional Spreadsheet	Users can submit directly
Meeting Minutes	Feishu Intelligent Minutes	Automatically organize interview records
Internal Communication	Feishu / Slack	Create channels by project
Content Management	Notion / Feishu Cloud Document	SOPs, templates, knowledge base

附录一：Bug Report 模板

Appendix 1: Bug Report Template

markdown

undefined

markdown

undefined

Issue 标题

Issue Title

[简明描述问题]

[Concise description of the issue]

基本信息

Basic Information

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

Source Channel: [User Feedback / Customer Service / Social Media / Beta Testing]
Number of Reports: [N] times (mark as severe if ≥3)
System/Platform: [Web / iOS / Android / Self-host]
Version Number: [e.g., v2.3.1]

复现步骤

Reproduction Steps

[步骤1]
[步骤2]
[步骤3]

[Step 1]
[Step 2]
[Step 3]

预期行为

Expected Behavior

[用户期望应该是什么样的]

[What users expect to happen]

实际行为

Actual Behavior

[当前实际发生的情况]

[What actually happens currently]

证据

Evidence

[截图 / 录屏链接]

[Screenshot / Screen Recording Link]

影响评估

Impact Assessment

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

[Impact on user experience/payment conversion/retention]

优先级建议（运营侧）

Priority Suggestion (Operations Side)

[P0（立即修）/ P1（本迭代修）/ P2（下个迭代修）]

---

[P0 (Fix immediately) / P1 (Fix in this iteration) / P2 (Fix in next iteration)]

---

附录二：迭代规划会模板

Appendix 2: Iteration Planning Meeting Template

markdown

undefined

markdown

undefined

[迭代名称] 规划会议纪要

[Iteration Name] Planning Meeting Minutes

日期： 参与人：

Date: Participants:

一、上迭代复盘

1. Last Iteration Retrospect

目标指标	起始值	结果值	完成情况

未完成项： 1. 2.

Target Metric	Starting Value	Result Value	Completion Status

Uncompleted Items: 1. 2.

二、本迭代目标

2. Current Iteration Goals

#	目标	对应商业化价值	负责人
1
2
3

#	Goal	Corresponding Commercial Value	Owner
1
2
3

三、运营侧需求

3. Operations-side Requirements

需求	背景/用户反馈来源	建议优先级

Requirement	Background/User Feedback Source	Suggested Priority

四、研发侧评估

4. Engineering-side Assessment

需求	技术方案	工时估计	本迭代可完成？

Requirement	Technical Solution	Effort Estimate	Can be completed in this iteration?

五、最终确认范围

5. Final Confirmed Scope

进入迭代： 延到下期： 技术债安排：

---

Enter Iteration: Defer to Next Iteration: Technical Debt Arrangement:

---

附录三：产研运职责边界

Appendix 3: Responsibility Boundaries for Product, Engineering, and Operations

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

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

Item	Decision-maker	Advisor	Executor
Whether to build a feature	Product + Operations	Operations (requirements), Engineering (feasibility)	Engineering
Whether to fix a Bug	Product + Operations	Operations (feedback concentration)	Engineering
Release time	Jointly by Product, Engineering, and Operations	—	—
Priority from user interviews	Operations	—	Product + Engineering
Growth strategy	Operations + Product	Engineering (data support)	Operations
Technical architecture/refactoring	Engineering + Product	Operations (experience impact)	Engineering

This SOP is integrated from real product strategy meeting minutes, user feedback entry templates, and beta user interview systems. It is suitable for all product teams that need to establish collaboration mechanisms between Product, Engineering, and Operations.