永恒客户问题团队制
解决什么问题
产品团队按什么维度划分才不会频繁重组?很多公司(如 Facebook)每三到六个月就 reorg 一次,组织结构的频繁变动本身就是巨大的摩擦成本。
核心内容
Substack 早期产品组织的划分方式:围绕"永恒的客户问题"组队,而不是围绕产品表面(surface)组队。具体结构:作者团队(服务 writers)、读者团队(服务 readers)、增长团队,外加一个没有 PM 的系统工程团队;每个产品团队配 PM + 工程经理 + 数据或设计 + 工程师,是全栈团队。
刻意避免的划分方式:不设"App 团队""Dashboard 团队""播客团队"这类围绕产品界面/形态的团队。原因:产品表面是易变的(ephemeral),客户问题是永恒的(timeless)——"服务作者"这件事永远不会做完,"增长"也永远不是一个能打勾完结的任务;而"播客功能"这种表面,可能半年后就并入别的形态或不再是重点。Sachin 对比自己在 Facebook 的经历(感觉每三六个月就重组一次),对这个结构能稳定这么久感到惊讶,并把稳定性直接归因于"面向客户而非面向表面"的划分逻辑——公司长大后团队数量自然会超过三个,但按客户问题分的骨架可以保持。
适用边界
适合客户角色清晰可分(双边市场的供给侧/需求侧)且团队规模尚小的公司;当单一客户角色下的产品面积大到一个团队装不下时,不可避免要引入二级拆分,那时"表面"维度可能会在二级结构里回归。这个结构也隐含了投入顺序的判断:Substack 先做作者团队、后建读者团队,因为在供给驱动需求的平台上,供给侧是先手(Lenny 在对话中点出这一点:作者去推广自己的 newsletter,读者随之而来)。
关键引述 · 原话
"We have teams that are oriented around customers and solving a bit of a timeless customer problem. We'll never be done serving writers... rather than orienting around what might be a bit more of an ephemeral surface area or product du jour." — Sachin Monga
关联卡片
与"按用户旅程/按客户角色组队"的组织设计讨论同源;"供给侧优先"的次序判断与 marketplace 增长中"供给带动需求"的经典结论一致。
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2