使用反馈和洞察信息来指导产品开发
在确定优先级的会议期间，如果能获得相关的洞察信息，就能极大地改变结果。洞察信息能使决策重点突出，与客户的需求和愿望相联系，并有据可依。
如果没有洞察信息，优先级的确定就不可避免地会陷入常见的陷阱：根据直觉做出决策、听取最响亮或最有说服力的意见，或者默认听取房间里最高级别领导的意见（也称为 HiPPO，薪酬最高人士的意见 🦛）。
这些意见都不会自动变为坏的，只是需要数据和证据的支持。对于产品团队来说，洞察信息就提供了证据。
什么是洞察信息？
洞察信息有多种形态和形式。所有这些都揭示了机遇、挑战和产品中潜在的改进领域。
支持团队发现的重复问题
销售团队发现的产品差距
来自客户的建议
来自不同部门员工的建议
市场研究和行业趋势
竞争分析和基准测试
头脑风暴会议和构思研讨会
领导层对公司战略和目标的意见
所有这些洞察信息都有各自的优缺点。为了做出出色的产品决策，您需要对所有这些洞察信息有一个平衡的认识。
为什么要使用洞察信息？
收集相关的洞察信息，并用它们来证实您的想法，让您的建议有可信度。这表明，您关心资源的有效利用，并将团队的辛勤工作引向能产生最大影响的地方。
洞察信息将想法与产品成果联系起来，使对话围绕客户需求和市场需求展开。这有助于您赢得团队、客户和领导层的信任，从而获得打造优秀产品所需的自主权。
每当优先顺序的讨论被嘈杂或令人信服的声音扰乱时，请遵从洞察信息，重新回到正轨。
如果过度依赖销售团队的反馈，就可能错过现有客户的重要摩擦点。同样，过度依赖领导层的反馈也会使您把精力放在赢得新客户的新战略赌注上，而不是改善目前的产品体验。这两种情况都可能导致现有客户流失。
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 Product Discovery 团队，我们从以下渠道收集洞察信息：
使用 Jira Service Management 的应用内反馈收集器
Slack 中面向客户的团队的内部反馈渠道
Dovetail 中的用户访谈存储库
Atlassian 社区内的社区群组
使用 Pendo 进行的产品分析
使用 Pendo 进行的应用内调查
Confluence 中的 Atlassian 知识存储库
从入站反馈中收集洞察信息
入站反馈（积极使用您产品的用户的疑虑、评论和问题）是您最重要的洞察信息来源之一。
在 Jira Product Discovery 中，我们有多个专用渠道用来收集和管理这些入站反馈。这样做有几个好处：
您可以为用户提供分享反馈的专用渠道，如门户或嵌入在应用中的反馈收集小工具。
您可以获得处理反馈的专用区域。这样可以保持产品待办事项的整洁和独立—这意味着产品团队能够决定哪些内容将以何种形式（新想法或添加到现有想法的洞察信息）包含在产品待办事项中。
您可以与报告人就他们的反馈进行对话，为下一步行动设定期望，或者与他们反复交流—如果您需要更多细节，或者您想主动与他们进行 Zoom 聊天，这都非常好。
在发布根据用户反馈产生的功能时，可以通知留下反馈的用户，从而实现反馈闭环。
使用 Jira Service Management 收集反馈
在 Jira Product Discovery 团队中，我们使用 Jira Service Management 让客户和最终用户直接分享非结构化反馈：
用户使用 Jira Service Management 嵌入式小工具直接从 Jira Product Discovery 中发送反馈。
这些反馈会进入 Jira Service Management 队列，团队中的 PM 每周会查看几次。
我们通过评论与用户直接讨论反馈，然后使用 Jira Product Discovery Chrome 扩展程序将其作为“洞察信息”添加到相关的“想法”中。
我们每周都会在 Jira Product Discovery 中以团队的形式审查这些新增内容，讨论来自用户反馈的新想法和洞察信息。
您可以在资源部分找到如何设置 Jira Service Management 队列以接收客户和内部团队反馈的演示。
通过专用 Slack 频道收集反馈
对于内部利益相关者，我们在 Slack 和 Teams 中创建了专门的频道，供他们提问和提出建议。我们对这些建议进行分类，然后使用 Jira Slack 应用将它们作为“洞察信息”添加到“想法”中。
这样，我们的团队就不会通过多个渠道收到过多的直接消息、问题和请求，从而避免了容易遗漏和难以组织的情况。
利益相关者花了一些时间才习惯在这里提问，不再直接给我们发消息，但是一旦流程建立起来，效率就会非常高。
我们有三个不同的专用反馈渠道：
#help-jpd-dogfooders，供 Jira Product Discovery 的内部用户使用
#help-jpd-sales 和 #help-jpd-support，当销售和支持团队在与客户和潜在客户讨论需要帮助时供他们使用
您可以在资源部分找到如何设置专门的产品反馈 Slack 或 Teams 频道以接收内部团队反馈的演示。
通过专用 Jira Product Discovery 项目收集反馈
虽然 Jira Product Discovery 团队不使用这种方法，但我们的许多客户都设立了专门的 Jira Product Discovery 项目，用于承接反馈。
这是一个独立于产品和交付待办事项的专用空间，贡献者可以在这里创建自己的想法，为其他想法添加评论和洞察信息，并对彼此的贡献进行投票。
只要您有好的方法在专用项目中执行好的做法，这种方法就会非常有效。否则，它很快就会变成一连串大大小小的要求清单，其中不乏重复和冗余。
但是，经过精心设置，在利益相关者数量有限、想法数量可控的情况下，我们已经看到这种方法取得了很好的效果。
以下是如何在 Jira Product Discovery 中设置反馈承接项目的方法：
为想法承接表单创建自己的模板。将特定字段添加到要使用的视图中，从而定义所需的信息。
选择谁可以创建想法，并将其添加为项目的贡献者
创建视图，使贡献者可以使用投票、评论和添加“洞察信息”等设置方法提供意见。
通过用户研究收集洞察信息
入站反馈可让您很好地了解产品可以改进的一般领域。但仅靠这些反馈还不足以指导您的产品决策。尤其是，它缺乏上下文。
从单一的用户反馈或功能请求中，您很难拼凑出整个故事：
用户面临的根本问题
这个问题对他们的工作流有多重要
它如何影响产品的其余部分
不同的解决方案能否解决他们的问题
对于所有这些问题以及更多问题，没有什么比与用户定期对话更好的了。
招募合适的用户参与研究可能很困难。但是，如果您有一个入站反馈或调查问卷解决方案，您就可以将其作为一个渠道来识别可以成为富有成效的研究对象的用户，并与他们取得联系，提供聊天机会。
使用 Dovetail 进行用户研究
在 Jira Product Discovery 团队中，我们主要依靠 Zoom 会议，因为我们都是远程办公，而且客户群遍布全球。当客户在我们的某个渠道（应用内反馈小工具或社区群组）中留下有趣的反馈时，我们会通过 Calendly 链接与他们联系，邀请他们与我们预约时间。
在征得受访者同意后，我们会录制这些会面并上传到 Dovetail。在那里，我们可以标记对话中的重要时刻，并将其作为“洞察信息”添加到相关“想法”中。
随着时间的推移，我们就这样找到了灯塔用户，他们帮助我们塑造了今天的 Jira Product Discovery。
此外，我们还发现，与基于文本的文档相比，一段 3 分钟谈论客户困境的视频是与团队和利益相关者沟通的更有影响力的方式。
利用研究报告进行用户研究
对于某些主题，最好依靠更深入的用户研究。在 Atlassian，我们很幸运拥有一支研究与洞察信息团队，他们深入研究特定主题，使用严格的研究技术将其提炼为“洞察信息”。
例如，最近一位研究人员帮助我们了解了 Jira Product Discovery 评估人员的摩擦点。我们将这份报告中的“洞察信息”标记为 Jira Product Discovery 中的“想法”，并利用这些成果重新思考评估人员如何在应用中上岗。
通过调查问卷收集洞察信息
对于产品团队来说，调查问卷是一个很好的工具，可用于：
通过提问收集用户反馈
测试和验证假设
根据洞察信息而非意见解决内部争论
我们注意到，与客户自行发送快速入站反馈相比，他们往往会花更多时间思考和撰写深思熟虑的反馈调查问卷。
使用 Pendo 创建用户调查问卷
在 Jira Product Discovery 团队中，我们使用 Pendo 根据细分和产品使用数据为特定用户群创建调查问卷。
我们有经常性的定期调查问卷，如每月 CSAT 问卷，也有为回答特定问题而发送的一次性调查问卷。通常情况下，这些问题一旦出错就会对产品产生深远影响，因此我们需要清晰、及时的数据。
我们在 Confluence 页面中总结调查问卷结果，并将其作为“洞察信息”添加到相关“想法”中。
建立社区群组以收集洞察信息
社区群组可以成为召集用户和获取反馈的有效途径。您可以利用这些群组来回答有关产品的问题，为新功能招募早期采用者，发布公告，分享最佳实践等。
Atlassian 的社区群组
自 Jira Product Discovery 推出以来，我们一直依靠 Jira Product Discovery 群组（Atlassian 社区的一个子群组）与用户直接互动。随着时间的推移，我们看到高级用户开始支持其他用户并分享他们对产品的心得—我们从这些对话中学到了很多。
通过帮助我们验证我们的假设，这种方法不止一次地改变了我们的方向。
例如，当我们首次宣布 Jira Product Discovery 的定价时，我们得到了令人惊讶的回应。一些公司正在以我们没有考虑到的方式使用贡献者，而这种定价对于他们的需求来说是难以承受的。
我们立即进行了调整，为贡献者角色添加了免费功能，以支持这些用例。我们的产品待办事项中充满了这样的洞察信息，这些洞察信息来自社区群组的讨论。
从产品分析中收集洞察信息
最后，在评估洞察信息和决定如何采取行动时，必须考虑定量数据和定性用户反馈。
产品分析可以提供两个粒度级别的洞察信息：
增长指标，例如流失率和客户终身价值。
例如，如果您发现评估者未能转化为活跃用户，并且在第一次会话后就流失了，那么您很可能应该暂停实施新功能，并检查一下您的引导流程。
功能使用情况和用户行为数据。
例如，如果您收到了很多关于某项功能的负面反馈，而且数据显示该功能并没有被很多人使用，那么这就是讨论该功能是值得保留还是应该淘汰的好时机。
使用产品分析工具收集洞察信息
显然，各公司使用的产品分析工具会有所不同。在 Jira Product Discovery 团队中，我们使用 Amplitude 和 Pendo 来进行产品分析。特别是，我们用它来跟踪使用情况、功能的受欢迎程度以及用户如何与我们的引导流程进行交互。同样，我们将关键“洞察信息”添加到我们产品待办事项的“想法”中。
让讨论洞察信息成为一种习惯
产品团队每天都要做出决策。为了使这些决策尽可能多地以客户数据为基础，他们必须持续不断地使用洞察信息。
无论您决定使用哪种反馈和研究渠道，为了让它们发挥作用，您的团队都必须将收集洞察信息并据其采取行动作为一项持续的实践。如果团队每个月只参与一次客户反馈，那么在没有及时听取客户意见的情况，他们就只能做一个月的决策。
正如 Teresa Torres 在《持续发现习惯》一书中分享的那样，在产品决策中使用洞察信息有很多好处：
更好地协调一致。
团队成员知道他们为什么要做某件事情，并对用户关心什么有共同的理解。
基于证据的优先级排序。
团队根据随时间推移收集的洞察信息确定优先次序。决定投资方向变得更加客观。
更容易绘制路线图。
明确投资领域变得简单明了，随时间推移收集的洞察信息为潜在的投资领域提供了有力的证据。明智的资源分配变得清晰明了，让您能以明智的方式做出权衡。
提高利益相关者的参与度。
对客户需求和优先事项的清晰描述是不言而喻的。团队可以轻松地向利益相关者传达这一描述，重构有关客户困难和影响的对话。
在 Jira Product Discovery 中讨论洞察信息
在 Jira Product Discovery 团队中，我们使用两种例行程序让持续发现成为一种习惯：
每周“反馈轮换”任务：
每周，产品团队都会指派一人进行“反馈轮换”。他们会查看我们的渠道，对反馈做出回应，并将相关“洞察信息”添加到“想法”中。这通常需要半天的时间，在一周内完成。
每周“数据浴”会议：
在该团队会议上，我们会回顾当周的反馈，讨论心得和收获。会议结束后，我们正式将“反馈轮换”任务移交给下一位产品经理。
由于我们一直在持续开展这项工作，因此我们为所有优先级排序讨论做好了准备，并掌握了大量新情况。
灯塔用户
如果您收到许多客户的反馈，您应该听取谁的意见？
在 Atlassian，我们有 30 多万个客户。仅在 Jira Product Discovery 团队，我们每周就会收到数十条关于产品的反馈。直接处理他们的所有反馈，更不用说采取行动了，这是不可能的。
入站用户反馈让我们了解到人们在使用产品时遇到的问题类型，以及哪些问题更为普遍。这些反馈为产品想法提供了依据，但我们不会仅根据这些反馈来设计解决方案。
相反，在开发、迭代和交付解决方案的过程中，我们通常会与一小群专门的用户合作。我们与他们一起为他们打造产品体验，倾听他们高度详尽、有针对性的反馈意见。
我们称这些测试群组为“灯塔用户”。根据我们的经验，10 个灯塔用户就足够了。
为什么要与灯塔用户合作？
根据我们的经验，与“灯塔用户”合作比同时取悦成千上万的用户效果更好。
我们的工作进展更快，因为我们可以在与少数人讨论的基础上做出决定。我们不需要调查 1000 名用户就能做出决定。我们可以先让灯塔用户使用原型，从而尽早测试产品体验。这些用户知道该期待什么：可能会有未涵盖的缺陷和极端情况。
我们可以获得丰富的背景洞察信息，因为我们已经与这些用户建立了融洽的关系，了解了他们的问题和动机。与熟悉的用户进行多次对话，往往比与许多人进行一次对话更有影响力。
这能激发整个团队的紧迫感，因为他们能从人的角度了解灯塔用户，并希望提供帮助。将灯塔用户介绍给整个团队，能增强他们的紧迫感和主人翁意识。为他们关心的人解决问题，比研究报告更能激发他们的动力。
如何选择灯塔用户
如果您决定采用这种工作方式，您必须非常清楚哪些人适合成为灯塔用户。如果选择错误，最终可能会为错误的人打造错误的产品。
随着时间的推移，在 Jira Product Discovery 中，我们发现灯塔用户具有以下共同特征：
✅ 非常清晰的沟通者
✅ 存在于我们的目标客户群中，即使我们仍在对目标客户群进行迭代
✅ 深受我们试图解决的问题和痛点的影响
✅ 试图找到解决这一痛点的新方法，但至今未获成功
✅ 不使用竞争性应用，因此我们不会以复制功能为讨论中心
✅ 对新的和不同的工作方式持开放态度，而不是寻求特定功能
✅ 乐于使用早期产品或功能，分享反馈并讨论解决方案
为什么要与灯塔用户合作
我们与灯塔用户通力合作。从根本上说，我们将他们视为解决方案的共同创造者。
我们设立了专门的 Slack 频道，供他们分享反馈和问题
我们每月召开一次会议，讨论他们的产品和产品管理经验
我们与他们分享早期设计，获取他们的反馈
我们让他们抢先体验产品和功能，获得体验
我们询问他们如何自己设计解决方案
有关灯塔用户的更多信息，请参阅 Atlassian 社区上的这一系列文章。
后续事项
通过将所有决策建立在洞察信息的基础上，产品团队可以将工作重点放在最终目标上—解决用户的问题，让他们的生活更轻松。
在本手册的最后两节中，我们将详细介绍如何使用产品待办事项来完成以下工作：
我们将举例说明我们如何在 Jira Product Discovery 团队中使用 Jira Product Discovery 和其他产品来做到这一点。