Notion如何打造产品

上周，我正在家中的办公室工作，听到妻子在另一个房间喊道：“我太喜欢 Notion 了！” 我明白她的意思。全球有超过 2000 万用户和数十万个团队使用 Notion 来组织工作和完成任务，她并非特例。Notion 目前是全球第四大增长最快的应用（去年它曾位列第一），而且，毫不意外，在我这个关于顶级产品团队如何打造产品的系列文章中，Notion 也是最受读者要求来讲一讲的团队。

我激动地终于要发布这一期内容了，这段等待是值得的。衷心感谢 Michael Manapat，Notion 的首席产品与技术官，以及整个 Notion 团队，耐心回答了我的诸多问题。和往常一样，你将看到大量可操作的实践经验和框架，而且这一期比以往任何时候都包含了更多即插即用的模板。

关于 Notion 打造产品的方式，以下几点最让我印象深刻：

• 他们在超高速增长过程中所经历的大量迭代

• 他们拥有的产品经理数量之少（类似于 Ramp！），以及他们等了多久才招聘第一位产品经理

• 他们的四点产品评审流程

• 所有产品之间的互联程度，以及这对他们组织设计的影响

• 他们每年两次的规划周期、两周的冲刺节奏，以及超过一个季度的规划频率（类似于 Coda！）

• 他们从主要依赖异步产品反馈，转向更注重实时对话的转变

• 数据、设计、工程、产品均向 Michael 汇报，以及这种架构背后的原因

  此外，如您下文所见，Notion 将于明日（5 月 31 日）推出 Notion Projects。Notion Projects 将项目管理与文档、知识库及 AI 整合于一个互联的工作空间中。点击此处了解更多。

  欲了解更多 Michael 的分享，请在领英和 Twitter 上关注他。如想获取更多关于顶级产品团队如何运作的案例，欢迎阅读我对 Figma、Coda、多邻国、Miro 及 Ramp 的深度解析文章。

Notion 如何打造产品

Michael Manapat，首席产品与技术官

1. 你们的详细规划跨度是多长时间？这些年来发生了怎样的变化？

我常开玩笑说，我们每个规划周期都会改变规划方式，甚至需要为规划本身再做规划。过去，我们基本不会考虑某个半年周期之外的事情。后来我们意识到这其实是个问题——我们总是在解决未来几个月内能完成的事，却没有以更全局的视角思考长远发展。目前我们正在探索如何兼顾常规规划带来的协调严谨性，同时为更宏观的未来思考留出空间。

话虽如此，我们大体上仍以半年为周期进行规划，但对两个季度的规划精细度有所不同。例如今年年初，我们要求第一季度要详细列出所有项目并排定优先级路线图，而第二季度只需列出几个高层级的要点，说明计划开展的工作。随后在第二季度开始时，我们会基于这些要点制定具体方案，同时根据公司战略在第一季度与第二季度之间的变化补充新的指导意见。

复制 Notion 年度规划练习模板 →

关于团队在每个季度内的运作方式，从理念上讲，我不喜欢强制推行全组织统一的工作流程——至少在团队如何自我管理这方面是这样。（不过我们在产品评审上确实有组织层面的统一流程，详见下文。）我们通常让各个小组或团队自行决定适合自己的节奏。然而，目前所有产品团队都采用双周冲刺周期，并且这些周期在整个组织内保持一致。就在昨天，全公司刚刚开始了新一轮的冲刺周期。

各个团队在冲刺中的具体做法差异很大。有些团队非常严谨和精确——他们会列出所有预计要完成的任务承诺，并在冲刺结束时评估该周期内实际完成了哪些工作。而对于那些从事基础设施等长期工作的团队来说，冲刺更多只是时间单位，而非问责机制。因此，唯一真正统一的就是这个双周周期，但具体团队内部的做法则多种多样。

Notion 的新冲刺功能，将于 5 月 31 日上线

我一直在想——我们公司只有 550 人，规模不算大——能不能更灵活一些？我们清楚自己的战略和总体目标，那能不能采取更持续的方式？“让全世界停下来确定接下来半年的计划”这种做法固然重要，尤其有助于与市场团队及其他跨部门团队协调，但在产品团队内部，我不确定这种方式是否能很好地满足我们的需求。不过，我目前也还没有找到更好的方法。

2. 你们有多少位产品经理？

