首页 文章详情

从混乱到凝聚力:建立可重复的产品流程

李宽wideplum | 162 2021-06-10 20:11 0 0 0
UniSMS (合一短信)

建立可重复的流程

除了仔细考虑团队的结构和指导团队决策的原则之外,规范化的流程也有助于促进凝聚力。正如我们在本章开头所提到的,在流程过多和不足之间存在着微妙的平衡。由你和你的团队决定哪些活动需要规范化的流程,以及这些流程应该如何安排。

在接下来的内容中,我们将分享产品组织在不同阶段的工作流程。这些例子用来启发你的灵感,而不是具体问题的解决方案。

根据目标和关键结果(OKRs)调整组织

当产品负责人 Justin Dilley 在2018年加入 FullStory 时,他的任务是从零开始构建产品管理。

当时,产品决策主要是由核心研发团队驱动的。这个团队主要由前 Google 工程师组成,他们习惯于在传统产品经理的指导下自主工作。

“当我加入时,这个团队(和公司)觉得他们已经发展到这样一个阶段——当我们决定要做什么和如何做时,这些决定开始体现收益递减规律,”Dilley解释说,“他们希望的产品管理,或者说,他们头脑中关于什么是好的产品管理,和我们的产品管理哲学非常契合。”

由于他的产品管理原则与现有团队的想法一致,Dilley能够立即开展产品管理工作。在最初的90天里,他批判性地思考如何将产品管理实践贯穿于整个组织,以及思考决定要招聘多少产品经理。

在早期阶段,我们需要做的只是倾听、学习,以及从宏观到微观层面来理解问题在哪里。从那时起,我们开始尝试在产品管理团队中创建规范和价值观,这可以帮助整个组织在我们为什么决定创建我们能的产品上达成一致,真正提升自己的水平。

——Justin Dilley,FullStory 产品主管

如今,产品团队(或者用 FullStory 的话来说)由大约60个人组成,他们分别从事产品、研发和设计工作。而且,他们已经实施了一个季度的计划流程,他们称之为 OKR 周期,来帮助团队更好地一起做计划和执行。

它是如何工作的

在FullStory,目标和关键结果(OKRs)深深植根于日常运营中,甚至可以说它们是组织文化的一部分。FullStory重点聚焦于OKR,每年设置全组织范围的OKR,以保持高层业务目标是整个组织的中心和前沿。然后组织中的每个团队都致力于他们自己的OKR,并且与整个公司的OKR保持一致。

对于Dilley的团队来说,年度OKR会在一个全面的季度计划会中被进一步剖析和讨论。他解释说:“在每个季度的开始,我们用两周的时间来考虑计划。我们采用自上而下的方法,通常会推出一些更大、更丰富的项目或功能,并且会涉及到不同的产品线。”

一旦在产品组织中定义了更大的且必须做的项目,那么在FullStory类似小组的团队就能够就这些计划自上而下的拆解到自己的项目中。

“在这两个星期里,他们要做一些小规模的讨论和推演,思考他们的使命和他们作为一个小组需要真正关心的事情。他们需要问自己,‘我们认为最重要的事情是什么?然后进行类似的优先级排序。”Dilley解释说。

一旦计划制定完成,团队就进入到了5周的执行阶段。Dilley说,“每个人都埋头致力于他们从结果或OKR的角度,需要要他们完成的事情。在这段时间里,我们会尽量减少干扰和分散精力。我们尝试着用这5周的时间,完全投入到执行模式中。”

但Dilley很快补充道,在制定季度计划时,做出的决定并不是一成不变的。Dilley信奉敏捷和精益的原则,并为他的团队的流程提供了修正计划的机会。

在五周的执行模式之后,是时候出来透透气,用一周的时间思考一下结果。Dilley说:“我们会停下来,用这一周的时间问自己:‘嘿,从季度进展的角度来看,我们还对自己所做的事情,感觉良好吗?让我们做一些必要的调整。’然后,我们马上回到执行模式。”

它为什么能有效

Dilley相信,季度计划和 OKR 周期对他的团队有好处,原因如下:

