如何基于消费者需求演进SaaS产品服务

作者：Teresa Hoffman

产品工程团队常常面临两个挑战：要么难以与目标受众保持一致，要么被不同利益相关者提出的所谓"最高优先级需求"清单所累。最终，最优秀的SaaS产品是那些能够预测客户需求变化并相应调整的产品。

然而，说起来容易做起来难。用户和内部反馈可能在不方便的时候以不方便的方式出现，除非建立正式的系统，否则会导致混乱。更重要的是，并非所有客户请求都具有同等重要性，确定哪些产品需求需要优先处理可能很棘手。

本文基于我作为高级产品经理17年的相关经验，帮助产品工程师系统化收集和优先处理客户反馈，制定清晰、有目的的产品开发路线图。这样，您就能将注意力集中在能为最终用户和公司利润带来最大影响的项目上。

获取客户需求洞察

产品工程师最糟糕的情况是与最终用户脱节。虽然团队可能有自己的改进想法，但必须密切关注现有客户的体验和行业整体优先级。

协作获取有价值的洞察

由于角色性质，客户成功经理（CSM）通常会收到关于可能改进和增强的有价值、坦诚的反馈。此外，他们分析客户的软件使用情况以提供个性化指导，同时也可以利用这个机会收集观察结果与产品工程团队分享。

我和产品工程同事的建议是：为CSM创建一个指定的电子邮件地址用于发送反馈，然后将这些反馈分发给整个团队。根据我们的经验，为CSM建立严格但方便的过程有助于防止客户反馈被遗忘或搁置。

一个好的经验法则是：产品工程和CSM之间必须保持开放、定期的沟通。

电子邮件的广泛分发是有益的，因为这意味着我们的响应时间更快。毕竟，在某些情况下，我们对软件的深入了解可以帮助CSM更好地服务客户。例如，如果用户寻求的解决方案已经存在，我们可以告知他们的联系人，提供快速解决方案。

在实施新变更前收集反馈

从构思到实施是一个漫长的过程。作为开发人员，您的目标是尽可能早和频繁地从用户和其他团队收集意见，以限制资源浪费。您应该准备的有用材料包括：

• 设计文档或交互式设计：这些材料详细说明了工具更新的细节，而无需在执行方面进行大量投资。产品团队可以向客户或利益相关者展示这些材料，听取他们的印象并收集反馈。产品工程师寻求关于设计、可用性、是否充分有效解决问题以及可以改进的其他方面的反馈。

• 进行可用性和A/B测试的测试版程序：在此过程中，产品工程师为愿意参与测试版程序的用户提前开启功能。早期的测试组通常是那些对特定增强功能表示兴趣的用户，然后扩大到包括其他现有客户，同时跟踪使用情况并收集反馈。

虽然CSM对于收集定性输入至关重要，但产品工程师还希望通过向所有测试用户分发调查来积累定量反馈。通过使用这两种数据收集形式，您可以获得对所有反馈的更全面视角。

一致文档的价值

一致的文档还有助于在产品更新的多个阶段进行可追溯性，因此多个团队成员可以回到相同的参考点（如JIRA票证、Google表格等）。将内部通信集中在同一论坛中，使每个人都能更容易地了解情况，最大限度地减少项目参与者之间的混淆。

如果没有用于积累和组织反馈的正式系统，重要的观察结果无疑会丢失或被遗忘。这是因为客户和内部输入可以通过多种方式传达（电子邮件、聊天机器人、Slack、调查、G2等外部审查网站等）。

此外，可能不清楚产品团队的哪个成员负责记录和评估这些观察结果。因此，您应该制定一个逐步的方法来编目反馈，并在团队中统一应用。

不可能立即对每个反馈采取行动。但是，如果您的产品工程团队决定推迟或跳过潜在项目，请不要删除任何相关文档（如客户投诉、产品审计等）。相反，保存这些注释并附上您决定不进行相关软件更新的理由。这样，如果您的团队改变主意，将来可以调用这些材料。

战略性优先排序项目

收集客户反馈只是故事的一半。产品工程领导需要对这些建议进行排序和优先排序，以创建符合公司整体战略并为客户提供最大价值的逻辑驱动路线图。

其中一种方法是通过R-I-C-E（覆盖范围、影响、信心和努力）的视角评估每个潜在项目。

• 覆盖范围（Reach）：确定新功能或升级是否适用于大多数当前或潜在受众。毕竟，SaaS产品工程不希望为个别用户创建定制解决方案。

• 影响（Impact）：修改将对产品和业务产生多大影响？在一端，您将拥有大多数会被忽视且产生最小可衡量结果的计划。在另一端，一些软件更新可能会完全改变业务的各个方面，从我们向新受众销售的能力到改进工具功能。

• 信心（Confidence）：团队对他们理解请求并能执行的信心有多大？信心低的原因有很多，例如请求完全超出产品的预期用途，或者在进一步分析之前可能需要解决的技术债务。

• 努力（Effort）：一些计划可能需要几个小时，其他可能需要几年。对于此练习，您不需要确定具体的时间表，而是使用通用的T恤尺码（如"特小、小、中、大或特大"）来衡量相对努力。请记住，这适用于前期工程和持续维护。

当您考虑R-I-C-E的所有元素时，您能够比较一个项目与另一个项目的感知投资回报率并相应地进行优先排序。影响项目优先排序的其他因素可能包括评估紧急性和随后的"技术债务"以及其他利益相关者对R-I-C-E的解释。

关于评估紧急性，产品工程专业人员经常面临选择快速解决方案还是正确解决方案的决定。在团队迅速推出比喻性的"创可贴"的情况下，这只是临时修复，为他们争取时间找到更永久的答案，并可能随着时间的推移创造更多的累积工作（技术债务）。

在其他内部利益相关者的帮助下，反思更新的紧急程度以及创建短期和长期解决方案的额外努力，以确定正确的行动方案。

至于其他利益相关者对R-I-C-E的解释，与客户成功和其他团队分享您的初始执行顺序以获得他们的批准。他们可能对潜在项目的覆盖范围和影响有不同的见解，进一步影响优先级水平。

这些项目元素可以指导团队的年度或季度路线图，以及确定这些产品修复是否足够小和/或足够紧急以证明立即采取行动是合理的。

衡量更新结果

产品工程并不是在成功发布更新后就完成了。使用专门的分析工具跟踪交互（在测试版和发布后阶段），寻找用户及其行为的模式。直接将更新前后的参与度水平进行比较，以形成（或验证）关于原因的假设。

如果产品更新带来了预期的结果，太好了！如果没有，您应该再次开始收集反馈和数据的循环，以创建新的假设，这些假设将为额外的更新提供信息。

通过系统化客户反馈、优先排序和影响衡量，您的团队将提高运营效率和决策背后的基础战略。结果是什么？一个能够战略性演进以更好地服务客户和市场需求的SaaS产品。