15 人以下。在 550 人的团队中。我们的产品管理团队规模很小。你可能知道，我们等了多久才开始招聘产品经理。直到两年前，我们才引入产品经理这个角色，当时工程师团队大约有五六十人。我不确定这算不算理想状态。无论是 Notion 还是我之前任职的 Stripe，早期都非常以工程师为主导，两家公司都拥有极具产品思维的工程师核心，这其实是一件很好的事情。话虽如此，具备产品思维的工程师与真正的产品经理之间还是有区别的——产品经理会主动与用户交流、持续收集用户反馈、紧密配合市场推广团队，并深入思考产品战略。而我认为，Notion 在早期确实缺少了这样的角色。所以我很高兴现在我们有了产品经理，并且产品管理团队也在不断壮大。

Notion 的一个有趣之处在于，它的产品功能几乎无法真正独立开来。在 Stripe，有很多基本上完全独立的产品线。在我负责的团队中，各产品之间的联系仅在于构建它们所需的能力（除了常规产品工作，还需要机器学习和人工智能方面的深度支持）。例如，有 Radar，这是一个风控产品；还有 Capital，一个借贷产品。它们的共同点是都基于机器学习和人工智能技术，但除此之外彼此独立——Radar 所做的工作几乎不会影响 Capital，反之亦然。但 Notion 无法拆解成独立的产品。如果你在 Notion 负责项目管理功能，而你改了数据库的工作方式，或者改了页面的工作方式，这都会影响 Notion 作为文档工具或维基工具的使用体验。因此，这里更需要一种整体性的规划和产品协同机制，确保各项工作被全局性地考量，避免相互踩脚，导致产品体验变差。

3. 你们会以某种形式使用 OKR 吗？

会的，我们在公司层面将 OKR 作为规划的一部分来使用。每半年一次的规划周期，其产出就是一组公司目标以及一组关键结果。

复制 Notion 的公司目标模板 →

在公司级 OKR 之下，情况则更为多样。部分团队或小组会使用 OKR，例如负责产品驱动增长的团队。而在其他领域，由于事情尚处于早期阶段，我们的很多关键结果最终变成了“把某个东西发布出去”。坦白说，对于我们而言，当大部分工作都是“从 0 到 1”的探索时，如何真正衡量成功，也是一段摸索的过程。这具体意味着什么？什么样的框架才合适？可以说，我们与谷歌相去甚远——他们在公司、部门、团队乃至个人层面都设有 OKR。

4. 你们的产品/设计评审会议是如何进行的？

这是我们一直在不断迭代的另一个领域。过去，我们有一种称为“工作交流会议”的形式。会议时长通常在30到45分钟之间，结构相对松散。当团队希望与产品负责人讨论某事，或者我们有事情想和团队沟通时，我们就会直接提议开会，议题通常比较概括。结果这些会议最终基本上变成了头脑风暴或创意构思会。

我们发现，需要增加一点结构，以确保工作能顺利推进。同时，我们也希望确保[Notion 联合创始人西蒙·拉斯特和伊万·赵]以及我本人的反馈能在固定的节点给出，而不是比如在产品发布前两天才突然冒出来。

因此，现在我们在产品开发流程中设定了四个节点，进行“进度同步会”。这四个节点分别是：

1. 用户问题的陈述

2. 对可能方向的讨论——解决用户问题的三四种高层次可行方法是什么，团队推荐哪一种？

3. 完整解决方案，包含高保真设计及所有范围界定的内容

4. 可发布的候选版本，已准备好进行最终质量检查

   所有这些流程主要以异步方式进行。在每一步，工程师、设计师、产品经理或工程经理都会发送邮件说明当前进展，然后我们会异步进行审阅并给出反馈。讨论的内容范围很广，从“用户的具体问题是什么？”到“这个功能与另一个功能如何交互？”，有时甚至会涉及产品中一些非常细枝末节的点。

   不过我们发现，异步沟通并不适用于某些类型的讨论。比如：你们探索了哪些方案？对每个方案是如何考量的？为什么最终选择了这些方案？要把这些内容整理成文档并用书面形式解释清楚，会耗费大量时间。大家花在记录这些内容上的时间太多了，如果再算上邮件往来和回复等环节，整个流程就会拖得很长。

   因此，我们目前正在调整方法。在探索方向的阶段，我们将开始侧重于与团队进行面对面的讨论。大家聚在一起，共同研究 Figma 设计稿，讨论各个方案的优缺点，提出问题，并就背后的逻辑达成一致。我们通常会将这类同步沟通安排为半小时。有时会更快，有时则会稍长一些（昨天我们就开了一次，稍微超时了几分钟，共用了 40 分钟）。

   我们直到今年二月才开始采用这种四阶段的沟通流程。最初，我们要求几乎所有产品工作都遵循这一流程。当然，我所说的“所有”并不是指每一个微小的改动，而是任何能带来实质产品影响的项目都要走这个流程。由于我最近才刚与产品团队共事，这一流程帮助我了解到了所有正在推进的工作。但在下一阶段的迭代中，我们将引入分级机制，只有 P0 级别的项目才需要由我来审核。

