使用反馈和洞察信息来指导产品开发

为什么要使用洞察信息？

收集相关的洞察信息，并用它们来证实您的想法，让您的建议有可信度。这表明，您关心资源的有效利用，并将团队的辛勤工作引向能产生最大影响的地方。

洞察信息将想法与产品成果联系起来，使对话围绕客户需求和市场需求展开。这有助于您赢得团队、客户和领导层的信任，从而获得打造优秀产品所需的自主权。

每当优先顺序的讨论被嘈杂或令人信服的声音扰乱时，请遵从洞察信息，重新回到正轨。

Jira Product Discovery 的洞察信息

在 Jira Product Discovery 中，洞察信息是每个想法不可或缺的一部分。养成使用 Jira Product Discovery Chrome 扩展程序、我们的 Slack 或 Teams 应用或我们的合作伙伴构建的集成之一，为想法添加相关洞察信息的习惯。

将 Jira Product Discovery 与您的支持、销售、研究和反馈管理解决方案结合使用。我们设计了 Jira Product Discovery，这样您就可以将相关反馈和洞察信息添加到“想法”中，并解释它们为何重要、应如何确定优先级以及它们意味着什么。

然后，当您开始讨论优先级时，这些洞察信息就会唾手可得。

设置收集洞察信息的渠道

如果您还没有足够的洞察信息来指导您的决策，那么现在开始收集也为时不晚。当您有持续的流程来收集这些数据时，您就能将其提炼为支持每个产品决策所需的洞察信息。

在本章中，我们将介绍如何与客户和面向客户的团队建立直接沟通渠道，并开始收集自己在研究过程中遇到的数据。

我们建议设置多个渠道来收集洞察信息：

Jira Product Discovery 团队如何收集洞察信息

构建 Jira Product Discovery 的整个过程是通过收集洞察信息塑造和指导的。在本节的其余部分，我们将向您展示 Jira Product Discovery 团队是如何建立反馈渠道，并利用这些渠道为我们的产品工作提供依据的。

从入站反馈中收集洞察信息

入站反馈（积极使用您产品的用户的疑虑、评论和问题）是您最重要的洞察信息来源之一。

使用 Jira Service Management 收集反馈

在 Jira Product Discovery 团队中，我们使用 Jira Service Management 让客户和最终用户直接分享非结构化反馈：

通过专用 Slack 频道收集反馈

对于内部利益相关者，我们在 Slack 和 Teams 中创建了专门的频道，供他们提问和提出建议。我们对这些建议进行分类，然后使用 Jira Slack 应用将它们作为“洞察信息”添加到“想法”中。

通过专用 Jira Product Discovery 项目收集反馈

虽然 Jira Product Discovery 团队不使用这种方法，但我们的许多客户都设立了专门的 Jira Product Discovery 项目，用于承接反馈。

这是一个独立于产品和交付待办事项的专用空间，贡献者可以在这里创建自己的想法，为其他想法添加评论和洞察信息，并对彼此的贡献进行投票。

只要您有好的方法在专用项目中执行好的做法，这种方法就会非常有效。否则，它很快就会变成一连串大大小小的要求清单，其中不乏重复和冗余。

但是，经过精心设置，在利益相关者数量有限、想法数量可控的情况下，我们已经看到这种方法取得了很好的效果。

通过用户研究收集洞察信息

入站反馈可让您很好地了解产品可以改进的一般领域。但仅靠这些反馈还不足以指导您的产品决策。尤其是，它缺乏上下文。

从单一的用户反馈或功能请求中，您很难拼凑出整个故事：

• 用户面临的根本问题
• 这个问题对他们的工作流有多重要
• 它如何影响产品的其余部分
• 不同的解决方案能否解决他们的问题

对于所有这些问题以及更多问题，没有什么比与用户定期对话更好的了。

招募合适的用户参与研究可能很困难。但是，如果您有一个入站反馈或调查问卷解决方案，您就可以将其作为一个渠道来识别可以成为富有成效的研究对象的用户，并与他们取得联系，提供聊天机会。

使用 Dovetail 进行用户研究

在 Jira Product Discovery 团队中，我们主要依靠 Zoom 会议，因为我们都是远程办公，而且客户群遍布全球。当客户在我们的某个渠道（应用内反馈小工具或社区群组）中留下有趣的反馈时，我们会通过 Calendly 链接与他们联系，邀请他们与我们预约时间。

