PD · FW · 130
分层团队架构
Layered Team Architecture · layered-team-architecture--how-notion-builds-product
解决什么问题
高度互联的产品（改动一处影响多处）如何组织团队，既让团队有清晰 ownership，又不至于互相踩踏。
核心内容
四层团队结构（比喻性层级，不完全对应组织架构）：
- 用例层（User-facing use cases/workflows）：面向具体用户场景，如项目管理团队、docs & wiki 团队。负责确保该场景的用户问题被 Notion 很好解决
- 原语层（Underlying primitives）：提供底层能力，如 Databases（内部叫 "Collections"）。上层团队是这一层的"客户"——wiki 和项目管理都依赖数据库
- 全产品系统层（Notion-wide systems）：搜索、通知、侧边栏等，由一个 PM lead 统管
- 基础设施层（Infrastructure）：最底层
特殊情况——跨层角色：企业 PM 团队不归入任何单一层，关注特定角色（企业买家/管理员）的需求，需跨层推动。例如：发现 20000 人的公司需要页面验证 → 向 wiki 团队倡导；需要数据驻留 → 和 Infrastructure 沟通；需要与外部工具集成 → 推动 API 和 integrations 工作（中间层）。
适用边界
Michael 明确说明这些层级是"metaphorical"的，不完全等于组织架构。适用于产品各部分高度互联、无法独立拆分的场景；如果产品线相互独立则不需要这种结构。
关键引述 · 原话
"You can't decompose Notion into individual products." — Michael Manapat
关联卡片
与 onion-layer-product-design 直接对应：产品架构（原语→用例）映射到团队架构（原语层→用例层）；与 unified-pd-tech-org 互补，后者是领导层设计，本卡是执行层设计。
出处：Michael Manapat · 02-newsletters/how-notion-builds-product.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2