SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgr-product-dev-ops

gr-product-dev-ops

General & other

View repository

Updated 10-16 05:49

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

Evidence Supplement: Avoid the "40-Point Feature" Trap

The AFFiNE retrospective in the local podcast transcript points out: when a solution is conceived, the product work has only just begun. If a team constantly chases new ideas, it will leave behind a large number of features that are only 40–60 points and have not validated activation and retention. Every iteration planning must answer: which existing capability will be polished from "usable" to "reliable" in this cycle, what the completion threshold is, and what is explicitly stopped for this purpose.

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 general working framework forthree-way collaboration among product, R&D, and operations.

Core principles: Everything is oriented toward commercialization services. Everything serves making money.

Instructions for use: This document is a general template. Replace all [产品名称] / [项目代号] / [系统名称] with the corresponding information and it can be used directly.

I. Diagnosis of Core Problems: Why is product-R&D-operations collaboration always poor?

1.1 Three contradictions almost all growth-stage products encounter

Contradiction 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 There is no unified priority decision-making mechanism
What R&D wants to do vs what operations needs R&D thinks operations does not understand technology, while operations thinks R&D does not listen to users Lack of shared goals
Fast vs stable The product form has not yet stabilized before rushing to growth, and technical debt keeps accumulating No clear judgment of the product stage

1.2 Solution approach

From real meeting insights: In companies that do commercialization and monetization well (such as Manus and DeepSeek), the COO or head of operations directly serves commercialization, and product, R&D, and operations are highly collaborative.

Four core mechanisms:

