如何基于用户需求演进SaaS产品

作者：Teresa Hoffman

产品工程团队常常难以与目标用户保持一致，或被不同利益相关者提出的所谓“最高优先级需求”所拖累。最终，最优秀的SaaS产品是那些能够预见客户需求变化并做出相应调整的产品。

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

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

获取客户需求洞察

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

协作获取有意义的见解

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

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

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

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

在实施新变更前收集反馈

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

• 设计文档或交互式设计：这些蓝图详细说明了工具更新的细节，而无需在执行上投入大量资源。产品团队可以向客户或利益相关者展示这些材料，听取他们的印象并收集反馈。产品工程师努力获取关于设计、可用性、是否充分有效地解决问题以及可以改进的其他领域的反馈。
• 进行可用性和A/B测试的Beta程序：在此练习中，产品工程师为愿意参与Beta程序的用户提前开启功能。早期的Beta群体通常是那些对特定增强功能表示兴趣的人，然后扩大到包括其他现有客户，同时跟踪使用情况并收集反馈。

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

一致文档的价值

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

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

此外，可能不清楚产品团队的哪个成员负责记录和评估这些观察结果。因此，您应概述一个逐步的方法，用于在整个团队中统一应用反馈分类。

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

战略性地优先处理项目

收集客户反馈只是故事的一半。产品工程领导需要排序和优先处理建议，以创建一个逻辑驱动的路线图，与公司整体战略保持一致，并为客户提供最大价值。

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

• 覆盖范围（Reach）：确定新功能或升级是否适用于大多数当前或潜在受众。毕竟，SaaS产品工程不希望为个别用户创建定制解决方案。
• 影响（Impact）：修改将对产品和业务产生多大影响？在一端，您将有一些倡议被大多数人忽视，并产生最小的可衡量结果。在另一端，一些软件更新可能完全改变业务的元素，从我们向新受众销售的能力到改进的工具功能。
• 信心（Confidence）：团队对他们既理解请求又能执行它有多大信心？低信心的原因有很多，例如请求远远超出产品的预期用途，或者可能需要在进一步分析之前解决的技术债务。
• 努力（Effort）：一些倡议可能需要几个小时，其他可能需要几年。对于此练习，您不需要确定具体的时间表，而是使用通用的T恤尺码，如“特小、小、中、大或特大”来衡量相对努力。请记住，这适用于前期工程和持续维护。

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

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

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

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

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

衡量更新的结果

产品工程在成功启动更新后并未结束。使用专门的分析工具跟踪交互（在Beta和发布后阶段），寻找用户及其行为的模式。直接比较更新前和更新后的参与水平，以形成（或验证）关于原因的假设。

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

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