gr-product-dev-ops

> 🌍 **Language / 语言**: [中文](#中文版) | [English](references/en/README.md) | [日本語](references/ja/README.md) | [한국어](references/ko/README.md) ## 📦 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 --- # 产品研发 × 运营协同 SOP ## 证据补充：避免“40 分功能”陷阱 本地播客逐字稿中的 AFFiNE 复盘指出：方案被想出来时，产品工作才刚开始。若团队不断追逐新点子，会留下大量只做到 40–60 分、没有验证激活和留存的功能。每次迭代规划必须回答：本期把哪个已有能力从“能用”磨到“可靠”，完成阈值是什么，以及为此明确停止什么。 > 本 SOP 整合一场真实产品战略会议纪要、用户反馈录入模板、内测用户访谈体系，提炼出一套**产品、研发、运营三方协同**的通用工作框架。 > > **核心原则：** 一切面向商业化服务。一切为赚钱服务。 > > **使用说明：** 本文档为通用模板，将所有 `[产品名称]` / `[项目代号]` / `[系统名称]` 替换为对应信息即可直接使用。 --- ## 一、核心问题诊断：为什么产研运总是协同不好？ ### 1.1 几乎所有成长期产品都会遇到的三个矛盾 | 矛盾 | 表现 | 本质原因 | |------|------|----------| | **新功能 vs 用户反馈** | 开发团队总在追新功能，用户反馈的小 Bug 被无限搁置 | 没有统一的优先级决策机制 | | **研发想做什么 vs 运营要什么** | 研发觉得运营不懂技术，运营觉得研发不听用户 | 缺少共同目标 | | **快 vs 稳** | 产品形态还没稳定就急着增长，技术债越积越多 | 没有明确的产品阶段判断 | ### 1.2 解决思路 > **来自真实会议洞察：** 商业化变现做得好的公司（如 Manus、DeepSeek），COO 或运营负责人直接为商业化服务，产研运三方高度协同。 **四大核心机制：** | # | 机制 | 说明 | |---|------|------| | 1 | **统一看板** | 用户反馈和产品需求进同一个池子，用同一套标签体系 | | 2 | **共同目标** | 每次迭代有明确的商业化指标（如"注册→付费转化率从 4.5% → 7%"） | | 3 | **运营有一票否决权** | 直接伤害用户体验或付费转化的问题，运营可以直接提议推迟发版 | | 4 | **每个迭代前三方对齐** | 产研运负责人共同决定做什么、哪些先做、哪些放下一期 | --- ## 二、统一协作载体：看板体系设计 ### 2.1 两层看板结构 > **来...