5. 产品和设计是否同属一个组织？产品经理最终向谁汇报？这些年来这个结构有变化吗？

我们拥有一个统一的产品与技术组织——工程、产品管理、设计、数据、用户研究以及安全，这些部门都向我汇报。我们的数据负责人、设计负责人、研究负责人、工程与产品管理小组负责人、用户研究负责人，再加上负责整体技术方案的人员以及我们的 CISO——他们都是同级别的同事，也是我的直属下属，我们频繁地一起开会和制定计划。

我个人非常喜欢这种模式，因为你能在同一间会议室里听到来自所有这些人的不同观点，并了解他们各自的工作进展。如果回到一年前，Janna 和 Daniel，他们虽然各自的职能都涉及了解我们的用户、用户需求、用户行为等，但却不常出现在同一个讨论场合中。

但现在每个人都能看到整个组织在推进的工作，而且法特梅可以听到我们的企业产品负责人比尔坎在讨论与特定规模用户合作的计划，并据此明确自己需要做哪些准备。我认为，当领导团队构成如此多元时，会有更多事项被主动提上议程。

6. 你们的产品团队是如何组织架构的？

目前我们大致分为四个团队层级。首先是负责面向用户的功能场景或工作流的团队，例如项目管理团队、文档与知识库团队。他们需要确保 Notion 能通过组合现有基础模块、按需扩展模块以及开发定制功能，妥善解决用户在该场景下的问题。而在其之下（打个比方），是负责所谓”底层基础模块”的团队，比如 Notion 中的数据库。实际上，wiki 和项目管理都依赖数据库驱动，因此负责 wiki 的团队和负责项目管理的团队都是这个数据库团队（我们内部称之为”集合”）的”客户”。

再往下是覆盖全 Notion 的系统，如搜索、通知、侧边栏等，由一位产品负责人——Ekin——统筹管理。最底层则是基础设施团队。这就是我们目前的大致分层方式。（需要说明的是，这些层级只是比喻，并非严格对应组织结构。）

有时，某些工作并不总能完全归属于某一个团队。我们有一个产品团队，负责整体思考企业级细分市场的需求，尽管他们的日常工作通常聚焦于特定角色（如企业买家或管理员）所需的功能。但基于这种整体细分市场的关注，他们需要考虑诸如：拥有 2 万名用户的公司对 Wiki 产品有什么需求？答案是，他们需要对页面进行验证。于是，该团队会去推动实现这一功能，即使最终由其他团队来构建（现实情况正是如此）。此外，从数据驻留、数据本地化或安全性的角度，这些大型企业又有什么需求？相应的产品经理也会与基础设施团队沟通。大公司还需要 Notion 能与其他工具良好协作，这就需要对我们的 API 和集成功能进行开发——这属于中间层的一部分。因此，那位产品负责人 Birkan 实际上是在 Notion 各处开展工作，并不单纯属于某一个团队。

7. 你们产品团队的工具有哪些？

我们在几乎所有工作中都使用 Notion——写作、项目管理、演示文稿等等。我们衷心希望，对于产品团队而言，Notion 能够成为他们一切工作的中心。这里的“几乎”指的是，在产品开发中一些重要的工作——例如设计（我们使用 Figma）、实验设置与分析（我们使用 Statsig）或数据分析（我们使用 Hex）——无法在 Notion 中完成，而且这些场景至少在短期内并不适合纳入 Notion。当然，你可以将许多这类工具中的工作嵌入到 Notion 中，这有助于让 Notion 继续充当所有工作的“中心枢纽”。

项目管理对我们来说至关重要，这一点毫不意外——既体现在我们内部如何运作项目，也关乎 Notion 如何让用户在与其他知识（如文档、维基、会议记录等）互联的工作空间中管理项目。过去，要想在 Notion 中搭建类似其他专业项目管理工具那样的框架（包含项目、任务、子任务等），通常需要大量的前期设置。虽然借助 Notion 基础组件的通用性可以实现，但并非易事。本周我们将推出一项令人振奋的重大更新——无论是通用场景，还是工程与产品团队的议题追踪，使用 Notion 进行项目管理都将变得易如反掌，并且会直接支持冲刺等机制。从 31 日起，你可以在任何团队空间中添加我们的全新项目管理工具 。

复制 Notion 的项目模板 →

Notion AI 也正在扩展功能，能够自动推断并帮你补全信息——当其他信息发生变化时，项目属性也会随之自动更新。我们认为，这将是人们使用 Notion 进行项目管理方式的一大进步。