Notion首席产品官公开Notion内部产品规划与决策模式；15人的产品团队如何管理？Notion团队也在用的工具堆栈分享！
这期内容来自Notion首席产品和技术官Michael Manapat的分享，Michael
提到了许多关于Notion在成长过程中所积累的宝贵产品经验。
Notion首席产品和技术官Michael Manapat
Notion作为全球范围内拥有超过2000万用户和数十万团队的组织工作与任务管理应用，其成功不是偶然的，Michael还谈到了Notion所采用的许多独特方法和策略，这些方法和策略正是让他们在如此快速的增长中脱颖而出。
Notion在扩张过程中所经历的大量迭代和持续改进，他们不仅在产品设计方面做到了少数精英，还在招聘第一位产品经理时有着深思熟虑的决策。
此外，他们的产品审查流程、组织设计以及规划和冲刺周期等方面也给我留下深刻印象。
最引人注目的是Notion在产品反馈方面的转变，从主要的异步反馈过渡到更加强调实时对话的方式。
最后，Michael还透露了有关Notion最新项目的消息——Notion Projects，这个将项目管理、文档、知识库和人工智能融为一体的连接工作空间必将引起巨大关注，这篇内容主要分为7个小节：
Notion的产品规划有多远？产品是如何演化的？
Notion有多少产品经理？
Notion 会使用OKR吗？
Notion的产品会议如何进行？
产品和设计是否属于同一组织？产品经理向谁汇报？
Notion是如何组织产品团队的？
Notion产品团队会使用哪些工具？
enjoy👻～
Notion的产品规划有多远？
产品是如何演化的？
Notion 每个规划周期都在改变规划方式，而且我们需要为规划制定规划。历史上，实际上并没有超过半年内想要完成的事项进行深入考虑。Notion已经意识到这其实是一个问题，因为我们总是解决在几个月内可以完成的事情，而没有全面考虑长期的情况，因此也正在探索如何在保持协调严谨和规划纪律的同时，确保有足够的空间来更广泛地思考未来。
话虽如此，Notion大致上会为每个半年进行规划，但两个季度的详细程度不同。例如，今年初 Notion 列出了第一季度所有项目，并对路线图进行优先级排序，而第二季度只需简要列出你认为将要开展的工作要点。
然后，在季度开始时 Notion 便进行第二季度的规划，将这些要点具体化，并根据第一季度和第二季度之间的公司战略变化提供一些额外的指导。
复制👉：https://www.notion.so/templates/notions-annual-planning
在每个季度内，团队运作的方式有所不同。在哲学上，我不喜欢强制规定全组织范围内的流程方法，至少在团队自己运作方面是如此。（Notion确实有针对产品审查的全组织流程，参见下文。）
通常情况下，Notion各个小组或团队自己决定适合他们的工作节奏。然而，现在的情况是，所有产品团队都在两周迭代周期上运作，并且这些周期在整个组织中是保持一致的。实际上，最新的迭代周期是从昨天开始的，全公司都参与其中。
各个团队在迭代周期方面的做法各不相同。有些团队非常纪律严谨，他们实际上会记录下他们认为会完成的所有承诺，并在迭代周期结束时评估确切完成了哪些任务。对于那些从事基础架构长期工作的团队来说，迭代周期更多只是一个时间单位，而不是一种责任机制。因此，唯一共享的是这个两周的周期，但在团队内部人们的做法各有不同。
Notion的规模并不算大，只有550人——公司的战略和整体目标，那么我们可以做一些更加连续性的事情吗？“团队要停下来思考下一个半年要做什么”的做法非常重要，特别是与Notion的市场团队和其他跨职能团队的协调，但在产品组织内部，并不确定它是否特别适合整体的需求。但是我还没有更好的方法。
Notion有多少产品经理？
不到15人。在550人的团队中，Notion的产品管理团队很小，内部等了很长时间才开始招聘产品经理。在两年前，当Notion有大约50到60名工程师时，才开始招聘产品经理。
我不确定这是否真的是理想的做法。Notion和我之前的雇主Stripe都是非常以工程为导向的创业公司，两家公司都有非常注重产品的工程核心，我认为这是一件好事。尽管如此，工程师们思考产品和真正在与用户交流、持续引入用户反馈、与市场团队密切协调并深入思考产品策略的产品经理之间是有区别的。
Michael 认为这在Notion早期是缺失的，所以他很高兴Notion现在有了产品经理，并且Notion的产品管理团队在不断壮大。
Notion的一个有趣之处在于，产品的任何一部分都无法真正孤立存在。在Stripe，有一些基本上是完全独立的产品线。在我负责的小组中，这些产品只是通过构建它们所需的能力相互关联（除了一般的产品工作外，还需要深入机器学习和人工智能）。
例如，有防欺诈产品Radar，还有贷款产品Capital。它们通过都是由机器学习和人工智能驱动的产品相互关联，但除此之外它们是独立的——Radar几乎不会对Capital产生影响，反之亦然。
而Notion则无法被拆解成独立的产品。因此，如果你在Notion的项目管理功能上进行更改，比如改变数据库的工作方式，或者改变页面的工作方式，那么这将对Notion作为文档工具或维基工具的使用产生影响。
因此，在这里需要更多的中央规划和产品协调，以确保事物被全面考虑，并且人们不会以使产品变得更糟糕的方式相互冲突。
Notion 会使用OKR吗？
Notion在公司层面上使用OKR作为规划的一部分。每个两次年度规划周期的输出是一组公司目标和一组关键结果。
模版👉：https://www.notion.so/e44f459c6e9a4c1ba9d8718f33881e4b
在公司层面之下，存在更多的变化。一些团队或小组确实有OKR，例如专注于产品驱动增长的团队。在其他领域，事情还处于初期阶段，以至于Notion的很多关键结果变成了“发布这个东西”，坦率地说，我们一直在努力找出在我们所做的工作中，当很多都是从零到一的工作时，我们如何衡量成功。这是什么样子的？什么是正确的框架？Michael 认为Notion离谷歌还有很大距离，他们在公司、小组、团队和个人层面都有OKR。
Notion的产品会议如何进行？
这是Notion一直在不断迭代的另一个领域。Notion过去有一个称为“工作会议”的形式。会议持续30到45分钟，相对没有结构。当团队想要与产品领导层讨论某个问题，或者有一些想要与团队讨论的内容时，我们实际上只是要求开会，主题是比较高层次的。这些会议基本上变成了头脑风暴或构思会议。
Notion发现需要更多的结构来确保事情顺利进行，另外团队还希望确保Notion的联合创始人Simon Last和Ivan Zhao，以及Michael在已知的时刻提供反馈，而不是在似乎出乎意料的情况下，比如在发布前两天突然提出反馈。
因此，现在Notion有一个流程，在产品开发过程的四个阶段进行“检查”。这四个阶段分别是：
用户问题的陈述
可能的方向讨论——解决用户问题的大致三个可能途径是什么，团队推荐哪些？
完整的解决方案，包括高保真设计和所有范围内的内容
可以发布的候选版本，准备进行最终的质量检查
所有这些都主要是异步进行的。在每个阶段，工程师、设计师、产品经理或工程经理会发送一封电子邮件，描述他们所处的位置，然后Notion会异步地进行审查并给予反馈。
Notion将讨论从“用户问题到底是什么？”到“这个东西如何与另一个东西互动？”到有时候对产品的琐碎细节进行讨论。
然而，Notion的团队发现，异步的检查会议对于某些类型的讨论并不适用。你们探索了所有的选项，你们如何考虑每个选项？你们为什么选择它们？将这些内容放在文档中并以书面形式解释需要很多时间。人们花费太多时间记录这些内容，然后考虑到电子邮件往来和回复等等，这个过程会拖延相当长的时间。
因此，Notion目前也正在调整这些方法。对于探索方向的步骤，将开始专注于与团队进行面对面的讨论。大家一起在Figma上观察，讨论每个变体的利弊，提出问题，并对推理进行对齐。Notion通常将这些同步检查安排为半小时。有时会更快，有时会花更长时间（例如40分钟）。
Notion从今年2月开始进行了这个四阶段的检查流程。起初，Notion的业务团队要求所有的产品工作都要经过这个流程。当然，并不是指每一个细微的更改。但是，任何具有实质性产品影响的项目都需要经过这个流程；作为下一个迭代的一部分，Notion还将引入分级制度，只有P0项目才会由我进行审查。
产品和设计是否属于同一组织？
产品经理向谁汇报？
Notion有一个统一的产品和技术组织，包括工程、产品管理、设计、数据、用户研究和安全都向我汇报。
Notion的数据负责人、设计负责人、研究负责人、工程和产品管理小组负责人、用户研究负责人，以及负责整体技术方向和首席信息安全官的人都是我的同级和直属下属，我们经常一起开会和进行规划。
个人而言，我非常喜欢这样，因为你可以在同一个房间里与所有这些人进行交流，了解他们正在进行的工作。如果回顾一年前，这里负责用户研究的Janna（Lenny在Airbnb工作了很多年，与她合作过！）和负责数据的Daniel，尽管两个功能都涉及到Notion了解用户、他们的需求、行为等方面，但他们并不经常在同一个论坛中交流。
但现在每个人都能看到整个组织正在进行的工作，Notion这里负责核心产品工程的Fatemeh（Lenny在Airbnb也与她合作过！）可以了解到Notion的企业级产品经理Birkan讨论与特定规模的用户合作的计划，并找出她端需要的内容。我认为当你有这样一个混合领导小组时，更多的内容会被积极地提出。
Notion是如何组织产品团队的？
现在，Notion基本上有四个层次的团队。有一些团队负责用户界面的用例、故事或工作流，例如项目管理团队或文档和维基团队。他们负责确保Notion能够通过利用产品中的现有基本功能、根据需要进行扩展以及开发定制功能，很好地解决与该用例相关的用户问题。
在这之下，比喻地说，有一些团队负责所谓的基础基元，比如Notion中的数据库。数据库实际上支持维基和项目管理，因此负责维基的团队和负责项目管理的团队都是这个数据库团队（Notion在内部称之为“Collections”）的“客户”。
然后在此之下，还有Notion的整体系统，如搜索、通知、侧边栏等，有一个产品经理负责监督所有这些事务，他就是Ekin。再往下是基础架构。这是目前Notion的团队划分方式。（需要明确的是，这些层次是比喻性的，与组织结构并不完全对应。）
有时候，并不是所有事情都能清晰地映射到这些单一团队中。Notion有一个产品团队负责全面考虑企业市场，尽管他们的日常工作通常关注的是特定人物角色（企业买家或管理员）的需求。
但是，考虑到整体市场，他们需要思考诸如：好吧，具有20,000个用户的公司从维基产品需要什么？嗯，他们需要类似于页面验证的功能。
然后，即使是其他团队构建它（这就是在这里发生的情况），他们也会去倡导这个需求。此外，他们还需要从数据居住地和数据局部性或安全性的角度考虑需求。该产品经理也与基础架构团队进行交流。
大公司还需要Notion与其他工具良好地协同工作，这就需要Notion在API和集成方面进行工作，这是中间层的一部分。所以，那个产品经理负责人Birkan实际上在整个Notion上工作，并没有明确地映射到一个单一的团队。
Notion产品团队会使用哪些工具？
Notion的团队几乎在所有方面都使用Notion——写作、项目管理、演示等等。对于产品团队来说，大家希望它可以成为（几乎）他们的一切工具。这里的“几乎”指的是在产品中做一些重要的事情——例如设计（使用Figma）、实验设置和分析（使用Statsig）或数据分析（我们使用Hex），这些在Notion中无法完成，而且这些用例在Notion中可能暂时没有意义。当然，你可以在Notion中嵌入来自这些工具的工作，这有助于将Notion作为所有工作的“中心”。
在Notion中如何使用Google Drive和Figma预览来保持一切集中
毫不奇怪，项目管理对Notion的业务团队非常重要，无论是在内部如何运行项目，还是在Notion如何帮助用户将项目作为连接工作区的一部分与其他知识（文档、维基、会议等）一起运行。
传统上，你需要进行相当多的设置才能在Notion中获得类似于其他专门的项目管理工具中的项目管理框架（包括项目、任务、子任务等）。鉴于Notion的基本功能的普遍性，这是可能的，但并不总是容易的。
不久前，在Notion中使用项目管理将会更加简单，无论是一般用途还是针对工程和产品团队的问题跟踪，还将直接支持诸如迭代等功能。现在，你可以将Notion的新项目管理工具添加到任何团队空间中。
模版👉：https://www.notion.so/96cff02a265b4570a44dcf4f4a97e9e2
Notion AI也正在扩展，以便它能够自动推断和完成信息，通过在其他信息自动变化时保持项目属性的更新。Notion认为这将对人们如何在项目管理中使用Notion带来重大进步。
Reference：
https://www.lennysnewsletter.com/p/how-notion-builds-product