重组 Braze 产品团队

任何软件产品背后最重要的驱动力是构建它的一群人——以及他们之间的关系。 因此，重要的是要以一种允许他们拥有尽可能多的影响力和影响力的方式来安排团队。

在 Braze，我们对产品和工程组织的设计方式进行了广泛思考，并希望分享我们从重大部门重组中获得的经验，这有助于我们极大地改进功能优先级、开发团队专业知识和更有效地构建产品的方式。

早期结构：产品/市场契合度及其他

寻找产品/市场契合度——并利用它来发展业务——是所有初创公司都必须经过的考验。 在初创公司发展的整个阶段，实验速度和快速利用机会的能力至关重要。 为此，我们最初的产品团队结构是这样的：

这种根据职能专业划分我们团队的结构之所以运作良好，有几个原因。

首先，它使我们能够在产品/市场契合的过程中有效地应对产品转型变化——专家可以拥有我们的大量代码库，并使用他们最熟悉的语言、框架和设计决策。 在大量咖啡因的推动下，一体式项目“团队”经常处理巨大的努力。 其中包括构建我们面向客户的公共 API 和彻底改造我们的整个消息发送基础设施，通常担任唯一工程师、产品经理和设计师的角色。 这些极端措施对大公司来说是疯狂的，但在早期成长过程中是必要的，而且几乎是例行公事。

此外，这种结构帮助我们在只有 10 到 15 人的团队中深入掌握了某些技术领域。 我们核心产品的许多元素——例如我们前端的模型-视图-控制器层、API 和高吞吐量的消息发送代码——只有少数人完全理解。

当时，这很简单，而且我们所需要的一切。 当速度就是一切时，基于简单指导的组织有助于减少认知开销，并使我们能够将注意力集中在可以发挥最大作用的地方。

后期结构：增长和扩展

然而，随着我们的团队超过 30 或 40 人，这种结构开始瓦解。 我们最终确定重组产品团队是解决我们面临的一些最大挑战的方法。 我们正在花费不可持续的努力来兼顾技能和时间表来为战略项目组建团队。 我们还花费了过多的时间来确定优先级，并且经常发现自己在整个业务中强制对所有产品优先级进行排序，因为我们基于技术的团队结构没有直接映射到最重要的产品需求。 最后，我们几乎没有机会让团队成员在特定客户用例方面积累深厚的经验。

我们最终转向了一个围绕敏捷跨职能团队构建的组织，类似于 Spotify 推广的 Squad/Tribe 模型。 我们的新组织结构如下所示：

我们团队的大多数人都在“产品垂直领域”工作，对应于我们产品或业务的关键领域。 例如：

• 我们的电子邮件和企业团队从上到下运行电子邮件，以及某些产品领域，例如对我们许多最大客户至关重要的权限管理。
• 我们的消息传递和自动化团队拥有与用户细分、消息传递和我们的旗舰编排产品 Canvas 相关的多个产品领域。

在一个垂直领域，我们希望优先级（相对）简单，因为每个垂直领域都对应一组特定的客户需求。 视觉设计、DevOps 和我们的基础设施工程团队等特定团队跨越整个平台，在关键领域建立一致性。

影响

我们的重组显着减少了跨团队的依赖。 以前，我们一直在努力解决类似数独的调度问题，即在给定时间将专业技能集（工程、设计、产品管理等）的适当平衡分配到给定项目中。 它还调整了短期激励措施——在过渡之前，团队经常发现自己依赖于目标不相关的对手。 借助我们的新结构，产品团队变得独立，对时间线有更多的控制权，并且在目标上完全一致，从而提高了生产力和士气。

新的组织设计还改进了优先级。 例如，我们的电子邮件和企业团队可能需要在升级我们的电子邮件基础设施、构建核心电子邮件功能或修复企业可用性问题之间做出决定——这是一个简单且易于量化的决定，因为这三者都以类似的方式与客户的需求相关.

一个为太多高优先级需求而苦苦挣扎的团队也表明他们的产品领域需要更多资源。 这使我们能够将困难的优先级问题重新定义为人员需求，这些问题仍然具有挑战性，但在概念上很容易解决。

最后，将大多数团队专注于特定产品领域，可以让个人随着时间的推移建立深厚的专业知识和高效的工作关系。 最初，在构建的最初几年，个人基本上可以将整个产品和代码库放在脑海中，但随着我们的发展，这变得不可能。 产品问题是分形的：每次你仔细观察，你会发现更多的细微差别和深度。 因此，在产品或代码库的特定领域花费大量时间并深入了解其业务需求是实现真正产品突破的最佳方式之一。 此外，创建专注的长期团队可以建立所有权和融洽的关系，并允许一组一致的合作者之间不言而喻的工作关系凝聚在一起。

当然，没有一个系统是完美的。 通过专注于以产品为导向的支柱，我们增加了团队优化本地化需求的潜力，而牺牲了整体优先级。 例如，人们可能会关注本地化的技术债务（“这个控制器很麻烦”）而不是全球性问题（“改变我们的前端框架将提高整体工程速度”）。 出于对这一需求的预期，我们采取措施建立了上述跨领域团队，并为其他广泛的项目使用了专门的委员会——例如，建立一个由前端组件和设计模式组成的整体产品/设计系统的委员会.

我们的新结构还为整体的、变革性的产品变化带来了更高的活化能。 我们产品的某些领域，例如我们的后端 API，由多个团队共同拥有。 对我们代码库的广泛、交叉领域进行全面更改的门槛更高，因此一旦您的产品骨架基本形成，这种类型的结构效果最好。

外卖

总体而言，我们对重新设计的产品组织结构感到满意：我们已经解决或大大改善了围绕团队依赖性、优先级和建立长期产品专业知识的挑战，并且还为我们如何扩展制定了有用的路线图。 特别是，我们了解到：

• 消除依赖和调整激励措施会带来巨大的效率提升。
• 苹果对苹果的优先排序既简单又有效。
• 在特定客户或业务需求方面的深厚专业知识可以带来更好的产品成果。
• 长时间与相同的团队成员合作对于建立良好的工作关系至关重要。

我会向任何共享某些关键特征的团队推荐这种结构：一个跨职能的组织，其中产品经理、设计师和工程师等职能专家是平等的利益相关者； 合并后的产品开发团队大约有 15-20 人以上； 最重要的是，牢固的产品与市场契合度。 如果这种类型的团队结构听起来对您有吸引力，我们正在招聘！