首先,团队知道什么时候应该专注于执行,什么时候应该更有战略性地思考,并且要让专注更加简答易行。“从本质上讲,我们把五周时间切分两段。我们在每个季度,非常努力地实现着我们的OKR。在中间的一周和开始的两周,我们计划和务实地看待我们在做的事情。”Dilley说。

其次,因为OKR框架对FullStory的每个团队(不仅仅是产品开发团队)来说都是一个熟悉的概念,所以沟通“为什么”就容易得多了。

“我们 FullStory 是一家非常重 OKR 的公司,每个人都有季度和年度 OKR,这意味着 OKR 是一个非常好的沟通机制,可以向公司其他人传达我们正在建设的东西,以及我们建设这个东西背后的细节。”他解释道。

最后,也是这个方法最好的地方,它让产品组织考虑更大的而且是更有意义的项目,以及为了完成他们需要完成的功能。“实际上,我们完成了大事情的计划,同时每个小团队都可以做出个性化的团队决策,他们自己决定什么是重要的,然后适当地调配资源。”这样,小团队的目标和角色也能兼顾到。

如何完成任务
  • 推动组织内的协调,以及对于战略的共同理解

  • 使产品组织有足够的时间进行战略规划

  • 在执行时,消除干扰,提高专注力

  • 经常提供修正计划的机会

标准化的机会评估文档有助于团队协作和清晰的沟通

产品总监Ronnie Regev于2017年加入 Procore 公司,拥有多年的产品负责人经验,在多个组织的产品研发部门见证了产品的快速增长。

他在职业生涯中观察到的最大变革是转向敏捷实践和迭代开发。“理解到价值可以迭代交付,而不是一次性地交付给客户,需要随着时间推移来看到的思维转变,“Regev解释道,“企业内部对价值可以迭代交付而不是一次性交付的理解发生着变化,这是我观察到的组织在理解价值交付方面做出的转变。”

这种思维上的转变是 Procore 的持续做出变革的诸多原因之一。随着时间的推移,团队做出了许多调整,以持续改进他们交付的产品和他们交付的过程。他们目前制定年度和季度计划,并随着团队的成长,而采取措施保持团队透明度和合作。为了帮助产品团队更好地在一起做计划和沟通,他们所实施的一件事对此产生了巨大的影响,那就是机会评估文档。

它是如何工作的

“过去,年度计划总是由产品负责人单独完成的,但我们通过大量员工反馈和其他途径了解到,我们可以做得更好。人们希望在制定计划的过程中,有更多的包容性决策和透明度。”Regev解释道。

那么,Procore 公司是如何创建一个更具包容性和透明度的制定计划流程,并且在目前的企业规模上仍然有效呢?

根据 Regev 的说法,这些团队一起创建了机会评估文档。

Procore 的每条产品线由2至7个小组(小型团队)组成,每个小组可以一起工作,创建自己的机会评估文档。这些机会评估是标准化化的一页纸格式,包含如下关键信息:

•  市场上遇到了什么问题?

•  解决这个问题对客户的价值是什么?

•  解决这个问题对企业的价值是什么?

•  假设条件是什么?

•  进入市场的计划是什么?

•  潜在的业务影响是什么?

然后,在产品线的负责人对这些机会进行评估审查之前,会先将这些机会评估交给每个产品线下的各个小组中。

“最终,我们会产生10倍的机会或想法,然后我们就有了需要追加的资源。”Regev 解释说,“所以作为一个团队,我们看了年度和季度的公司 OKRs,以及我们在收入和留存等方面的产品线目标。”

基于每个机会评估中的标准化信息,团队可以一起工作。他们可以为客户和业务提供最大价值的机会进行优先级排序。

“我们问自己,我们觉得哪一种方式对客户的影响最大,哪一个对我们的业务最有利?决策是集体做出的。也就是说,人们也会意识到,在某些决策过程中,管理者、工程师、设计师和产品负责人中的某个角色会有更大的权重。”Regev 解释道。

随着这些决策的制定,产品线的负责人能够提出他们需要的资源(比如员工数量),以产品线能够交付的目标。

它为什么能有效

•  促进协作构思和制定计划。

•  提供了一套标准化的信息,来产生和构建沟通。

•  无论信息来自于谁,都能确保信息的类型和质量在整个组织中得到一致的传达。

