从开始到交付，用想法实现产品成果

在 Jira Product Discovery 中，“想法”是产品待办事项中使用的主要对象。为了支持不断验证和学习的过程，我们将想法作为长期对象使用—一个想法在开发开始时会离开待办事项列表，但在发现和交付的迭代过程中会一直存在，直到它产生所需的影响。

成功的产品团队会采用实验思维—他们会通过增加更多的背景、用户反馈、规范和设计来不断迭代想法。在想法生命周期的每个阶段，他们都会评估哪些有效，哪些无效，回答关键问题并验证他们的假设，以确保他们的投资与收到的反馈和验证相匹配。

从大到小的想法

虽然您在 Jira Product Discovery 中使用的对象名称是“想法”，但它们可以代表产品想法、机会、问题、解决方案等。产品待办事项可以设计为容纳多种不同形式和粒度级别的想法。

定义这些类别并让参与该过程的每个人都同意这些类别非常重要。这将防止产品待办事项成为一个从超级大到超级小的混合项目包，而没有分类和比较它们的框架。

巨石、岩石和卵石：对想法进行分类的一种方法

在 Jira Product Discovery 团队中，我们将想法分为三个级别：巨石、岩石和卵石。

巨石、岩石和卵石。

巨石：投资大，潜在回报高，但不确定性也高
- 示例：大型新赌注、新产品支柱、大型工程项目。
岩石：中等规模投资，风险较小
- 示例：新功能、新的引导实验、根据反馈重新设计
卵石：小规模、通常是直接的投资
- 示例：用户体验小改进、“剪纸”修复

我们的团队使用不同的视图来讨论这些不同类别的想法：

Jira Product Discovery 中的巨石视图。

Jira Product Discovery 中的岩石视图。

Jira Product Discovery 中的卵石视图。

想法的属性

在 Jira Product Discovery 中，每个想法都有一个单行摘要、详细描述、客户反馈等洞察信息，以及交付想法的 Jira 请求单链接。

Jira Product Discovery 中的想法。

Jira Product Discovery 中想法的交付面板。

为了尽可能有用和可操作，产品待办事项中的每个想法都应具备以下属性：

属性	它是什么？
摘要	它是什么？关于想法的一句话。
描述	它是什么？对机会、问题和解决方案的更详细描述。
字段	它是什么？想法的不同方面：有助于实现哪个目标、所处阶段、涉及产品的哪个部分、有助于确定优先级的信息（如影响或工作量）、指向规范或设计的链接。
洞察信息	它是什么？通过所有渠道获取的洞察信息：从用户反馈中获得的关键信息、客户对话和研究报告中的片段，或清晰阐述该想法为何重要的产品分析。
交付	它是什么？指向 Jira（长篇故事或计划）中交付工作的交付请求单的链接，用于实际交付产品想法。

为每个想法收集所有这些信息可能都需要时间。起初，想法在进入您的待办事项列表时可能只是一句话的摘要，例如在与客户对话时收集到的洞察信息。随着时间的推移，您会根据用户访谈、销售或支持部门的反馈，或公司战略的变化，收集到更多关于它的洞察信息。

包含一段用户反馈的一句话。

包含用户反馈和潜在影响分析。

包含经过验证的解决方案和进展顺利的交付。

有两种方法可以描述想法：直接在 Jira Product Discovery 中，或通过将 Confluence 链接到团队的 Jira Product Discovery 项目。

在 Jira Product Discovery 中，在想法的描述字段中写入摘要或定义。使用提供的模板之一，或创建您自己的模板，为描述与想法相关的问题、解决方案、假设等提供一致的公式。

Jira Product Discovery 中描述的想法。

如果您的团队也使用 Confluence，您可以将想法链接到 Confluence 页面：可以在想法的描述中，也可以使用自定义超链接字段。这种方法的好处是，您可以利用 Confluence 的所有协作功能，如内联评论。

描述本身的内容取决于想法的类型和阶段。

