SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsproduct-dev-ops-playbook

product-dev-ops-playbook

General & other

View repository

Updated 10-15 21:52

About this skill

🌍 Language / 语言: 中文 | English | 日本語 | Korean

📦 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
Product R&D × Operations Collaboration SOP

This SOP integrates the minutes of a real product strategy meeting, a user feedback entry template, and a beta user interview system to distill a set ofthree-way collaboration among Product, R&D, and Operationsgeneral working framework.

Core principles: Everything serves commercialization. Everything serves making money.

Usage instructions: This document is a general template; simply replace all [产品名称] / [项目代号] / [系统名称] with the corresponding information to use it directly.

1. Core Problem Diagnosis: Why is Product-R&D-Operations collaboration always poor?

1.1 Three conflicts almost every growth-stage product encounters

Conflict Manifestation Root cause
New features vs user feedback The development team is always chasing new features, while small bugs reported by users are shelved indefinitely No unified priority decision-making mechanism
What R&D wants to build vs what Operations needs R&D thinks Operations doesn't understand technology; Operations thinks R&D doesn't listen to users Lack of shared goals
Fast vs stable Rushing to grow before the product form has stabilized, causing technical debt to pile up No clear judgment of the product stage

1.2 Solution approach

Insight from a real meeting: In companies that do commercialization and monetization well (such as Manus, DeepSeek), the COO or operations lead directly serves commercialization, and Product, R&D, and Operations collaborate highly closely.

Four core mechanisms:

# Mechanism Description
1 Unified board User feedback and product requirements go into the same pool and use the same set of tags
2 Shared goals Each iteration has a clear commercialization metric (e.g., "registration-to-paid conversion rate from 4.5% → 7%")
3 Operations has veto power For issues that directly harm user experience or paid conversion, Operations can directly propose delaying the release
4 Three-way alignment before each iteration The leads of Product, R&D, and Operations jointly decide what to do, what to do first, and what to put in the next cycle

2. Unified Collaboration Carrier: Board System Design

2.1 Two-tier board structure

From real experience: Don't have only a small board for each iteration; you must have a master board. All raw Issues first enter the master pool, then flow downstream to the various iterations.

Level Name Content Owner
First tier: Master requirements pool [产品名称] 总 backlog Raw Issues from all sources (user feedback/competitor analysis/strategic requirements) Product owner
Second tier: Iteration board [版本号] - [目标描述] Requirements confirmed for this iteration + bugs that must be fixed Iteration owner

Flow logic:

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

2.2 Issue entry template (general format)

Key principles: Every Issue submitted by Operations must include reproducible information; otherwise R&D cannot fix it.

Field Description Example
Issue Title Briefly describe the problem "iOS version's chart calculation results are inconsistent with Android"
Source Channel User feedback / Competitor / Strategy User feedback
Number of Reports How many times the same issue has been reported 3 or more times → tag as severe
System/Platform Web / iOS / Android / Self-host iOS
Version Number Specific version v2.3.1
Reproduction Steps It can only be fixed if it can be reproduced 1. Open synastry 2. Select XX 3. View results
Expected Behavior What the user expects The chart calculation results should be consistent across both versions
Actual Behavior Current actual behavior The display order on iOS is opposite to that on Android
Screenshots/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 Recommendation Operations-side judgment (High/Medium/Low) High

Special operations-side rule: If the same Issue has been reported 3 or more times, automatically tag it with severe and it must be resolved in the most recent iteration.

2.3 Bug and Feature Request Triage Handling

Type Definition Handling Method
Bug Existing feature behavior does not match expectations Go directly to the Bug board; R&D estimates work hours and fixes it
Feature Request The user needs a new feature Enters the master requirements pool; it can only enter iteration after Product produces a solution
UX optimization Does not affect core functionality, but affects experience Same level as Bug; Operations can push priority

III. Iteration Rhythm Design

3.1 Iteration Cycle Selection

Product Stage Recommended Iteration Cycle Description
Early PMF validation 1-2 weeks Fast pace, rapid trial and error
Growth stage 3-4 weeks Balance speed and stability
Stable stage 6-8 weeks Stability first; can do major versions

