产品待办事项简介

一旦您明确了自己的成果,团队便可以聚集起来,就有助于实现这些成果的产品想法展开战术讨论。为此,您可以采取的第一个务实步骤就是采用产品待办事项。

在工作中,我们遇到过许多产品团队使用一个 Jira 待办事项列表来记录一切:功能请求、大小机会、任务和子任务、缺陷和紧急事务,以及关于产品下一步发展的想法。

他们总是向我们讲述同样的故事。待办事项列表逐渐失控,请求单列表不断变长,成为焦虑的根源。从战术变更到大型新投资,这些杂乱无章、不堪重负的待办事项列表不支持任何级别的优先级排序。

团队最后只能在电子表格中进行这些讨论,但每个季度都是土拨鼠日。洞察信息被遗失,决策没有记录,在时间压力下根据直觉或强烈的意见分配资源。

有一种更好的方法:围绕成果建立一个指定的产品待办事项,有别于日常工作的交付待办事项。

什么是产品待办事项?

产品待办事项是创建想法、确定想法的优先级并将其分享到路线图的地方,与成果和目标相关联。它包含所有产品想法、洞察信息、机会和解决方案,由产品团队所有。它不是规划要执行的具体任务,而是讨论“我们应该投资什么以及为什么投资”的地方。整个公司的利益相关者都可以被邀请到这个待办事项列表中,就优先事项和路线图进行协作,并讨论正在实施的产品计划的高层次进展情况。

可以把产品待办事项看作是产品团队的家,要与整个公司的协作者共享。这是一个指定的空间,可以存放他们想要跟踪的所有内容(从模糊的想法到完全成型的机会),并随着时间的推移,根据经验、客户反馈和不断变化的全局目标对其进行完善。

产品待办事项与交付待办事项

产品待办事项与交付待办事项是分开的,各有其特定的目的。

交付待办事项用于管理交付工作、制定交付计划和跟踪进度。它包含如何交付承诺的工作细分(长篇故事、故事、任务和子任务),由工程团队所有。这是整个团队开会协作、讨论交付问题的地方:排序、依赖关系、产能、技术里程碑。

很明显,产品待办事项和交付待办事项是紧密相连的。交付待办事项中的工作层层递进为产品待办事项中的想法,而产品待办事项中的想法本身又与预期成果相关联。这样,领导者、管理者和开发人员就能概览团队在发现和交付的循环迭代中如何致力于实现成果。

与产品待办事项不同的是,交付待办事项中的所有项目都是作为最终要完成的具体计划。相比之下,产品待办事项是用于构思和头脑风暴以及规划的。有些产品想法永远不会被优先考虑,也不会被列入路线图,这没有关系。

通过将从全局考虑的产品问题与交付规划和跟踪分开,团队可以更有效地确定优先级,将工作与成果联系起来,避免待办事项列表失控,试图面面俱到。

产品待办事项与交付待办事项
产品待办事项和交付待办事项如何相互联系,以及如何与公司的不同团队联系。

产品待办事项

交付待办事项

它有什么用?

我们应该投资什么?为什么?

如何实现它?

里面有什么?

产品想法、用户问题、机会、解决方案、假设

工作细分:长篇故事、故事、任务、子任务和缺陷

谁拥有它?

产品经理

产品负责人、工程团队负责人、项目/计划经理

谁参加

核心产品团队:产品经理、工程师、设计师、公司内的其他产品团队

面向客户的团队(销售、支持、客户成功、解决方案工程、现场团队)

管理层

业务利益相关者

核心产品团队:

产品经理、工程师、设计师

工程部门领导者

确定优先级的依据

目标、业务价值

客户反馈与洞察信息

产品分析与数据

技术可行性

依赖关系

Team Capacity

运营紧迫性(例如缺陷和可靠性问题)

产品待办事项的优势

为产品和交付使用不同的待办事项列表有很多好处:

  • 它为产品团队提供了一个安全的空间,让他们可以根据现有数据讨论潜在的想法,而不必担心这些想法的可行性或明确性。

  • 它将产品讨论整合到一个地方,因此团队可以随着时间的推移积累知识,而不必在数十个电子表格中进行搜索。

  • 它创建了产品优先事项的共享事实来源,并形成对它们的共同理解。这就解决了产品团队面临的一个共同问题:根据直觉或客户和利益相关者最强烈的意见进行决策。

  • 它为优先级讨论创造了透明度,将整个公司的每个人都带入一个共享空间。这消除了与利益相关者和面向客户的团队合作时的大量摩擦。

  • 它与交付工作相关联,因此路线图不会过时,并在考虑交付限制因素时保持诚实。

如何整理产品待办事项

