如何处理并非来自用户访谈的产品建议

与客户的定期接触是持续发现的支柱。如果您不经常与客户直接交谈,则会增加开发出的产品没人用的风险。

然而,除了用户访谈,客户反馈和和功能建议等也会通过其他途径源源不断的涌现出来。客户成功和销售团队每天都在直接听取客户的意见,支持和售后团队有源源不断的工单,这些工单描绘了产品存在的问题。还有些分析工具或用户调查来监控客户行为并直接从客户那里收集反馈。

来自其他团队的同事可能会很兴奋地传达他们从客户那里听到的信息,有可能是是投诉,有可能是功能请求,甚至是表扬。但是,这些见解并不完全算作客户访谈,因此许多产品团队想知道如何处理这些信息并采取行动。

产品组绝对应该监控这些其他来源的需求。我们可以从工单、销售对话、行为分析和许多其他输入中学到很多东西,麻烦在于这些信息不够全面。一位客户提交了一份支持请求,要求提出某某功能,但我们不知道他们为什么需要这个功能?它将帮助他们完成什么?他们什么时候需要它?如果没有些场景信息,就很难设计这些需求。

我们也不知道还有谁需要该功能。我们可能有几个客户要求听起来像相同的功能,但没有很多上下文,我们真的不知道他们为什么需要它,或他们可能如何使用它。即使客户要求相同的功能,他们的事迹需求也可能不同。

更糟糕的是,我们经常看到客户要求增加不同的功能来满足他们相同的需求。这导致我们不停的堆砌功能。发生这种情况是因为客户并不总是知道满足自己需求的最佳解决方案。因此,每个功能请求都代表了他们的需求,但没有一个是理想的解决方案。在这种情况下,我们通常会开发一些对任何人都不起作用的功能,然而我们本可以构建一个适合所有人的解决方案。

不要指望您的销售团队知道如何收集用户故事

并非所有销售人员都擅长从客户那里收集背景信息,这没关系。 我们仍然可以使用他们分享的见解来指导我们与客户的对话。

一些销售人员擅长获取背景信息。 当潜在客户要求特定功能时,有些人会深入研究其背后的原因。 他们可能会问:“该功能对您有什么作用?“ 这种情况会有所帮助。 但是这个问题会导致客户推测他们未来的行为。 而且我们已经知道这不是获得客户反馈的好方法。 我几乎没有遇到参与过用户故事培训的销售人员,他们可以收集功能请求背后的完整背景。毕竟,这不是他们的工作,这是我们的。

行为分析告诉我们一些事情——但不是所有事情

行为分析是了解客户行为的绝佳窗口。 这个窗口可以告诉我们客户在做什么,但不能告诉我们他们为什么这样做。 分析缺少很多上下文。 客户想要完成什么? 他们是否足够了解我们的产品以实现这一目标? 他们的行为是否代表了一条成功的路径;或者他们只是在徘徊,试图找到这条路径?

其他来源无法取代用户访谈,但它们可以帮助指导我们与客户的对话

虽然我们不应该使用其他信息来源作为用户访谈的替代品,但我们可以将这些作为灵感来指导我们在接下来的采访中探索的内容。

如果客户一遍又一遍地要求某项功能,请与他们面谈。问他们的这些需求是要完成是什么事情,达到什么目标。如果工单表明存在未解决的痛点,请采访这些客户。当他们遇到那个痛点时,找出他们当时在做什么。当您的行为分析指向有趣的行为时,请与一些表现出该行为的客户交谈。

采访是了解完整背景的最有效方法之一,但不是唯一的。您还可以通过观察客户来获取完整的上下文。我提倡对客户进行采访的原因是因为它是每周一次更可持续的活动。这并不意味着你不应该进行观察。

如果您想确保您的产品反映了现实的需求,我建议您将产品需求限制在您能够在用户访谈中直接探索或您能够亲自观察到的需求上。

原文:https://www.producttalk.org/2022/06/other-insights

# #


《 “如何处理并非来自用户访谈的产品建议” 》 有 0 条评论

  1. wannz说道:

    cool

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注