在链接的 Confluence 页面上描述的想法。

想法生命周期

与想法内容同样重要的是它如何随时间演变。因此，为每个想法定义所经历的生命周期的清晰阶段很重要。有了描述想法生命周期各个阶段的通用词汇，无论是在团队内部还是与利益相关者的对话都会更有成效。

在 Atlassian，我们使用四个阶段：深思、探索、创造和影响。在 Atlassian，每个人都知道这些阶段的含义。对于每个阶段，我们都知道团队正在从事什么类型的工作，应该提出什么样的问题，以及团队可能需要什么类型的帮助。这种一致性适用于团队内部讨论、与其他团队讨论或与高层领导讨论。

在构建 Jira Product Discovery 时，我们的团队使用这种方法来开发、验证和交付我们的想法。对于每个生命周期阶段，我们将解释我们的团队是如何将其付诸实践的。

深思、探索、创造、影响

在进入这个生命周期之前，每个想法都要从暂存区开始。在这个阶段，它们通常只是一句话的摘要，其中包含导致它们产生的洞察信息。这些洞察信息可能来自研讨会、研究报告、与客户的讨论，也可能是销售或支持人员分享的。

一旦开始对想法进行积极的工作，它就会遵循以下四个阶段：

深思：讨论想法可以解决的问题或带来的机遇，它们会对谁产生影响，以及它们的重要性。
探索：构思潜在的解决方案，直到找到一个通过客户反馈验证的解决方案。
创造：构建解决方案，并不断改进，直到满足足够多客户的需求。
影响：推出解决方案，衡量结果，并不断改进，直到达到您想要的结果。

Sirius 团队在 Jira Product Discovery 中的想法阶段。

Jira Product Discovery 团队每个想法阶段的想法面板视图。

这不是瀑布模型—这些阶段不一定是线性的。例如，“探索”阶段的想法回到“深思”阶段是很常见的，因为测试解决方案会让我们对问题有更多的了解。如果尝试几次后仍找不到合适的解决方案，放弃某些想法也是意料之中的。

在下面的章节中，我们将通过展示我们的团队在构建 Jira Product Discovery 时是如何遵循各个阶段的，来说明每个阶段。

如果您对这一过程感到好奇，请观看本讲座了解更多详情：

深思

“深思”阶段是验证问题或机会。

在这一阶段，您通常需要与客户进行定性访谈。通过这项研究，您的团队将明确该想法旨在提供的利益和成果，并根据对客户和企业的价值来衡量。他们还将就如何衡量成功提出假设。

对于这一阶段的想法，您可以使用 Jira Product Discovery 的“问题定义”模板，也可以创建自己的模板。

Jira Product Discovery 中的“问题定义”模板。

在整个“深思”、“探索”、“创造”和“影响”阶段，将从研究和客户对话中获得的经验纳入想法的“洞察信息”部分：

Jira Product Discovery 中想法的“洞察信息”字段。

“深思”阶段在实际中的应用

以下是我们构建 Jira Product Discovery 时“深思”阶段的样子。该产品的最初想法来自：

对使用 Jira 进行软件交付的产品经理进行的采访

分析 Atlassian 自己的研究与洞察信息团队以及 Gartner 和 Forrester 等分析公司的研究结果

产品开发最佳实践示例，例如 Marty Cagan 的博客和 Teresa Torres 的著作。

通过收集这些洞察信息，我们确信：

从有效确定优先顺序到说服所有人相信他们的路线图，PM 正在努力处理各种事情
PM 希望通过 Jira 解决这些痛点，但由于 Jira 并非为此目的而设计，因此收效有限
PM 陷入了交付困境，专注于交付功能等产出，而他们本可以采取发现优先的心态并交付成果
产品管理正在成为一项关键职能，甚至超出了科技公司的范围。因此，我们相信这是一个巨大的机遇，对解决方案的需求也会非常强烈。

我们的 Jira Product Discovery 登陆页面。

