产品闭环要求

目的

这份文档给产品经理、业务负责人、项目负责人和小组长用。工程闭环能保证“事情被做完”，产品闭环要保证“做的是正确的事，并且上线后知道有没有产生价值”。

一个需求如果只写“做某个功能”，但说不清用户、问题、成功标准和上线后反馈，就不算产品闭环。

产品经理评审时先问 8 个问题

  1. 这个需求解决谁的问题？
  2. 用户现在怎么做，痛点在哪里？
  3. 不做会有什么损失？
  4. 这次成功的可观察信号是什么？
  5. Scope 里哪些必须做，哪些明确不做？
  6. 上线后谁验收，怎么验收？
  7. 如果效果不好，怎么下线、回滚或调整？
  8. 反馈从哪里回来，谁负责继续处理？

答不出来时，不要直接进入开发。先进入 clarification 或 discovery。

产品需求最小字段

字段 必须写什么 不合格表现
用户 / 客户 谁受影响，最好具体到角色或场景 “所有用户”
问题 用户现在遇到什么阻碍 只写“要做一个功能”
目标 希望用户或业务发生什么变化 只写“优化体验”
成功指标 用什么信号判断有效 没有指标或只写“用户满意”
Scope 这次做什么、不做什么 越做越大
验收标准 怎么判断功能符合预期 工程做完但产品不认
发布策略 全量、灰度、内测、开关 上线后风险不可控
反馈入口 用户反馈、客服、数据、运营看哪里 上线后没人看结果

草台团队可以先不写完整 PRD，但这 8 项必须能在任务卡、功能简报或评论里找到。

三角色产品准入

角色 在产品准入中确认
产品负责人 用户问题、目标、优先级、验收、反馈
技术负责人 scope 是否会引发架构、数据、安全、性能风险
平台 / 资深工程师 是否有可验收环境、mock、preview、截图或数据观测方式

优先级判断

不要只用“老板急不急”判断优先级。至少写出一个主要理由：

理由 说明
用户影响 影响多少用户、什么类型用户
收入 / 成本 增收、降本、减少人工处理
风险 合规、安全、数据、客户承诺
战略 是否支撑当前季度或项目目标
依赖 是否阻塞其他团队或客户交付
学习 是否用于验证一个关键假设

优先级可以由负责人拍板，但拍板理由要记录。否则团队会不断被临时需求牵着走。

产品验收

用户可见功能必须有 Business Approver。它可以是产品经理、业务负责人、运营负责人或客户成功负责人。

产品验收至少看 4 件事：

  1. 是否解决了原始用户问题。
  2. 核心路径是否按预期工作。
  3. 文案、状态、错误提示、权限边界是否可接受。
  4. 上线后观察或反馈入口是否明确。

产品验收不是让产品经理重复做 QA。测试证明“功能能跑”，产品验收判断“功能是否解决正确问题”。

发布前产品检查

用户可见功能发布前，产品经理或 Business Approver 要确认：

  1. Release scope 和用户影响范围。
  2. 是否需要灰度、内测、feature flag。
  3. 是否需要用户通知、客服话术、销售同步。
  4. 是否有截图、录屏或 staging 链接可验收。
  5. 上线后看哪些指标或反馈。
  6. 出问题时如何回滚或关闭功能。

如果需要对外沟通，但没有准备文案或负责人，不应直接全量发布。

上线后反馈回流

上线后 1-7 天内，Driver 或 Business Approver 应根据风险选择一种反馈检查：

类型 适用场景 最低检查
快速功能修复 小 bug、小文案 确认投诉或复现路径消失
用户可见功能 页面、流程、权限变化 看核心路径、客服反馈、错误率
增长 / 转化实验 注册、支付、邀请等 看实验指标或转化漏斗
高风险改动 支付、权限、数据 看监控、告警、人工抽样

检查结果必须回写任务或发布记录：

上线结果：
用户反馈：
指标变化：
遗留问题：
后续 action：

没有反馈回流的需求，只是“交付完成”，不算“产品闭环完成”。

产品反模式

反模式 后果 修正
需求只写解决方案 工程照做但可能解决错问题 先写用户、问题、目标
验收标准只有“页面完成” 做完也无法判断好坏 写核心路径和期望行为
所有需求都 P0 团队无法判断取舍 记录优先级理由
上线不通知客服 / 运营 用户反馈没人接 发布前明确沟通对象
只看工程 Done 用户价值没闭环 上线后补反馈检查
产品验收全靠口头 争议无法回溯 验收结论回写任务

下一步阅读

读完或填完这份文档后，通常继续看：