⚠️ Reminder: Under the modern Web development rhythm, it is recommended to compress it to 10 days~2 weeks. An overly long iteration cycle will cause the team to lose its sense of urgency.

3.2 10-Day Iteration Standard Process

Day R&D Action Operations Action Deliverable
Day 1 Start development — —
Day 6 Submit atestable version Claim the test version,finish testing within half a day Test report (Bug list + priority)
Day 7 Fix P0/P1 according to priority Operations × R&DAlignment meeting(20-30 minutes) Confirm the scope of this iteration
Day 8 Continue fixes + release the second test version Second round of testing (if necessary) —
Day 9 Final fixes Preparerelease assets(screenshots/official website/social media) Assets ready
Day 10 Release and launch Sync release content to all channels Release complete

3.3 Release cadence red lines

From real lessons: Never release on Friday or over the weekend.

IV. Tripartite alignment meeting mechanism

4.1 Daily stand-up (daily, 15 minutes)

Participants: Product / R&D / Operations, all members

  • Hold it standing up, limited to within 15 minutes
  • Each person says only three things: ① what you did yesterday ② what you are doing today ③ whether there are any blockers
  • The operations side must report: yesterday's hot user complaints and newly discovered high-frequency bugs
  • Any meeting longer than 1 hour will definitely have people slacking off

4.2 Iteration planning meeting (at the start of each iteration, 30-60 minutes)

Participants: the heads of product, R&D, and operations

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

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

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

4.3 Iteration acceptance meeting (at the end of each iteration, 30 minutes)

Core questions:

  1. This iteration'starget metricsachievement status?
  2. Which P0 bugs have not been fixed? Do they affect the release?
  3. Which features are decidedto be postponed to the next iteration？
  4. What is the operational focus for the next iteration?

4.4 Meeting frequency overview

Meeting Frequency Duration Purpose
Daily stand-up Every day 15 minutes Sync progress and discover blockers
Iteration planning meeting At the start of each iteration 30-60 minutes Decide what to do in this iteration
Iteration acceptance meeting At the end of each iteration 30 minutes Review + prepare for the next iteration
Monthly Review Every month 60-90 minutes Core metrics review + direction adjustment

V. The role of operations in collaboration

5.1 Operations is the "interpreter" between users and R&D

Responsibility Specific actions Frequency
Collect user voices Organize user feedback, extract high-frequency issues, and categorize them as Bug / Feature Daily
Initial Bug triage Confirm that each Issue is reproducible and add reproduction steps Daily
Priority suggestions Set priorities from the perspective of user experience and commercialization Every iteration
Version acceptance testing Starting on day 6,complete testing within half a dayand produce a report Every iteration
Release material preparation App Store updates, official website updates, social media publishing content Every iteration

5.2 Operations' veto power over releases

Trigger conditions: If before launch it is discovered thataffecting user experience or payment conversionP0 bugs have not been fixed, operations can proposepostponing the release。

P0 Bug criteria (judged by operations):

Bug type Example Is it P0
Payment-related Payment failure, duplicate charges ✅ P0
Core function unavailable Unable to register, unable to generate results ✅ P0
Data error Chart results inconsistent with other platforms ✅ P0
Interface disordered but functions usable Button position offset ⚠️ P1
Copy/translation error English spelling error ❌ P2

Six, User feedback-driven product iteration

6.1 Feedback → optimization closed loop

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

6.2 Internal testing user interview mechanism

Stage Time Action Person in charge
User screening 1 week before internal testing Screen 10-15 people from active users Operations
Test account distribution 3 days before internal testing Distribute test accounts + points Operations
User self-testing During internal testing Use the product based on real needs User
In-depth interviews During internal testing 30-40 minutes/session Operations
Daily summary After the end of each day Organize high-frequency bugs + core needs Operations
Weekly Review Weekly Determine whether it is suitable for release Product, engineering, and operations together

Interview structure (30-40 minutes):