我们尤其注重验证我们的需求假设，因为这是我们最冒险的假设。如果我们错了，我们创造的产品只有少数公司会购买。

因此，在编写一行代码之前，我们创建了一个宣传产品的网页。

结果证实了我们的假设：两星期内就有 3000 人加入了等待名单。

了解

在“探索”阶段，我们针对“深思”阶段发现的问题或机遇，构思、测试和验证解决方案。

我们知道，很多产品想法都会失败，这只是过程的一部分！为了尽早发现这些不那么有前途的想法，并为好的想法让路，Marty Cagan 建议产品经理解决以下四个关键风险。在评估您所发现的问题和机遇的可能解决方案时，请使用这四个关键风险。

解决方案对客户有价值吗？如果没有价值—比方说，他们已经有了更好的替代方案—那么就有可能出现人们不使用您所构建的解决方案的情况。
解决方案是否实用、直观？要让用户从解决方案中获得价值，解决方案必须容易获取且简单易用。如果获取价值的门槛很高，那么推出的功能就有可能使用率很低。
该解决方案在技术上是否可行？无论想法多么有前途，您的工程师都必须具备必要的技能和技术来实现它，否则就有可能不必要地耗费资源。
在企业的资源和限制条件下，该解决方案是否可行？要想获得正确的解决方案，很可能需要经过几次不同的迭代。您要确保企业做好投资准备，否则就有可能把时间花在一个被放弃的想法上。

您团队的目标是尽可能高效地降低风险，避免基于直觉或对解决方案的喜爱而过度投资。通常的做法是，先交付一项功能，然后进行迭代或研究其性能如何。而替代的做法是，在开始编写代码之前，应使用低级技术，如在 Figma 中创建原型并向客户展示，以获得早期反馈。

如果您决定交付一项功能，请尝试构建一个有很多限制的实时原型，在一小群早期采用者中进行测试，并快速迭代。这样，您就不必考虑所有可能出现的情况。如果这个想法对他们来说不可行，您会更快地了解原因，并继续迭代直到可行为止，如果这个想法没有落地，就放弃。

如果存在较大的不确定性，则应在“探索”阶段进行技术预研。这种类型的实施旨在帮助您了解团队自身的限制因素；哪些是技术上可行的，哪些是技术上复杂的领域。

对于这一阶段的想法，您可以使用 Jira Product Discovery 的“解决方案定义”模板，也可以创建自己的模板。

Jira Product Discovery 中的“解决方案定义”模板。

在您的产品待办事项中，链接与每个想法相关的所有文档、规范和设计，这样您就可以随时与团队和利益相关者讨论想法。我们建议在每个想法上创建“超链接”字段，以跟踪每个资产（单页、设计）。

以下是如何创建的演示：

“探索”阶段在实际中的应用

在创建 Jira Product Discovery 时，我们使用了以下技术来与客户验证我们的解决方案：

我们用来与客户验证 Jira Product Discovery 的幻灯片。

首先，我们向 PM 展示了包含不同可能解决方案的幻灯片，以了解哪种解决方案最能引起共鸣。通过这些对话，我们对客户的困难以及他们所看重的东西有了很多的了解。就这样，“优先级排序”成为了 Jira Product Discovery 的第一支柱。

💡 幻灯片非常适合这一验证阶段：它们易于创建、测试和更改。

早期“探索”阶段的 Figma 原型。

接下来，我们在 Figma 中创建原型，向用户展示，并询问解决方案将如何帮助他们。我们尝试的第一个原型是一个解决方案，旨在帮助 PM 利用利益相关者的反馈来确定优先级。

虽然用户肯定很感兴趣，但 PM 认为，他们需要花费大量精力进行设置，才能获得价值。因此，我们放弃了这个想法。

Jira Product Discovery 胜出的 Figma 原型。

在收集了多轮此类反馈后，我们探索出了解决方案，这就是今天的 Jira Product Discovery：一个用于讨论产品想法的协作空间。

