1 前言
在数字产品的世界中，用户反馈不仅是检验产品成功与否的试金石，更是推动产品迭代与创新的关键驱动力。作为项目负责人，我们深知每一个反馈背后蕴含的用户需求与期望。最近刚好看到了@玉伯大佬写的文章从用户反馈到产品需求的思考，深受启发，结合这一年半的工作经验，总结一下自己的看法。
2 用户调研需要谨慎
在启动产品开发之前，深入的市场调研是至关重要的。市场调研的目的在于通过市场趋势分析、竞争对手研究及用户调查，收集有价值的信息，以指导产品策略和开发方向。在线上执行市场调研时，常见重点在于竞品分析和用户调查。然而，笔者认为传统用户调查方法可能并不总是高效。问卷调查虽然直接，但用户体验并不友好，填写问卷的积极性及问卷的真实性难以保证。因此，问卷调查的统计学结果应谨慎解读，仅作为参考。
要替代传统的市场调研方法，一个有效的策略是利用个人或团队的人脉网络。通过直接与目标企业用户沟通，了解他们在产品使用过程中重视的参数指标及应用场景，可以更精确地构建用户需求档案。此法需注意选择主营业务相近的一批企业进行咨询，因为针对细分市场的产品需要高度聚焦，避免因过于宽泛而失去产品核心竞争力。通过这种定向深入的方法，不仅能获得更为精准的市场洞察，还能确保调研结果的真实性和实用性，为产品的成功开发奠定坚实基础。
3 架构设计切勿过度优化
基于详尽的需求分析，产品团队着手进行产品设计和规划，这一过程涵盖了功能设定、用户界面设计、技术架构构建以及项目时间表的制定。在此阶段，确保设计贴合用户预期并具备可扩展性与可维护性是至关重要的。然而，无论是产品设计还是代码架构设计，都应避免过度优化。
强调不要过度优化是有原因的。笔者在独立负责第一个项目前，参与过 FastDeploy 的开发和维护。在开发和维护过程中，第一次接触到了代码架构设计。受到开源仓库的影响，在公司的代码架构设计阶段引入了大量的设计模型。这么做导致了几个很严重的问题，包括：
- 代码开发周期长。由于引入了大量的设计模型，导致加一个新功能都要按设计模式来添加，代码量无故增加，十分繁琐。
- 协同能力差。笔者所在的公司大部分同事的代码水平较弱，引入了大量设计模型后，同事维护代码非常吃力，业务很难找到人接手。
- 代码重构难度大。随着设计模型的增多，代码的内部都会按照“高内聚，低耦合”的原则设计，这就导致需要将几个功能串联整合起来时，需要重构代码，此时整合难度极大。
因此，我们建议采取“多重构，少设计”的策略，根据业务复杂度来决定采用多少设计模式。这样的方法论既能保证项目的灵活性和高效性，又能避免不必要的复杂性，从而更有效地推进产品开发。
4 理解用户反馈
4.1 直接反馈和间接反馈
一般来说，完成代码设计后我们就发布了第一个 SDK，此时开始收集用户反馈。要收集用户反馈就要先懂得可以通过哪些渠道获得用户反馈的信息。这里的用户范围可以大一点，可以是 B 端用户、C 端用户甚至是你的领导。无论反馈渠道是什么，我们都可以总结为直接反馈和间接反馈两大类。
直接反馈是用户明确表达的看法、建议和问题。这种反馈通常来自用户的口头沟通、反馈表单、社交媒体评论和客户支持请求。直接反馈提供了宝贵的信息，因为它直接反映了用户的期望和需求。产品经理需要善于收集、整理和分析这些反馈，以确定哪些问题需要解决，哪些建议值得考虑，并将其转化为具体的改进措施。
隐式反馈是通过用户行为和数据分析获得的信息。这包括用户的点击、浏览习惯、购买历史、停留时间等数据。通过分析这些数据，产品团队可以了解用户如何实际使用产品，识别潜在问题和改进机会。隐式反馈可以通过用户分析工具和数据科学方法来获取和解释，例如笔者比较关注的数据就是淘宝后台的加购率，购买率。
4.2 用户反馈需要分而治之
笔者的用户一般是 B 端和 C 端的用户，一般情况下，我习惯将 B 端用户和 C 端用户的反馈区别对待。针对 B 端用户，这部分用户一般量都比较大，他们的需要即使小众也要重点重视。针对 C 端用户，很容易出现大量不重叠的小众需求，这种需求做下去往往吃力不讨好，因此要关注重复性的需求。
针对 C 端用户，笔者会强制用户在发布 SDK 的 Gitee 仓库上通过 Issues 对自己遇到的问题或希望新增的需求做反馈。在用户提交反馈后，笔者会对反馈打标签，这样点进每个标签里就能知道用户集中的需求在哪里。另外，这样还有一个好处，就是如果用户反馈的是 Bug，其他用户也可以通过查阅 Issues 的方式来解决他们的问题，可以极大的降低售后的压力。
针对 B 端用户，每一个客户关注的点可能都不一样，因此需要专门拉团队来做支持。一般来说可以拉一个微信群，针对重点客户的需求针对性解决或者针对性发包，用定制化的方式解决问题。最后将多个定制化的项目合入主分支中，强化产品的鲁棒性。
另外一个容易忽视的点是领导的反馈，领导观点需要谨慎而仔细的看待。如果觉得领导的观点和产品核心利益点存在分歧，应该写一个分析表反馈给领导，而不是盲目去做。
4.2 建设性反馈和一般反馈
掌握了反馈渠道，便能持续收集用户反馈。此时，对反馈进行分类处理显得尤为关键。笔者通常将用户反馈划分为建设性反馈和一般反馈两类，并采取不同的处理策略。对于建设性反馈，本人会优先处理；而对于一般反馈，则将其处理优先级后移，甚至选择不进行处理。
建设性反馈特指用户提供的具有明确指向性、具体且富有建设性的意见和建议。这类反馈往往包括详细的问题描述、功能改进建议以及 Bug 报告。其特点是用户明确表达了他们的需求和期望，并为产品改进提供了具体路径。建设性反馈大多属于共性问题，对用户体验影响较大，应给予重点关注。例如，凌智 DAQ 高速采集器最初不支持 Labview，许多习惯于使用 N I采集器的客户难以转换，导致部分客户流失。本人在收到反馈后，迅速在第三季度进行了适配，并结合其他优化措施，使销售量在一个季度内增长了 30%。
一般反馈则是指用户提供的意见、评论或情感反馈，通常缺乏具体细节或建议。这类反馈可能涉及一般性的满意度陈述、喜好和感受，但未必提供详细的背景或上下文。尽管一般反馈不如建设性反馈那般具体，它们同样具有价值，因为它们能够揭示用户的情感状态和整体满意度。对于这类反馈，建议采取温和处理方式，将其纳入需求池，待研发团队有空闲时再进行处理。本人通常使用 Gitee 发布 SDK，故在 Issues 中集中反馈。对于那些确实不太重要的反馈，本人选择不进行处理。一个产品无法满足所有用户需求，新增需求应聚焦于大多数用户或大量用户的利益，避免因追求大而全而引发广泛问题。
5 需求的决策
笔者特别赞同玉伯大佬的说法：“需求只有选择，没有对错”。理解用户反馈的反馈后，我们再来看，面对一个有具体建议的用户反馈时，如何决策应不应该成为一个产品需求。笔者起初思考的是以下几点：
- 竞品是否有这个功能，这个功能是否给竞品带来了显著优势
- 技术上能否实现，开发资源能否覆盖到位
- 如果没有这个需求用户会受到哪些影响，影响的面有多大
- 长期来看，这个需求是否是必要的
- 需求背后的逻辑是什么，有没有更好的方式通过其他方案来实现这个需求
但是这么罗列出来其实还能有很多种不同的考量，一个一个思考总是麻烦的。在语雀的实践里，有一个需求决策三角模型：
玉伯大佬认为：从需求普适度、定位匹配度、实现成本三个维度来看每一个具体建议，最终给出我们的需求决策。理想情况下，这三个圈的交集，才是有效的产品需求。
