确定想法的优先级，实现有效的产品开发
知道如何有效地确定优先级是产品经理最重要的技能之一。有效的优先级排序是成功产品团队的超级能力，使他们能够快速行动，专注于影响最大的活动。
但是，优先级的确定很少是显而易见或简单明了的；产品经理需要有意识地做出谨慎的判断。他们需要平衡相互冲突的优先事项和考虑因素，如当前的业务需求、长期战略、客户请求、竞争和不断变化的市场条件。
另一方面，如果优先级的确定不以洞察信息为基础，不与成果挂钩，就会成为一场噩梦。讨论会演变成冲突，没有达成共识的明确方法，只能根据直觉或最响亮的意见做出选择。
RUF：可靠性、可用性、新功能
我们建议在新产品功能、改善现有体验和加强产品可靠性工程基础之间平衡投资。
Atlassian 的许多团队都使用一个框架来平衡投资，这个框架称为 RUF：
RUF = 可靠性 + 可用性改进 + 新功能
将 RUF 框架视为一个金字塔：
| 可靠性 | The first thing users expect from your app is that whenever they open it, and it just works. |
| Usability improvements | The longer you’ve worked on a product, the more features it likely has. Feature bloat is the silent killer of many apps. |
| New Features + Ideas | With a strong foundation in place, you can add new features. Everyone knows what we’re talking about here 😉 |
The 3 Bucket Planning Guide for prioritizing new ideas
Even when it comes to new product ideas, take a balanced approach to set your product up for success.
🛑 You can’t just build whatever features customers ask for, as you risk only helping your current user base.
🛑 You can’t only focus on improving key business metrics like revenue growth, as you might ignore important customer needs.
🛑 You can’t only ship new revolutionary ideas either, or you put reliability and usability at risk
Adam Nash, former VP product and growth at Dropbox, suggested looking at 3 buckets (source: “the 3 bucket planning guide”):
A view of 3 bucket feature planning in Jira Product Discovery
- Metrics Movers are product initiatives that directly contribute to business goals by improving key metrics: sign-ups, conversion, retention, active users, referrals, revenue, etc. Growth initiatives typically fall in this category.
- Customer Requests are what customers ask for, both net-new features and improvements to current experiences. Addressing these helps keep customers happy, reduce support load, and ensure that your product nails its key jobs.
- Delighters are where your product innovates. These are the features your customers didn’t know they wanted, but can improve their lives by changing how they work. Delighters differentiate you from competition and build a moat around your product.
Allocating budget across investments
It’s important to be intentional in how you invest in each of these buckets. Otherwise, your velocity might drop because your team spends 80% of their time fixing bugs, or the growth of your product slows down, because you’re not thinking strategically. Shipping as many new features as possible is unlikely to fix that.
The right budget allocation for each bucket depends on many things, but in particular the stage of your product: pre-PMF (Product Market Fit), post-PMF, or mature product.
In practice, budget allocation could look like this:
| | Pre-PMF | Post-PMF | Mature |
|---|---|---|---|
| 可靠性 | Pre-PMF 10% | Post-PMF 30% | Mature 50% |
| Usability improvements | Pre-PMF 20% | Post-PMF 20% | Mature 20% |
| Customer requests and delighters | Pre-PMF 70% | Post-PMF 30% | Mature 10% |
| Growth initiatives | Pre-PMF
| Post-PMF 20% | Mature 20% |
Remember, this should never be set in stone. For example, you might decide to invest more in new features for a few months, then go back and focus on UX improvements or addressing technical debt.
But as you allocate and re-allocate, it’s important to keep in mind the different aspects that are required to make your product successful, and to balance your investments over time.
There are different ways to manage these investments: you can have teams dedicated to one or the other bucket, you can make sure that each team has one initiative from each bucket at each time, or you can have each team pick work from each of the buckets in a round-robin fashion. There are pros and cons to each approach but it’s a lot more about delivery planning so we won’t cover them here.
Balancing investments at Jira Product Discovery
Here’s how we configured our investment allocation on the Jira Product Discovery team over a six-month period.
Investments across all squads
We have 4 main themes: pricing and packaging, growth, jobs-to-be-done and engineering initiatives. In each of these themes, we have a number of bets.
These bets are distributed amongst the JPD teams: 5 product squads and 1 engineering squad (Sirius, Horizon, Aurora, Juno, Pulsar, X-flow).
Product squads
Each product squad is required to allocate their time with the following split:
- 60% on product initiatives. For this they create a roadmap with two sections: one for new features, and one for improvements to the current product experience.
- 20% on RtB - Run the Business: on-call, bugs, etc.
- 20% on fixing tech debt
While we don’t strictly enforce this allocation, each team discusses keeping this balance during their sprint planning and monthly reviews. Typically, it does hold true over time.
For product initiatives, we keep a watch on feedback we receive from users and discuss every week with all product managers. We separate the feedback into “Boulders,” XL investments, and “Rocks,” large investments.
We have a separate list for “Pebbles,” small improvements fixing “paper cuts” in the UX. These are difficult to prioritize since you can’t compare their impact to L and XL investments. But, their impact compounds over time. The expectation is that each squad has one Pebble fix in progress at any point in time.
Engineering squads
Each engineering squad has a similar split. But instead of product initiatives they focus on pure engineering projects to improve system resilience and scale.
Setting the stage for productive prioritization discussions
There are many people at your company who have insights into business and customer needs your product should help with.
If you can harness this collective knowledge, you can build more confidence in your product decisions and mitigate the risk of making the wrong bets.
But this is easier said than done. We’ve heard of product teams being swamped with asks from leadership and sales teams, then constantly interrupted with requests for updates: “when is my request going to ship?”
Done right, you can get a lot of value from turning prioritization into a team sport. A collaborative prioritization process creates clarity of mission, vision and purpose, getting teams across the business working towards shared goals.
Here are a few principles to follow for productive, collaborative prioritization.
设定明确的期望
Setting expectations is crucial for everyone to collaborate effectively. People must understand what prioritization actually entails, and how they should contribute.
Here are a few key ingredients:
- Everyone’s roles and responsibilities in the conversation
- Shared goals and ways to measure success
- Designated vocabulary and framework for prioritizing
- Established communication channels and feedback loops
分配角色和职责
For prioritization to be a positive experience for everyone, you want to make it clear how they should contribute.
To help with this, we designed Jira Product Discovery around 3 roles: creators, contributors and stakeholders.
Where creators, contributors, and stakeholders fit into the prioritization process.
角色 | Who they are | 职责 |
|---|---|---|
| 创建者 | Who they are The core product team across product, engineering, design, research. | 职责 Drive the product, the prioritization process, and the ideas from beginning to end. |
| 贡献者 | Who they are Points of contact within the sales, support, customer success, marketing and other field teams. | 职责 Participate in the prioritization process and provide key insights: customer requests, support problems, etc. |
| 利益相关者 | Who they are The rest of the company, typically separated in 2 roles: leadership, and everyone else. | 职责 Need visibility on priorities, progress and decisions and ways to provide feedback. |
Review priorities continuously for incremental improvement
确定优先级的一种无效但常见的节奏是每年一次或两次—“大爆炸”式方法。
这种方法行不通，因为它无法让团队适应不断变化的因素。您的产品必须对市场条件、新客户对话、比预期更复杂的实施等做出响应。
“大爆炸”式的优先级排序也会导致大对话，每个决策都会产生非常大的影响。这会带来压力和期望，从而在优先级讨论中造成紧张关系。人们担心陷入把资源用在错误事情上的境地，因为他们不想在几个月内都被这个决策的结果所困扰。
而我们建议您经常与团队和利益相关者进行优先级方面的讨论，至少每两周或每月一次，最好每周都讨论一点：您学到了什么？它是否根据您当前的工作重点改变了任何事情？
配置产品待办事项以主持这些讨论
为了让每个人都明确自己的角色，并帮助决策按计划进行，我们建议通过以下方式来配置产品待办事项：
- 创作者在 Jira Product Discovery 项目中。他们设置其配置（字段、视图等），并创建和管理想法、观点和洞察信息。
- 贡献者被添加到项目中，但只有一套有限的基本协作功能。他们可以添加投票、洞察信息、评论和反应。
- 利益相关者不会被添加到项目中。创建者会发布与利益相关者共享的只读视图。
我们建议为每个受众创建单独的视图：
有三种视图可用于 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 美元游戏”，以了解每个人的想法。或者在结束阶段玩该游戏，看看大家的意见是否一致。
在产品和工程团队的对话中使用影响与工作量矩阵
影响与工作量矩阵根据潜在的业务影响和实现这些想法所需的工作量来确定想法的优先级。
该矩阵是构建产品经理和工程师之间对话的一种简单而强大的方法。
工程师可受邀分享他们对交付复杂性的看法。这有助于经理们识别可能的速赢或大赌注，并确定为什么特定的想法应优先于其他想法。
Jira Product Discovery 中的影响与工作量矩阵。
使用 RICE（影响范围、影响力、信心水平、工作量）将信心水平考虑在内
RICE 框架使用四个考虑因素来帮助确定一个想法的优先级：影响范围、影响力、信心水平和工作量。这是一种广受欢迎的产品管理工具，因为它以一种大多数利益相关者都能理解的方式来阐述这些重要因素。
大多数贡献者都习惯于评估一个想法的影响力、影响范围以及实现该想法所需的工作量。但 RICE 框架的优势在于，它还将信心水平引入对话中。
产品团队是否有信心认为这个想法是一项很好的投资？还是需要进一步的研究和产品或技术验证才能确定？
这有助于团队分享为什么一个想法已成定局，或者为什么它可能需要更多的调查。
要求面向客户的团队在符合客户需求的想法上标记客户
许多使用 Jira Product Discovery 的团队都选择了这种方法：他们配置一个视图，其中包含一个想法列表，以便与面向客户的团队共享。
当客户分享的需求与其中一个想法相关时，销售/支持人员就会在想法上标记他们。然后，可以根据被标记客户的数量对每个想法进行评分。
如果客户属于不同重要性的细分市场，产品和客户团队可能希望为不同的客户分配不同的权重—在下面的例子中，客户被分为企业、中小企业和初创企业。
这是一种简单但非常有效的方法，可以促进产品团队和面向客户的团队之间进行富有成效的对话。
根据公司目标对客户群使用权重。
为关键客户分配权重以确定优先级。
您可以把它做得更漂亮（但您可能不应该这样做）
团队还可以使用更多方法来讨论优先级。
至于哪种方法适合您的需求，这实际上取决于您—但一般来说，我们发现方法越简单，对话效果越好。
可能矫枉过正了：加权最短工作优先 (WSJF)。
有些团队执着于寻找“正确”的优先级排序模型。但框架只是达到目的的一种手段。它的目的是帮助您实现目标，而不是占用您的时间和注意力。记住—您要管理的是您的产品，而不是您的优先级排序框架！
使用适合您的方法
说到底，这些都只是建议。没有两个 Jira Product Discovery 项目是相同的，因为没有两个公司或团队是相同的。在不同的渠道，所有这些方法都是为了建立以下内容的平衡视图：
- 企业的目标
- 潜在客户的需求
- 客户和用户的需求
- 如何减轻支持团队的负担
- 如何实现销售对话
- 还有更多，取决于您的业务和产品
根据团队的独特需求和产品，我们建议您创建自己的视图组合，以帮助您按照自己所需的方式来确定优先级。在此基础上，只有您自己才能决定您的优先事项：您要对哪些说“是”，对哪些说“不”。
在这些讨论的基础上，您就可以制定出自己的路线图。
后续事项
确定优先级是将决策与预期产品成果联系起来的唯一途径。有效的优先级排序意味着强有力的路线图，它能以负责任的方式分配资源，使产品团队能够按计划实现业务目标和满足客户需求。
现在，我们准备进入本手册的最后一部分。我们将把迄今为止所学到的所有知识汇总起来，以便：
创建将团队和利益相关者团结起来的路线图
我们将举例说明我们如何在 Jira Product Discovery 团队中使用 Jira Product Discovery 和其他产品来做到这一点。
反馈和洞察信息
了解如何将洞察信息整合到产品开发流程中，从而加强决策、满足客户需求并取得成功。
制定路线图
探索如何制定有影响力的产品路线图，以调整优先级、加强沟通并支持各团队的战略目标。