在这一阶段，与用户的对话发生了巨大变化。许多人都在询问何时能获得访问权限，因为该工具对他们帮助很大。就在那时，我们知道我们的方向是正确的。

在收集了多轮此类反馈后，我们探索出了解决方案，这就是今天的 Jira Product Discovery：一个用于讨论产品想法的协作空间。

生产

在“创造”阶段，团队会构建并验证他们在“探索”阶段确定的解决方案。这是进行开发工作的主要阶段。

这一阶段的成果是可运行的软件，可以是新产品或新功能，也可以是对现有体验的改进，该软件已证明能够实现预期成果，已被足够多的客户采用以证明其价值，并已准备好供所有客户使用。

当开始交付时，无论是在这一阶段还是在“探索”阶段，您都要将想法与 Jira 中的请求单（我们推荐长篇故事级或以上）连接起来。在 Jira Product Discovery 中跟踪交付进度，并获得所有产品计划和团队进展情况的概览。

在 Jira 中，想法与交付工作之间的关系。

如果多个团队都参与了某个想法的交付，而且他们在不同的 Jira 项目中工作，您可以将他们的所有交付请求单都链接到产品待办事项中的“想法”。

由三个不同的 Jira 小组交付的想法。

然后，您就可以在 JPD 中跟踪交付进度，并获得所有产品计划和团队进展情况的概览。

进行中的产品工作仪表板。

如需了解更多信息，请参阅资源部分中关于“如何在 Jira 中连接发现和交付”的在线研讨会。

请记住，解决方案不太可能立即实现预期成果。相反，应尽早并经常向客户交付，并不断迭代，直到足够好为止。根据了解到的内容，不断将客户对话中的洞察信息添加到想法中。衡量成功与否的方法会根据想法的类型而有所不同：新功能、增长计划等。确保每个人都知道这一点，并确保您的计划允许迭代。

“创造”阶段在实际中的应用

在创建 Jira Product Discovery 时，以及在为产品添加重要的新功能时，我们会逐步扩大客户群，对其进行测试和验证。在某些情况下，这个过程需要几周时间，而在其他情况下则需要几个月。

0 → 10 个客户证明价值	在“探索”阶段，我们与少数预选客户进行了迭代。我们与这些客户密切合作，共同制定解决方案。我们不断迭代，直到他们确认解决方案解决了他们所面临的问题。在这一阶段，解决方案已经证明了它的价值。但它还远远不够完善，也没有考虑到各种可能出现的情况。
10 → 100 个客户使其功能完善	然后，我们逐步接触更多的客户。这帮助我们确定了最初可能没有考虑到的不同方案。我们不断进行迭代，直到有 100 个活跃客户使用该解决方案。在这一阶段，解决方案通常功能完备。但它可能无法被发现，也不是自助服务。例如，用户可能需要视频教程才能了解如何使用。
100 → 1000 个客户实现自助服务	然后，我们向更多客户提供了访问权限，直到达到 1000 个。接下来，我们从产品分析、支持请求单和入站反馈中查看使用率数字。根据调查结果，我们改进了用户体验或修复了缺陷。如果使用率数字太低，无法发挥作用，我们就会研究该功能的可发现性。在这一阶段，功能应该是自助式的：它可以被发现，用户体验足够好，文档准备就绪，等等。
正式发布做好运营准备	最后，我们准备好了支持赋能、销售赋能、操作仪表板、性能和可扩展性改进。在这一阶段，解决方案应该可以进入黄金时段了。

当我们开发这样的解决方案时，我们通常会在一个单独的 Confluence 页面中塑造它们，我们称该页面为“实时功能文档”。这是一个非常轻量级的页面，我们每次召开团队会议时都会打开它，讨论当前迭代的范围。我们会经常更新这个文档，因为我们会了解到更多关于哪些容易或难以交付的信息。它侧重的不是各项任务，而是产品体验，这也是我们希望从产品到设计再到工程团队的每个人都要统一的地方。