# Mechanism Description
1 Unified board User feedback and product requirements go into the same pool and use the same tagging system
2 Shared goals Each iteration has clear commercialization metrics (for example, "registration → 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 postponing the release
4 Three-way alignment before each iteration The heads of product, R&D, and operations jointly decide what to do, what to do first, and what to put in the next cycle

II. Unified Collaboration Vehicle: Board System Design

2.1 Two-layer board structure

From real experience: Do not have only a small board for each iteration; there must be an overall board. All raw issues first enter the general pool, then flow downstream to each iteration.

Level Name Content Owner
First layer: general requirements pool [产品名称] 总 backlog Raw issues from all sources (user feedback/competitive analysis/strategic requirements) Product owner
Second layer: 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 raised by Operations must contain reproducible information, otherwise R&D cannot fix it.

Field Description Example
Issue Title Briefly describe the problem "iOS version chart results are inconsistent with Android"
Source Channel User feedback / Competitor / Strategy User feedback
Feedback Count How many times the same issue has been reported More than 3 times → tag as severe
System/Platform Web / iOS / Android / Self-host iOS
Version Number Specific version v2.3.1
Reproduction Steps Only fixable if reproducible 1. Open synastry 2. Select XX 3. View results
Expected Behavior What the user expects The chart results in both versions should be consistent
Actual Behavior Current actual behavior The display order on iOS is opposite to 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 Suggestion Operations-side judgment (High/Medium/Low) High

Special rules on the operations side: If the same Issue has been reported more than 3 times, automatically tag it as severe and it must be resolved in the most recent iteration.

2.3 Bug and Feature Request Triage

Type Definition Handling Method
Bug Existing feature behavior does not match expectations Go directly to the Bug board; R&D estimates the effort and then fixes it
Feature Request Users need a new feature Enter the overall requirements pool; it can enter the iteration only after the product produces a proposal
UX optimization Does not affect core functionality, but affects experience Same level as Bug; Operations can push for priority

III. Iteration Cadence 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 handle major versions

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

3.2 Standard 10-Day Iteration Process

Day R&D actions Operations actions Deliverables
Day 1 Start development — —
Day 6 Submittestable version Receive the test version,complete 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 fixing + produce the second test version Second round of testing (if necessary) —
Day 9 Final fixes Preparerelease materials(screenshots/official website/social media) Materials ready
Day 10 Release and launch Sync release content to all channels Release completed

3.3 Release cadence red lines

From real lessons: Absolutely do not release on Fridays or weekends.

IV. Tripartite alignment meeting mechanism

4.1 Daily stand-up (daily, 15 minutes)

Participants: All product / R&D / operations staff

  • Hold it standing, limited to within 15 minutes
  • Each person says only three things: ① what was done yesterday ② what is being done today ③ whether there are any blockers
  • Operations must report: yesterday's user complaint hot spots, newly discovered high-frequency bugs
  • In meetings longer than 1 hour, someone will definitely slack off

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

Participants: Product, R&D, and operations leads

议题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 operations focus for the next iteration?

4.4 Meeting frequency overview

Meeting Frequency Duration Purpose
Daily stand-up Daily 15 minutes Sync progress, 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 Monthly 60-90 minutes Core metrics review + direction adjustment

V. The role of operations in collaboration

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

Responsibility Specific actions Frequency
User Voice Collection Organize user feedback, extract high-frequency issues, and categorize them as Bug / Feature Daily
Bug Triage Confirm that each Issue is reproducible and add reproduction steps Daily
Priority Recommendations Set priorities from the perspectives 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 release content Every iteration

5.2 Operations' Veto Power Over Releases

Trigger condition: If before launch it is found thataffects user experience or paid conversionP0 Bug has not been fixed, Operations can proposepostponing the release。

P0 Bug Criteria (Operations-side judgment):

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

VI. User Feedback-Driven Product Iteration

6.1 Feedback → Optimization Closed Loop

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

6.2 Beta User Interview Mechanism

Stage Time Action Owner
User Screening 1 week before beta testing Select 10-15 people from active users Operations
Test Account Distribution 3 days before beta testing Distribute test accounts + points Operations
User Self-Testing During beta testing Use the product based on real needs User
In-Depth Interview During beta testing 30-40 minutes/session Operations
Daily Summary After the end of each day Organize high-frequency Bugs + core requirements 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 are you using? Biggest problem?
20 minutes Product Testing Review Which step was smoothest? Which step was the most stuck? Were there any Bugs?
10 minutes Optimization Suggestions What do you most want prioritized for optimization?
5 minutes Closing confirmation Are you willing to continue participating? Would you recommend it?

Core principles: Do not discuss abstract feelings; only discuss real usage processes.

VII. Core Metrics System

7.1 Goal Metrics Template for Each Iteration

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

7.2 Core Commercialization Funnel Metrics

Stage Metric Description
Acquisition Number of new registered users Break down by channel (organic/social media/paid ads/KOL)
Activation Onboarding completion rate View by module: information input/feature experience/getting results
Retention Next-day/7-day/30-day retention rate Break down by user source
Payment Registration-to-payment conversion rate Break down by channel/user attributes
Referral 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 of the same Bug ≤2 times ≥3 times
Test report submission timeliness rate 100% before Day 6.5 More than half a day late

VIII. Technical Debt and Product Refactoring Management

8.1 Signals That Trigger Refactoring

Signal Description
The same module repeatedly has Bugs (≥5 related Issues) The module design has fundamental problems
The cost of developing new features keeps 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 basic experience
Technical debt/refactoring 20-30% Ensures long-term sustainability

8.3 Handling Refactoring-Type Requirements

  • Refactoring-type requirementsCreate a separate Project, with a cycle of 1-3 months
  • During refactoringDo not affect normal iteration releases(two systems run in parallel)
  • After refactoring is completed,complete regression testingis required (recommended to have 3-5 core users participate)

IX. Phased Priorities

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

Ten, Tool Recommendations

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 Recommender 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 time Jointly by Product, R&D, and Operations — —
Priorities discovered 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 integrates real product strategy meeting minutes, user feedback entry templates, and the internal testing user interview system. It is applicable to all product teams that need to establish a collaboration mechanism among product, R&D, and operations.