在征得受访者同意后，我们会录制这些会面并上传到 Dovetail。在那里，我们可以标记对话中的重要时刻，并将其作为“洞察信息”添加到相关“想法”中。

随着时间的推移，我们就这样找到了灯塔用户，他们帮助我们塑造了今天的 Jira Product Discovery。

利用研究报告进行用户研究

对于某些主题，最好依靠更深入的用户研究。在 Atlassian，我们很幸运拥有一支研究与洞察信息团队，他们深入研究特定主题，使用严格的研究技术将其提炼为“洞察信息”。

例如，最近一位研究人员帮助我们了解了 Jira Product Discovery 评估人员的摩擦点。我们将这份报告中的“洞察信息”标记为 Jira Product Discovery 中的“想法”，并利用这些成果重新思考评估人员如何在应用中上岗。

使用 Pendo 创建用户调查问卷

在 Jira Product Discovery 团队中，我们使用 Pendo 根据细分和产品使用数据为特定用户群创建调查问卷。

我们有经常性的定期调查问卷，如每月 CSAT 问卷，也有为回答特定问题而发送的一次性调查问卷。通常情况下，这些问题一旦出错就会对产品产生深远影响，因此我们需要清晰、及时的数据。

我们在 Confluence 页面中总结调查问卷结果，并将其作为“洞察信息”添加到相关“想法”中。

建立社区群组以收集洞察信息

社区群组可以成为召集用户和获取反馈的有效途径。您可以利用这些群组来回答有关产品的问题，为新功能招募早期采用者，发布公告，分享最佳实践等。

Atlassian 的社区群组

自 Jira Product Discovery 推出以来，我们一直依靠 Jira Product Discovery 群组（Atlassian 社区的一个子群组）与用户直接互动。随着时间的推移，我们看到高级用户开始支持其他用户并分享他们对产品的心得—我们从这些对话中学到了很多。

从产品分析中收集洞察信息

最后，在评估洞察信息和决定如何采取行动时，必须考虑定量数据和定性用户反馈。

产品分析可以提供两个粒度级别的洞察信息：

1. 增长指标，例如流失率和客户终身价值。
   
   例如，如果您发现评估者未能转化为活跃用户，并且在第一次会话后就流失了，那么您很可能应该暂停实施新功能，并检查一下您的引导流程。
2. 功能使用情况和用户行为数据。
   
   例如，如果您收到了很多关于某项功能的负面反馈，而且数据显示该功能并没有被很多人使用，那么这就是讨论该功能是值得保留还是应该淘汰的好时机。

使用产品分析工具收集洞察信息

显然，各公司使用的产品分析工具会有所不同。在 Jira Product Discovery 团队中，我们使用 Amplitude 和 Pendo 来进行产品分析。特别是，我们用它来跟踪使用情况、功能的受欢迎程度以及用户如何与我们的引导流程进行交互。同样，我们将关键“洞察信息”添加到我们产品待办事项的“想法”中。

让讨论洞察信息成为一种习惯

产品团队每天都要做出决策。为了使这些决策尽可能多地以客户数据为基础，他们必须持续不断地使用洞察信息。

无论您决定使用哪种反馈和研究渠道，为了让它们发挥作用，您的团队都必须将收集洞察信息并据其采取行动作为一项持续的实践。如果团队每个月只参与一次客户反馈，那么在没有及时听取客户意见的情况，他们就只能做一个月的决策。

正如 Teresa Torres 在《持续发现习惯》一书中分享的那样，在产品决策中使用洞察信息有很多好处：

1. 更好地协调一致。
   
   团队成员知道他们为什么要做某件事情，并对用户关心什么有共同的理解。
2. 基于证据的优先级排序。
   
   团队根据随时间推移收集的洞察信息确定优先次序。决定投资方向变得更加客观。
3. 更容易绘制路线图。
   
   明确投资领域变得简单明了，随时间推移收集的洞察信息为潜在的投资领域提供了有力的证据。明智的资源分配变得清晰明了，让您能以明智的方式做出权衡。
4. 提高利益相关者的参与度。
   
   对客户需求和优先事项的清晰描述是不言而喻的。团队可以轻松地向利益相关者传达这一描述，重构有关客户困难和影响的对话。