想法、机会、问题、解决方案:产品团队需要决定把什么放到产品待办事项中。这些应该是团队试图优先考虑的内容,代表了团队对产品投资和优先事项的思考。

发现待办事项
不同的利益相关者群组如何与产品待办事项交互。

对于产品团队来说,控制产品待办事项中所包含的内容以及用于对想法进行分类和优先级排序的结构非常重要。否则,他们就有可能让待办事项列表陷入他们一开始就想避免的那种无序状态中。

要控制待办事项列表,应邀请外部利益相关者仅以预先确定的方式做出贡献,而不是拥有直接创建和编辑项目的权限。例如,这些协作者可以添加评论、对想法进行投票或标记请求功能的客户。

产品待办事项的不同类别的贡献者
产品待办事项的不同类别的贡献者。

以下是两个推荐的产品待办事项结构框架:巨石、岩石和卵石,以及长列表、中列表和短列表。我们建议围绕这三个桶和这些活动来整理产品待办事项。

在 Jira Product Discovery 中,这可以通过配置特定视图来显示正确的想法,并选择显示哪些字段来帮助讨论(选择、评级)和邀请协作(洞察信息、投票、评论、反应)来实现。

巨石、岩石和卵石

许多产品团队只有一种对象类型:“想法”。但是,待办事项列表可以包含不同形式、大小和粒度级别的项目,大到新赌注,小到产品改进。

常见的做法是使用三类项目来构建待办事项列表:

  • 巨石:大规模投资、战略机会和大的新赌注

  • 岩石:中等规模投资、推动成果的实质性产品改进

  • 卵石:小规模投资,如修复“剪纸”式的缺陷和用户体验问题

最好在产品待办事项中为这些投资创建单独的区域,并考虑平衡这三种投资,为每种投资预留预算和路线图空间。尤其是卵石,如果没有这种意向性,就很难确定其优先级。虽然大规模的新赌注令人兴奋,但一些“小缺陷”会加剧对用户体验的负面影响。

有关此框架的更多信息,请参见想法部分。

JPD 路线图
“巨石”的视图。
“卵石”的视图
“卵石”的视图。

长列表、中列表和短列表

Jira Product Discovery 的早期采用者之一 Brent Johnston 提出了另一种简单实用的产品待办事项构建方法。Brent 将产品工作描述为不断处理 3 个桶:长列表、中列表和短列表。

产品团队通过邀请全公司的利益相关者合作,将想法从长列表精简到中列表再到短列表,然后再纳入到产品待办事项中。

不同的利益相关者群组如何为长列表、中列表和短列表做贡献
不同的利益相关者群组如何为长列表、中列表和短列表做贡献。
  • 长列表包含所有内容:“总有一天,也许会有想法”、问题、机会或解决方案。这个列表上可能有 200 多个想法。

    • 产品团队利用他们对市场的了解、战略和运营问题的了解以及客户和业务需求,对这个长列表进行整理,将其转化为中列表。

  • 中列表是对潜在优先事项的预选:团队可以合理投资的有吸引力的机会。在包含 200 个想法的长列表中,可能有 10 到 20 个想法可以进入中列表。

    • 这些想法看起来是合适之选,因为它们在战略上很重要,经常出现在与客户的讨论中,或者具有让用户满意的巨大潜力。我们必须确定这些想法的优先级以形成短列表,通常要听取公司不同利益相关者的意见。

  • 短列表基本上就是产品路线图:产品团队承诺进一步探索的想法。这些任务将机会、问题或解决方案付诸行动,开始创造产品体验或改进现有体验。

    • 团队会根据他们所了解的情况定期审查这个列表,并不断更新。公司的其他成员也会定期收到这个列表的更新信息。

产品待办事项,经过整理用于存放客户请求
产品待办事项,经过整理用于存放客户请求。

如何在 Jira Product Discovery 中创建产品待办事项

我们创建了 Jira Product Discovery,作为产品团队收集想法、就想法进行协作和确定想法优先级的地方。在 Jira Product Discovery 中,您可以创建一个或多个产品待办事项,称为“发现项目”。

一般来说,最好将日常一起工作的人员放在同一个项目中(例如一个小队或多个小队)。不过,也有不少 Jira Product Discovery 客户使用单个项目来管理多个团队和产品。当这些团队之间需要高度协作时,这一点尤其有用。

下面演示了如何做到这一点:

使用 Jira Product Discovery Premium 计划,您可以创建视图来显示来自多个项目的想法,并讲述组织产品计划的整个故事,从而在一个地方可视化多个项目的想法。

后续事项

在本手册的其余部分,我们将详细介绍如何使用产品待办事项来完成以下工作:

我们将举例说明我们如何在 Jira Product Discovery 团队中使用 Jira Product Discovery 和其他产品来做到这一点。