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

为什么要使用洞察信息？

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

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

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

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 社区的一个子群组）与用户直接互动。随着时间的推移，我们看到高级用户开始支持其他用户并分享他们对产品的心得—我们从这些对话中学到了很多。

Gathering insights from product analytics

Finally, it’s important to consider quantitative data, as well as qualitative user feedback, when evaluating insights and deciding how to act on them.

Product analytics can provide insights at two levels of granularity:

1. Growth metrics, like churn rate and customer LTV.
   
   For example, if you notice that evaluators fail to convert to active users and drop off after their first session, it’s very likely you should take a break from implementing new features and take a look at your onboarding flow.
2. Feature usage and user behavior data.
   
   For example, if you receive a lot of negative feedback about a feature, and data reveals it’s not used by many people, it’s a good time to discuss whether it’s worth keeping or should be retired.

Using your product analytics tools to glean insights

Obviously, the product analytics tools used will vary from company to company. On the Jira Product Discovery team, we use both Amplitude and Pendo for this purpose. In particular, we use it to track utilization, the popularity of features, and how users interact with our onboarding flows. And again, we add key Insights to Ideas in our product backlog.

Make discussing insights a habit

Product teams make decisions every day. To ground as many of those decisions as possible in customer data, they must work with insights on an ongoing basis.

Regardless of which feedback and research channels you decide to use, for them to work your team must make collecting and acting on insights a continuous practice. If teams only engage with customer feedback once a month, they’re making a month’s worth of decisions without timely customer input.

As shared by Teresa Torres in Continuous Discovery Habits, using insights in product decision-making has many benefits:

1. Better alignment.
   
   Team members know why they’re working on something, and have a shared understanding of what users care about.
2. Evidence-based prioritization.
   
   Teams prioritize based on insights they’ve gathered over time. Deciding where to invest becomes much more objective.
3. Easier roadmapping.
   
   Clarifying investment areas becomes straighforward, and nsights gathered over time provide weight to potential areas of investment. Wise resource allocation becomes clear and trade-offs can be made in an informed way.
4. Better stakeholder engagement.
   
   A clear narrative about customer needs and priorities is self-evident. Teams easily communicate this narrative to stakeholders, reframing conversations around customer struggles and impact.

Discussing insights at Jira Product Discovery

On the Jira Product Discovery team, we use two rituals to make continuous discovery a habit:

• Weekly “feedback rotation” assignment:

Each week, a person on the product team is assigned to “feedback rotation.” They look at our channels, respond to feedback and add relevant Insights to Ideas. This usually takes about a half day of effort, spread through the week.

• Weekly “data bath” meeting:

In this team meeting, we go over that week’s feedback to discuss learnings and takeaways. At the end of that meeting, we officially pass over the “feedback rotation” assignent to the next product manager.

Because we’ve done this work on an ongoing basis, we’re prepared for all prioritization discussions with plenty of fresh context.

If you receive feedback from many customers, who should you listen to?

At Atlassian, we have more than 300,000 customers. On the Jira Product Discovery team alone, we receive dozens of individual pieces of feedback about the product every week. Working with all their feedback directly, let alone acting on it, would be impossible.

Inbound user feedback gives us a sense for the types of issues people face when using the product, and which ones are more pervasive. This feedback informs product Ideas, but we don’t design solutions based on that feedback alone.

Instead, as we develop, iterate, and ship solutions, we typically work with a small, dedicated group of users. We build product experiences with and for them, listening to their highly detailed, targeted feedback.

We call these test groups “lighthouse users”. In our experience, 10 lighthouse users is enough.

Why work with lighthouse users?

In our experience, working with lighthouse users works better than trying to please thousands of users all at once.

• We move faster, because we can make decisions based on discussions with a small number of people.
  
  We don’t need to survey 1000 users to get to a decision. We can test product experiences early by giving lighthouse users prototype access before anyone else. These users know what to expect: there may be bugs and corner cases that are not covered.
• We get rich contextual insights, because we’ve built rapport with these users to understand their problems and motivations.
  
  It’s often more impactful to have multiple conversations with a user you know well, than to have a single conversation with many people.
• It drives urgency across the whole team, because they know our lighthouse users as people and want to help.
  
  Introducing lighthouse users to the whole team drives their sense of urgency and ownership. Solving problems for one person they care about is much more motivating than a research report.

How to select lighthouse users

If you decide to adopt this way of working, you must be very clear on who is a good fit as lighthouse users. If you choose wrong, you could end us building the wrong product for the wrong people.

Over time at Jira Product Discovery, we’ve found that our lighthouse users share the following attributes:

✅ Very clear communicators

✅ In our target customer segment, even if we’re still iterating on what that is

✅ Strongly affected by the problems and pain points we’re trying to solve

✅ Trying to find new ways to solve this pain point, so far without success

✅ Not using a competing app, so we don’t center discussions on replicating features

✅ Open to new and different ways of working, instead of looking for specific features

✅ Happy to use an early-stage product or feature, share feedback, and discuss solutions

Working with lighthouse users

We really go all in to collaborate with lighthouse users. Essentially, we treat them as co-creators of the solution.

• We set up dedicated Slack channels where they can share feedback and questions
• We meet monthly to discuss their product, and product management, experiences
• We share early designs with them and get their feedback
• We give them early access to products, experiences, and features
• We ask how they’d design the solution themselves

For more information about lighthouse users, see this series of posts on the Atlassian Community.

后续事项

By grounding all their decisions in Insights, product teams can keep their work focused on its ultimate goal — solving users’ problems and making their lives easier.

In the final two sections of this handbook, we’ll explain in detail how to use a product backlog to:

• Prioritize the ideas that can make an impact
• Create roadmaps your teams and stakeholders can rally behind

We’ll give examples for how we do this in the Jira Product Discovery team, using Jira Product Discovery and other products.