产品反馈与需求抽象

将客户诉求还原为可复用问题

“给客户 A 加一个专用按钮”描述了实现方式，还没有说明问题。反馈应包含用户任务、频率、影响、现有绕行和证据，再判断是否值得成为产品能力。

现场反馈卡

字段	合成案例
原始诉求	每位客户增加专属资料选择按钮
用户问题	无法判断设备适用哪个手册版本
当前绕行	在聊天中询问管理员后手动筛选
通用能力候选	文档生效版本与设备适配规则
证据缺口	其他客户是否出现同类错误
验证实验	在第二个合成租户使用配置规则

区分项目、配置与产品

法规或合同独有流程可能保留为项目扩展；文案、字段映射与阈值优先配置；跨客户稳定出现且能定义统一语义的问题再提议进入产品。不能只按“出现两次”机械判断，需要解释差异能否被稳定抽象。

与产品团队对齐

提交问题证据、受影响人群、价值和不解决的代价，附上当前替代及建议实验。让产品团队理解决策背景，而不是只丢一份功能清单。客户期望与内部排期分别管理，反馈被接收不代表已承诺发布日期。

关闭反馈的标准

状态可用“待取证、待决策、已排期、已交付、暂不处理”。每条记录有责任人、决定理由和下次复查时间。交付后回到用户任务验证问题是否缓解，代码合并不是反馈闭环终点。

练习与完成标准

把三个定制请求改写成问题卡，给出项目扩展、配置或产品化建议，并标记仍需验证的部分。涉及真实客户的公开反馈必须去除身份与敏感背景。下一步阅读方案复用。

参考阅读与使用边界

• GOV.UK：深度用户访谈：相关概念与方法的延伸阅读，访问核验日期 2026-10-14。本站练习、流程与指标为自主编排，不属于来源机构认证。
• 学习路线 · 项目实战 · 可下载模板

本页为基础指南；生产操作需结合实际版本、授权环境与审核证据验证。