在 Jira Product Discovery 中讨论洞察信息

在 Jira Product Discovery 团队中，我们使用两种例行程序让持续发现成为一种习惯：

• 每周“反馈轮换”任务：

每周，产品团队都会指派一人进行“反馈轮换”。他们会查看我们的渠道，对反馈做出回应，并将相关“洞察信息”添加到“想法”中。这通常需要半天的时间，在一周内完成。

• 每周“数据浴”会议：

在该团队会议上，我们会回顾当周的反馈，讨论心得和收获。会议结束后，我们正式将“反馈轮换”任务移交给下一位产品经理。

由于我们一直在持续开展这项工作，因此我们为所有优先级排序讨论做好了准备，并掌握了大量新情况。

如果您收到许多客户的反馈，您应该听取谁的意见？

在 Atlassian，我们有 30 多万个客户。仅在 Jira Product Discovery 团队，我们每周就会收到数十条关于产品的反馈。直接处理他们的所有反馈，更不用说采取行动了，这是不可能的。

入站用户反馈让我们了解到人们在使用产品时遇到的问题类型，以及哪些问题更为普遍。这些反馈为产品想法提供了依据，但我们不会仅根据这些反馈来设计解决方案。

相反，在开发、迭代和交付解决方案的过程中，我们通常会与一小群专门的用户合作。我们与他们一起为他们打造产品体验，倾听他们高度详尽、有针对性的反馈意见。

我们称这些测试群组为“灯塔用户”。根据我们的经验，10 个灯塔用户就足够了。

为什么要与灯塔用户合作？

根据我们的经验，与“灯塔用户”合作比同时取悦成千上万的用户效果更好。

• 我们的工作进展更快，因为我们可以在与少数人讨论的基础上做出决定。
  
  我们不需要调查 1000 名用户就能做出决定。我们可以先让灯塔用户使用原型，从而尽早测试产品体验。这些用户知道该期待什么：可能会有未涵盖的缺陷和极端情况。
• 我们可以获得丰富的背景洞察信息，因为我们已经与这些用户建立了融洽的关系，了解了他们的问题和动机。
  
  与熟悉的用户进行多次对话，往往比与许多人进行一次对话更有影响力。
• 这能激发整个团队的紧迫感，因为他们能从人的角度了解灯塔用户，并希望提供帮助。
  
  将灯塔用户介绍给整个团队，能增强他们的紧迫感和主人翁意识。为他们关心的人解决问题，比研究报告更能激发他们的动力。

如何选择灯塔用户

如果您决定采用这种工作方式，您必须非常清楚哪些人适合成为灯塔用户。如果选择错误，最终可能会为错误的人打造错误的产品。

随着时间的推移，在 Jira Product Discovery 中，我们发现灯塔用户具有以下共同特征：

✅ 非常清晰的沟通者

✅ 存在于我们的目标客户群中，即使我们仍在对目标客户群进行迭代

✅ 深受我们试图解决的问题和痛点的影响

✅ 试图找到解决这一痛点的新方法，但至今未获成功

✅ 不使用竞争性应用，因此我们不会以复制功能为讨论中心

✅ 对新的和不同的工作方式持开放态度，而不是寻求特定功能

✅ 乐于使用早期产品或功能，分享反馈并讨论解决方案

为什么要与灯塔用户合作

我们与灯塔用户通力合作。从根本上说，我们将他们视为解决方案的共同创造者。

• 我们设立了专门的 Slack 频道，供他们分享反馈和问题
• 我们每月召开一次会议，讨论他们的产品和产品管理经验
• 我们与他们分享早期设计，获取他们的反馈
• 我们让他们抢先体验产品和功能，获得体验
• 我们询问他们如何自己设计解决方案

有关灯塔用户的更多信息，请参阅 Atlassian 社区上的这一系列文章。

后续事项

通过将所有决策建立在洞察信息的基础上，产品团队可以将工作重点放在最终目标上—解决用户的问题，让他们的生活更轻松。

在本手册的最后两节中，我们将详细介绍如何使用产品待办事项来完成以下工作：

• 优先考虑能产生影响的想法
• 创建将团队和利益相关者团结起来的路线图

我们将举例说明我们如何在 Jira Product Discovery 团队中使用 Jira Product Discovery 和其他产品来做到这一点。