Time Module Core questions
5 minutes User background What are you currently doing? What tools do you use? Biggest problem?
20 minutes Product testing review Which step was smoothest? Which step was most stuck? Were there any bugs?
10 minutes Optimization suggestions What do you most hope will be optimized first?
5 minutes Closing confirmation Are you willing to continue participating? Are you willing to recommend it?

Core principle: Do not discuss abstract feelings; only discuss the real usage process.

Seven, Core metric system

7.1 Target metric template for each iteration

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

7.2 Core commercialization funnel metrics

Stage Metric Description
Acquire Number of new registered users Break down by channel (organic/social media/paid ads/KOL)
Activate Onboarding completion rate Break down by module: information input/feature experience/getting results
Retain Day 1/Day 7/Day 30 retention rate Break down by user source
Pay Registration-to-payment conversion rate Break down by channel/user attributes
Refer K-factor (NPS/referral willingness) Invitation mechanism participation rate

7.3 Iteration Health Self-Check

Check Item Healthy Value Warning Signal
Average P0 Bug Fix Time ≤2 days > 3 days
On-Time Feature Launch Rate ≥80% <60%
Average User Feedback Response Time ≤24 hours > 48 hours
Number of Repeated Reports for the Same Bug ≤2 times ≥3 times
On-Time Test Report Submission Rate 100% before Day 6.5 More than half a day late

8. Technical Debt and Product Refactoring Management

8.1 Signals Triggering Refactoring

Signal Description
The same module has recurring bugs (≥5 related issues) Fundamental problems in module design
The cost of developing new features is increasing The underlying architecture limits scalability
Data inconsistency across multiple ends Entity abstraction is not unified
The technology choice is outdated The tech stack needs to be upgraded

8.2 Resource Allocation Recommendations

Type Recommended Proportion Description
New feature development 50-60% Directly serves commercialization goals
Bug fixes 20-30% Ensures the basic experience
Technical debt/refactoring 20-30% Ensures long-term sustainability

8.3 Handling Refactoring-Type Requirements

  • Refactoring-type requirementsshould be set up as a separate Project, with a cycle of 1-3 months
  • During refactoringnormal iterative releases should not be affected(two systems run in parallel)
  • After refactoring is complete,a complete regression testis required (recommended to have 3-5 core users participate)

9. Phase-Specific Priorities

Stage Priority Description
Cold start period (<PMF) Get the collaboration process working Use 2-3 iterations to get the process working, and conduct in-depth interviews with 20-30 users
Early growth period Clarify core metrics Onboarding completion rate / conversion rate / retention curve
Rapid growth period Improve R&D efficiency Compress iterations to 10 days and establish an in-house growth team

10. Recommended Tools

Purpose Tool Description
Project Management Linear / Jira / Feishu Bitable Unified entry point for all Issues
Data Analysis PostHog / Amplitude / Mixpanel Core funnel tracking + funnel analysis
User Feedback Collection GitHub Issue / Linear / Feishu Bitable Users can submit directly
Meeting Minutes Feishu Smart Minutes Automatic organization of interview records
Internal Communication Feishu / Slack Create channels by project
Content Management Notion / Feishu Docs SOPs, templates, knowledge base

Appendix 1: Bug Report Template

## 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（下个迭代修）]

Appendix 2: Iteration Planning Meeting Template

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

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

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

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

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

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

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

Appendix 3: Boundaries of Responsibilities Among Product, R&D, and Operations

Item Decision Maker Advisor Executor
Whether to build a feature Product + Operations Operations (requirements), R&D (feasibility) R&D
Whether to fix a Bug Product + Operations Operations (feedback concentration) R&D
Release Timing Product, R&D, and Operations jointly — —
Priorities found from user interviews Operations — Product + R&D
Growth Strategy Operations + Product R&D (data support) Operations
Technical Architecture/Refactoring R&D + Product Operations (experience impact) R&D

This SOP is integrated from real product strategy meeting minutes, user feedback entry templates, and the internal beta user interview system. It is applicable to all product teams that need to establish a collaboration mechanism among product, R&D, and operations.