确定想法的优先级，实现有效的产品开发
知道如何有效地确定优先级是产品经理最重要的技能之一。有效的优先级排序是成功产品团队的超级能力，使他们能够快速行动，专注于影响最大的活动。
但是，优先级的确定很少是显而易见或简单明了的；产品经理需要有意识地做出谨慎的判断。他们需要平衡相互冲突的优先事项和考虑因素，如当前的业务需求、长期战略、客户请求、竞争和不断变化的市场条件。
另一方面，如果优先级的确定不以洞察信息为基础，不与成果挂钩，就会成为一场噩梦。讨论会演变成冲突，没有达成共识的明确方法，只能根据直觉或最响亮的意见做出选择。
确定优先级既是艺术也是科学
为了取得最佳结果，优先级的确定应将结构化方法与定性考虑相结合，并为直观决策留有余地。
RICE 或“影响与工作量矩阵”等框架可以帮助安排对话。但您还应利用团队和利益相关者对业务目标和客户需求的了解，例如基于研究、用户访谈和内部反馈。确定优先级有科学的因素，但始终需要一点艺术。
不同的组织以不同的方式确定优先级。正确的方法取决于公司文化、团队规模、产品成熟度以及谁在推动决策（如在销售主导型公司与产品主导型公司中）等因素。
就像产品开发中的许多其他工作一样，必须不断完善优先级排序—您优先考虑什么，以及如何确定它的优先级。
如果您从事的是早期阶段产品的相关工作，那么您很可能只关注客户的当前需求。
一旦找到产品的市场契合点，您就会开始考虑激活、用户参与和保留、解决技术债务问题，并为系统的扩展做好准备。
对于成熟产品，您可能会优先考虑分销，以及探索新的收入来源，如高级功能、合作伙伴关系和新产品发布。
随着团队和公司的发展壮大，您可能需要让更多的人参与到优先级排序过程中，如销售、支持和客户成功团队。
您永远找不到永远有效的完美方法。基于上述所有这些原因，我们将 Jira Product Discovery 设计得像一张灵活的画布，以支持正确的对话，了解在您的成长阶段，什么对您的公司和产品最重要。没有两个 Jira Product Discovery 项目是相同的。
成功确定优先级的要素
虽然每个团队都会以独特的方式确定优先级，但要有效地确定优先级，仍有几个关键要素。不幸的是，许多团队都会陷入无效的优先级确定中，从而阻碍他们实现目标。以下是在确定优先级的过程中应努力采取和避免的做法。
努力采取 | 避免 |
|---|---|
通过确定优先级来平衡随时间推移不同类型的投资，例如用户请求、销售机会、策略投注和指标变化因素 | 优先级的确定过度注重产出（如交付新功能），而不是成果 |
协同确定优先级，包括整个产品团队以及所有了解业务和客户需求的利益相关者 | 由领导层决定优先级，或由产品经理单独处理 |
根据经验持续确定优先级 | 在“大爆炸”式的路线图工作中每年确定优先级一次 |
利用数据和洞察信息，根据从持续产品发现实践获得的定性和定量数据确定优先级 | 根据直觉或客户和利益相关者的意见确定优先级 |
优先考虑均衡的产品投资组合
在许多产品团队中，我们发现一种倾向，认为确定优先级就是“我们下一步应该交付哪些功能？”
这种想法会带来麻烦。即使抛开外部力量和市场压力（如竞争对手的干扰），这样确定优先级也不会带来您想要的产品成果。
一开始，您可以通过添加新功能来快速推进。但这只是产品管理的简单部分。难的是，在未来的许多年里，创造出让用户满意的产品。
仅仅满足客户的所有要求还不足以让产品取得成功。例如：
如果您只关注活跃用户的反馈，评估者可能无法理解应用的价值，因为您没有在入职培训方面进行投资
功能臃肿可能会使产品难以使用，因此早期采用者无法说服其他人使用它
缺陷和可靠性问题可能会妨碍用户执行关键任务，因为您只关注新功能的交付而忽略了对现有功能的维护
防止出现这种问题的方法之一是将产品路线图划分为不同的桶，分别用于产品成功的不同方面。您可以为新功能、改进现有功能、可靠性投资和专注于分销等方面划分桶。
积极地在每个桶上进行投入，而不是为了应对因忽视这些桶而不可避免地出现的危机，并提前为每个桶分配预算。
RUF：可靠性、可用性、新功能
我们建议在新产品功能、改善现有体验和加强产品可靠性工程基础之间平衡投资。
Atlassian 众多团队用于平衡资源投入的框架名为 RUF：
RUF = 可靠性 + 易用性优化 + 新功能
可将 RUF 框架想象成一个金字塔：
可靠性 | 用户对应用的第一期望是，无论何时打开它，它都能正常运行。 当他们尝试执行关键操作时，没有任何缺陷阻碍他们完成工作。应用不会丢失他们的数据，也不会因为用户体验不佳而让人觉得丢失了数据。用户相信他们的数据是安全可靠的。 可靠性就是建立信任。信任的建立需要很长的时间，但也可能很快被摧毁—一次数据丢失或安全漏洞事件就可能造成严重的用户流失，更不用说重复事件了。 可靠性是金字塔的基础。这里的任何问题都应优先解决—您必须全力以赴，集中精力解决这些问题。投资于能让这些紧急中断发生的基础架构：事件管理流程、系统冗余、减少技术债务等。 |
可用性改进 | 您开发产品的时间越长，产品的功能就可能越多。功能膨胀是许多应用的无声杀手。 通常，20% 的功能占使用量的 80%。客户通常看重的是只做一件事但做得很好的应用，而不是试图面面俱到的“瑞士军刀”。 一项功能很少会永远“完成”—它是一个系统的一部分，而这个系统需要不断调整。在路线图中，务必分配预算与各类资源，以在当前功能集上持续投入： - 优化常用功能的用户体验 - 提升低频使用功能的可查找性 - 移除没有吸引力的功能 - 优化引导流程以提升使用率和转化率 |
新功能 + 想法 | 有了坚实的基础，您就可以添加新功能了。每个人都知道我们在说什么 😉 |
确定新想法优先级的 3 桶规划指南
即使是新产品想法，也要采取平衡的方法，为产品的成功做好准备。
🛑 不能客户要求什么功能，您就开发什么功能，因为这样做有可能只会帮到现有的用户群。
🛑 您不能只关注改善关键业务指标，如收入增长，因为您可能会忽略重要的客户需求。
🛑 您也不能只交付变革性的新想法，否则就会把可靠性和可用性置于危险之中
Dropbox 前产品与增长副总裁 Adam Nash 建议从 3 个桶入手（资料来源：“3 桶规划指南”）：
指标动因桶是指通过改善关键指标（注册人数、转化率、留存率、活跃用户数、推荐数、收入等）直接促进业务目标实现的产品计划。增长计划通常属于这一类。
客户请求桶是指客户提出的要求，包括新功能和对现有体验的改进。解决这些问题有助于让客户满意，减少支持负担，并确保您的产品完成其关键任务。
愉悦客户桶是产品的创新点。这些功能是客户不知道他们需要的，但却能通过改变他们的工作方式来改善他们的生活。愉悦客户桶可使您在竞争中脱颖而出，并为您的产品筑起一道护城河。
在投资之间分配预算
重要的是，要有意识地投资于每一个桶。否则，您的速度可能会因为您的团队将 80% 的时间用于修复缺陷而下降，或者因为您没有进行战略性思考而导致产品增长放缓。尽可能多地交付新功能不太可能解决这个问题。
每个桶的正确预算分配取决于很多因素，尤其是产品所处的阶段：PMF（产品市场契合度）前、PMF 后或成熟产品。
在实践中，预算分配可以是这样的：
PMF 前 | PMF 后 | 成熟 | |
|---|---|---|---|
可靠性 | 10% | 30% | 50% |
可用性改进 | 20% | 20% | 20% |
客户请求桶和愉悦客户桶 | 70% | 30% | 10% |
增长计划 | 20% | 20% |
请记住，这绝不是一成不变的。例如，您可能会决定在几个月内加大对新功能的投资，然后回过头来专注于用户体验改进或解决技术债务问题。
但在进行分配和重新分配时，重要的是要牢记使产品成功所需的不同方面，并随着时间的推移平衡投资。
管理这些投资有不同的方法：您可以让团队专门负责一个或另一个桶，您可以确保每个团队每次从每个桶中选择一个计划，或者您可以让每个团队以循环的方式从每个桶中挑选工作。每种方法都各有利弊，但这与交付规划有很大关系，所以我们在此就不一一介绍了。
在 Jira Product Discovery 中平衡投资
以下是我们在六个月内对 Jira Product Discovery 团队投资分配的配置。
所有小队的投资
我们有四大主题：定价和包装、增长、待完成的工作以及工程计划。在每个主题中，我们都有一些赌注。
这些赌注分配给 JPD 团队：5 个产品小队和 1 个工程小队（Sirius、Horizon、Aurora、Juno、Pulsar、X-flow）。
产品小队
每个产品小队需要按以下比例分配时间：
60% 用于产品计划。为此，他们创建了一个路线图，其中包括两个部分：一部分用于新功能，另一部分用于改进当前的产品体验。
20% 用于 RtB—业务运营：待命、缺陷等。
20% 用于解决技术债务
虽然我们没有严格执行这一分配，但每个团队都会在冲刺规划和月度审查中讨论如何保持这一平衡。通常情况下，随着时间的推移，这一比例也会保持不变。
对于产品计划，我们会密切关注从用户那里收到的反馈，并每周与所有产品经理进行讨论。我们将反馈分为“巨石”（特大型投资）和“岩石”（大型投资）。
我们还有一份单独的“卵石”列表，是指用于修复用户体验中的“小缺陷”的小改进。由于无法将其影响与 L 级和 XL 级投资进行比较，因此很难对其进行优先排序。但是，随着时间的推移，它们的影响会逐渐增大。我们的期望是，每个小队在任何时间点都有一个“卵石”修复在进行中。
工程小队
每个工程小队都有类似的划分。但他们专注于纯工程项目，以提高系统的弹性和规模，而不是产品计划。
为富有成效的优先级讨论奠定基础
公司中有许多人对您的产品应帮助满足的业务和客户需求有着自己的洞察信息。
如果您能利用这些集体知识，就能为您的产品决策建立更多信心，并降低下错赌注的风险。
但这说起来容易做起来难。我们听说过产品团队被领导层和销售团队的要求淹没，然后不断被更新请求打断：“我的请求什么时候交付？
如果方法得当，将优先级排序变成一项团队运动，就会产生巨大的价值。协作确定优先级的流程可以明确使命、愿景和目的，让整个企业的团队都朝着共同的目标努力。
以下是高效协作确定优先级所应遵循的几项原则。
设定明确的期望
设定期望是每个人有效协作的关键。每个人都必须了解确定优先级的实际意义，以及他们应如何做出贡献。
以下是几个关键要素：
每个人在对话中的角色和职责
共同的目标和衡量成功的方法
用于确定优先级的指定词汇和框架
建立的沟通渠道和反馈回路
分配角色和职责
要想使确定优先级成为每个人的积极体验，就必须明确他们应如何做出贡献。
为此，我们围绕 3 种角色设计了 Jira Product Discovery：创作者、贡献者和利益相关者。
角色 | 他们是谁 | 职责 |
|---|---|---|
创建者 | 产品、工程、设计和研究领域的核心产品团队。 | 自始至终推动产品、优先级确定流程和想法。 |
贡献者 | 销售、支持、客户成功、营销和其他领域团队的联系人。 | 参与优先级确定流程并提供关键洞察信息：客户请求、支持问题等。 |
利益相关者 | 公司其他人员，通常分为 2 种角色：领导层和其他人员。 | 需要了解优先事项、进度和决策，以及提供反馈的方式。 |
持续审查优先事项，以逐步改进
确定优先级的一种无效但常见的节奏是每年一次或两次—“大爆炸”式方法。
这种方法行不通，因为它无法让团队适应不断变化的因素。您的产品必须对市场条件、新客户对话、比预期更复杂的实施等做出响应。
“大爆炸”式的优先级排序也会导致大对话，每个决策都会产生非常大的影响。这会带来压力和期望，从而在优先级讨论中造成紧张关系。人们担心陷入把资源用在错误事情上的境地，因为他们不想在几个月内都被这个决策的结果所困扰。
而我们建议您经常与团队和利益相关者进行优先级方面的讨论，至少每两周或每月一次，最好每周都讨论一点：您学到了什么？它是否根据您当前的工作重点改变了任何事情？
配置产品待办事项以主持这些讨论
为了让每个人都明确自己的角色，并帮助决策按计划进行，我们建议通过以下方式来配置产品待办事项：
创作者在 Jira Product Discovery 项目中。他们设置其配置（字段、视图等），并创建和管理想法、观点和洞察信息。
贡献者被添加到项目中，但只有一套有限的基本协作功能。他们可以添加投票、洞察信息、评论和反应。
利益相关者不会被添加到项目中。创建者会发布与利益相关者共享的只读视图。
我们建议为每个受众创建单独的视图：
这些针对特定角色的视图可确保每个群组都能以与他们相关的方式获得所需的信息。产品团队如何确定优先级、正在讨论哪些想法以及如何做出贡献，都将一目了然。如果他们有不同意见，也有渠道以富有成效的方式表达出来。
这种方法可以帮助每个受众有效参与，改善各个层面的协作和协调。
在 Jira Product Discovery 中协作确定优先级的技巧
一旦每个人都明确了条件，确定优先级就会成为一个共享的、透明的过程。然后，您就可以开始参与实际讨论了。
在 Jira Product Discovery 中，您的产品待办事项是将确定优先级转化为协作练习的完美空间。在本节中，我们将分享配置产品待办事项以支持这些对话的不同方法。
很多方法都使用数字，如 1-5 评级。这些数字本身是主观的，重要的是数字背后的“原因”。重要的是每个人都能以同样的方式理解它们，这样就能更容易地讨论每个想法的相对优先级。例如，让大家对什么被视为“高工作量”或“低影响”达成共识。
开展“10 美元游戏”，鼓励在限制条件下思考问题
“10 美元游戏”是一种有吸引力的方式，可以让人们在考虑各种限制条件的同时，对某个想法的重要性进行评级。
如果有无限的时间和资源，产品团队可以做任何事情。但实际上，两者都是有限的。这就是“10 美元游戏”的用武之地。它是一个像产品经理一样思考的练习，可以帮助玩家体会到这份工作的艰辛！
Jira Product Discovery 中的“10 美元游戏”。
方法很简单：给每位参与者 10 美元的预算，让他们“花”在自己认为最重要的想法上。他们可以在一个想法上任意下注，比如在 2 个想法上下注 5 美元，在 3 个想法上下注 3 美元。当然，您也可以使用 10 美元以外的预算。
然后，参与者解释他们下注的理由。为什么他们认为某些想法很重要或很有前景？这种方法鼓励积极参与和讨论，确保每个人的意见都得到考虑。
尝试在确定优先级周期的开始阶段使用“10 美元游戏”，以了解每个人的想法。或者在结束阶段玩该游戏，看看大家的意见是否一致。
在产品和工程团队的对话中使用影响与工作量矩阵
影响与工作量矩阵根据潜在的业务影响和实现这些想法所需的工作量来确定想法的优先级。
该矩阵是构建产品经理和工程师之间对话的一种简单而强大的方法。
工程师可受邀分享他们对交付复杂性的看法。这有助于经理们识别可能的速赢或大赌注，并确定为什么特定的想法应优先于其他想法。
使用 RICE（影响范围、影响力、信心水平、工作量）将信心水平考虑在内
RICE 框架使用四个考虑因素来帮助确定一个想法的优先级：影响范围、影响力、信心水平和工作量。这是一种广受欢迎的产品管理工具，因为它以一种大多数利益相关者都能理解的方式来阐述这些重要因素。
大多数贡献者都习惯于评估一个想法的影响力、影响范围以及实现该想法所需的工作量。但 RICE 框架的优势在于，它还将信心水平引入对话中。
产品团队是否有信心认为这个想法是一项很好的投资？还是需要进一步的研究和产品或技术验证才能确定？
这有助于团队分享为什么一个想法已成定局，或者为什么它可能需要更多的调查。
要求面向客户的团队在符合客户需求的想法上标记客户
许多使用 Jira Product Discovery 的团队都选择了这种方法：他们配置一个视图，其中包含一个想法列表，以便与面向客户的团队共享。
当客户分享的需求与其中一个想法相关时，销售/支持人员就会在想法上标记他们。然后，可以根据被标记客户的数量对每个想法进行评分。
如果客户属于不同重要性的细分市场，产品和客户团队可能希望为不同的客户分配不同的权重—在下面的例子中，客户被分为企业、中小企业和初创企业。
这是一种简单但非常有效的方法，可以促进产品团队和面向客户的团队之间进行富有成效的对话。
您可以把它做得更漂亮（但您可能不应该这样做）
团队还可以使用更多方法来讨论优先级。
至于哪种方法适合您的需求，这实际上取决于您—但一般来说，我们发现方法越简单，对话效果越好。
有些团队执着于寻找“正确”的优先级排序模型。但框架只是达到目的的一种手段。它的目的是帮助您实现目标，而不是占用您的时间和注意力。记住—您要管理的是您的产品，而不是您的优先级排序框架！
使用适合您的方法
说到底，这些都只是建议。没有两个 Jira Product Discovery 项目是相同的，因为没有两个公司或团队是相同的。在不同的渠道，所有这些方法都是为了建立以下内容的平衡视图：
企业的目标
潜在客户的需求
客户和用户的需求
如何减轻支持团队的负担
如何实现销售对话
还有更多，取决于您的业务和产品
根据团队的独特需求和产品，我们建议您创建自己的视图组合，以帮助您按照自己所需的方式来确定优先级。在此基础上，只有您自己才能决定您的优先事项：您要对哪些说“是”，对哪些说“不”。
在这些讨论的基础上，您就可以制定出自己的路线图。
后续事项
确定优先级是将决策与预期产品成果联系起来的唯一途径。有效的优先级排序意味着强有力的路线图，它能以负责任的方式分配资源，使产品团队能够按计划实现业务目标和满足客户需求。
现在，我们准备进入本手册的最后一部分。我们将把迄今为止所学到的所有知识汇总起来，以便：
创建将团队和利益相关者团结起来的路线图
我们将举例说明我们如何在 Jira Product Discovery 团队中使用 Jira Product Discovery 和其他产品来做到这一点。