🌍
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
Product × Engineering × Operations Collaboration SOP
Supplementary Evidence: Avoid the "40% Feature" Trap
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
/
/
with corresponding information to use it directly.
1. Core Problem Diagnosis: Why Can't Product, Engineering, and Operations Collaborate Well?
1.1 Three Conflicts Almost All Growth-Stage Products Face
| 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 Solution Approach
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 Two-layer Kanban Structure
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 Entry Template (General Format)
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
tag and resolve it in the nearest iteration.
2.3 Bug vs Feature Request Diversion Handling
| 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 Iteration Cycle Selection
| 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-Day Iteration Standard Process
| 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 Release Cadence Red Line
Real Lesson: Never release on Friday or weekends.
4. Tri-party Alignment Meeting Mechanism
4.1 Daily Standup (Daily, 15 minutes)
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 Iteration Planning Meeting (Start of each iteration, 30-60 minutes)
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 Iteration Acceptance Meeting (End of each iteration, 30 minutes)
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 Meeting Frequency Overview
| 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 Operations as the "Translator" Between Users and Engineering
| 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 Operations Veto Power on Releases
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 Feedback → Optimization Closed Loop
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 Beta User Interview Mechanism
| 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 Iteration Target Metrics Template
Current Iteration Goal: [Specific Description]
- Starting Value: XX%
- Target Value: XX%
- Verification Method: [Data Source/Query Method]
- Owner: Product/Operations/Engineering
7.2 Commercial Core Link Metrics
| 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 Iteration Health Self-Check
| 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 Signals Triggering Refactoring
| 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 Resource Allocation Suggestions
| 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 Refactoring Requirement Handling
- 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
| 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
| 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 |
Appendix 1: Bug Report Template
markdown
## Issue Title
[Concise description of the issue]
## Basic Information
- **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. [Step 1]
2. [Step 2]
3. [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]
## Tags
[Bug / Feature Request / UX Optimization]
## Priority Suggestion (Operations Side)
[P0 (Fix immediately) / P1 (Fix in this iteration) / P2 (Fix in next iteration)]
Appendix 2: Iteration Planning Meeting Template
markdown
# [Iteration Name] Planning Meeting Minutes
**Date:**
**Participants:**
## 1. Last Iteration Retrospect
|---------|-------|-------|---------|
| | | | |
**Uncompleted Items:**
1.
2.
## 2. Current Iteration Goals
|---|-----|------------|-------|
| 1 | | | |
| 2 | | | |
| 3 | | | |
## 3. Operations-side Requirements
|-----|----------------|----------|
| | | |
## 4. Engineering-side Assessment
|-----|---------|--------|-------------|
| | | | |
## 5. Final Confirmed Scope
**Enter Iteration:**
**Defer to Next Iteration:**
**Technical Debt Arrangement:**
Appendix 3: Responsibility Boundaries for Product, Engineering, and Operations
| 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.