除了为产品开发组织的所有成员创建一个更具包容性、协作性的计划流程之外,机会评估文档还有助于提高信息质量和一致性。“如果产品团队没有这种结构,那么信息的接收者最终将得到失真的信息,这将导致单个产品经理可能做什么,也可能不做什么。”Regev解释说。这有助于确保团队尽职尽责地收集信息,并做出深思熟虑的优先级决策。

在一个规模更大的组织中,信息必须传递给多个小组,然后逐级传递出去。因此首先必须保证信息质量的一致性。

—— Ronnie Regev,Procore 产品总监

利益相关者参与早期计划

在某些情况下,对产品管理架构的需求直到产品团队已经就位后才会被实现。当Scott Williamson(现任Gitlab产品VP,前SendGrid产品VP)在2013年加入SendGrid领导产品管理时,当时的3人产品团队迫切需要管理架构。

“当我加入 SendGrid 时,他们早就不再需要一位产品管理负责人了。他们有一些产品经理,但是他们并没有真正的协作起来。我有机会从零开始构建产品管理,这太棒了。”他说,“我在公司的第一年就采用了轻量级产品流程。它不能太重,因为当时的环境很混乱,我们必须迭代以获得更严格的产品方法。关于构建什么功能的决定通常是基于直觉,并没有一个真正严格的规划过程。所以,我开始尝试制定路线图、处理依赖关系、从组织中获取反馈、尝试将我们自己嵌入到一个以前从未有过的位置,并在那里打下基础,”Williamson回忆说,他还指出,第一年他还尽可能多地采访了客户,了解了市场和竞争情况。

在Williamson加入的这几年里,SendGrid的产品团队(该公司于2019年被Twilio收购,但在该组织仍可以独立运营)取得了长足的进步。团队不仅在规模上有所增长(在 SendGrid ,目前有30名产品经理和5名产品总监) ,而且在架构和流程上也有所进步。根据Williamson的说法,在这个过程中有很多的调整和迭代,但是现在一切都很顺利。一开始,没有正式的架构,甚至没有产品路线图。今天,团队已经形成了一个正式的战略规划周期,帮助他们一起更好地做规划和优先级排序。

它是如何工作的

SendGrid 的产品组织围绕着 Williamson 所说的“年度”计划周期运作。

这个计划周期的第一部分是与高管人员一起进行资源分配和制定预算。根据Williamson的说法,这个阶段的大问题是,“今年我们应该在产品线和项目任务上花多少钱?”在这部分规划过程中,让高管领导参与进来是很重要的,因为Williamson认为,最终应该由CEO来决定在某个特定领域投入多少资金(以及最终有多少人会专注于项目任务)。

大多数情况下,这些决定是根据每个项目对应的市场机会做出的:

•  市场有多大?

•  有多少收入的潜力?

•  项目将提供什么样的全局价值?

Williamson认为,在决定为哪些项目提供资金并且为各产品线和项目准备好预算之后,接下来的细节应该留给产品团队。

由项目的所有者(通常是董事级别的人)来做出项目级别的决定,因为他们更接近细节。高管团队不应该决定项目的具体的史诗级的主题,因为他们没有足够的背景。

——Scott Williamson | SendGrid 产品VP

考虑到他们的预算,每个项目的负责人需要向高管团队清楚地阐明他们打算在项目内开展的计划,并让他们了解团队项目的最新情况。

关于项目的优先级决策留给在负责每个项目的团队。SendGrid 的产品团队要使用 RICE 优先级框架评估项目。

它为什么能有效

•  高管人员参与计划的早期阶段。

•  功能级决策的责任由产品团队承担。

•  可重复且客观的优先级排序方法。

Williamson 认为,他的团队目前的计划和优先排序过程之所以能发挥作用,主要有两个原因。首先,高管从一开始就是这个过程的一部分,减少了以后出现偏差的可能性。其次,有一个客观的、可重复的、一致的方法来做出优先级决定。

减少优先级辩论对我们大有帮助。如果你不能做到这一点,这基本上是任何一个宏观和微观的需求,这真的很难分清轻重缓急。但是我们可以说‘嘿,我们同意在项目Y上花费X。在这个范围内,采用我们的RICE优先机会列表。对于任何拥有这一项目的人来说,这都是一种容易得多的对话,也是一种容易得多的优先级思考过程。

——Scott Williamson,SendGrid 产品管理VP

驱动团队前进的小引擎

流程不需要过于复杂。Drift 的产品团队已经在整个产品开发团队中实施了多个“引擎”——轻量级、可重复的过程系统,以赋予它们产品管理架构。以下是其中的一些引擎:

季度目标流程引擎

像我们在本章中讨论的案例一样,Drift 的产品组织有一个季度 OKR 式的目标流程。每个季度,产品负责人决定为了达到目标而需要做的高级别、战略性的事情,然后各个产品团队从那里接手事情——这样实现目标的责任就可以向外延伸。

双周产品回顾引擎

每两周,每个团队的产品经理都会聚在一起,分享他们彼此之间以及与 CTO 和联合创始人之间的工作成果。

Daniel说,每个产品经理有30分钟的时间来展示,“他们会以一段3-4分钟的视频作为开场,概述自己所做的工作。”

这些短视频在不同团队之间遵循一致的结构——回答了一系列相关问题:

•  留存率怎么样?

•  有哪些Bug?

•  顾客们怎么说?

•  什么正在进行中,什么即将发布?

•  团队在学习和研究什么?

•  有什么对客户的新理解?

在分享视频之后,产品经理们讨论他们的工作,提出问题,并获得反馈。

“它重新定位了团队的任务,并为他们提出的问题的找到答案。例如,我不知道我是否应该根据我学到的东西去追踪这个线索。这就是我们如何运作它的方式。”Daniel说。

Daniel解释说: “从每个产品团队中吸取经验教训真的很重要。”因此,在每两周一次的产品评审之后,团队的所有视频都会在 Slack 上分享,并发布在团队Wiki页面上,以便组织中的其他人能够看到。

交付引擎

对于许多在持续交付或持续集成下运作的组织来说,关于交付内容的沟通可能很棘手。Drift让所有人对交付物保持一致的方式是群组,这个群组的名字很贴切,叫做“交付工厂”(Shipyard)。

当工程师们发布新内容时(Drift公司每天发布5到15次) ,他们会在这个渠道发布的他们发布的内容。

•  他们发布的是什么

•  他们为什么要发布这些

•  谁能获得这些

这使得整个组织都处于关于发布版本的循环中,并且给工程团队一些可见性。

我们所有的引擎都像齿轮——就像手表上的齿轮一样,它们彼此相互作用。

—— Craig Daniel,Drift产品管理VP

永远不会结束

随着团队的不断壮大,我们面临的一个关键挑战是,如何用一些更标准化的方式来完成工作,从而使我们的工作效率更高。

——Justin Dilley,FullStory 产品主管

我们希望你能够在建立自己的流程,并且在思考让团队更好地一起工作的方法时,能够考虑到这些成功的故事。但是我们也想警告说,单独的流程并不能使团队表现良好。伟大的领导者和优秀的人可以让团队表现出色。

在下一章中,我们将缩小范围,看看产品负责人和产品团队如何通过告知、激励和授权组织中的个人,来推动凝聚力和实现更好的结果。

题外话:

本文中提到了很多案例,但是有一个核心主线是打造目标一致的团队。这个目标一致是自上而下的目标一致。能够聚焦在关键目标,让执行团队认同目标,并做后续的执行。

说得直白些,就是把团队拧成一股绳。

参考资料:《FROM PRODUCT MANAGER TO PRODUCT LEADER: Lessons from today's product experts》



  我的新书《B端产品经理必修课2.0》已经开售了。

这是对我的第一本书的全新改版,也是关于B端产品的方方面面。

查看具体内容:我的《B端产品经理必修课》升级了


推荐阅读:

SaaS新用户登录指南(附8个好例子)

SaaS 客户成功: 减少客户流失和提高 MRR 的秘诀

【干货】B端产品差异化指南

SaaS免费模式的本质

10个做SaaS业务的重要原则

[建议收藏]极简SaaS创业手册

[收藏]7个可以调研B端产品的网站

good-icon 0
favorite-icon 0
收藏
回复数量: 0
    暂无评论~~
    Ctrl+Enter