oldwinter 产品和工程的组织设计
构建您的团队，以最大限度地提高自主性、速度和战略一致性。
利用 27 位嘉宾的见解以及 Lenny 的播客和时事通讯中的帖子，帮助用户进行产品和工程的组织设计。
如何提供帮助
- 分析生命周期和目标 - 确定公司是否需要通过 GM 模型实现速度和敏捷性，或者通过功能模型实现产品凝聚力。
- 定义团队边界 - 围绕持久的客户群或结果而不是临时功能构建自主 Pod。
- 分配领导配对 - 在各个级别上配对产品和工程领导，以确保业务战略和技术执行的平衡。
- 实施扩展护栏 - 随着组织的发展以保持速度，添加产品运营等专业角色和清晰的职业阶梯。
核心原则
从项目到项目集的转变
Bill Carr: "Let's create teams that can stand alone, where there's a single leader and the cross- functional resources that they need are all either directly report to them or are dedicated to them. So they don't necessarily have to be a straight line direct report. In Amazon's case, for the most part it was. There were some dotted line, but it could be all straight line, it could be all dotted line, it could be a mix of the two."
从在任务之间转移资源转向以项目为导向，团队无限期地拥有特定的客户领域。这使得单线领导者能够完全掌控长期成果。
统一在单一 CPTO 之下
Claire Vo: "I'm using CPTO for short code of running product and engineering design functionally together. There should be no debates over what's best for product or what's best for engineering, what's best for design speed. What is best for the organization?"
将产品、工程和设计整合到一位领导者的领导下可以消除职能孤岛。这种一致性可以阻止内部争论，并优化整个组织的速度而不是单个部门的目标。
通过功能集中化实现标准化
Dhanji R. Prasanna: "So all engineers report into one single team now, all designers report into one single team and there's single head of engineering, single head of design, et cetera. And so that was the big transformation that we made, and that meant we could really drive forward AI, we could drive forward platform and just technical depth generally."
过渡到职能结构有助于公司调整单一的技术战略。它允许标准化的工程水平和政策，推动整个部门的卓越发展。
公共设计
Heidi Helfand: "I really like it when there's transparency in reorgs. There's a story in my book from Christian Lima at Spotify about how they reorged a large infrastructure team. They visualized it on whiteboards and brought people over to the whiteboards to see the future team structure that the leaders wanted and they got input into the design."
通过在公共白板上可视化拟议的结构来保持重组期间的透明度。尽早让员工参与有助于发现结构性错误并提高对新使命的参与度。
分配 PM 职责
Karri Saarinen: "We actually don't have much PMs in the company. We only have one and we can talk about more about it. One of the things I think that happens is when you build a team and you start creating these very specific roles for everything I think that often the PM can be the ones figuring things out and making decisions and guiding the team, but they're not the ones building the feature."
消除每个团队的专职 PM 可以增加实际构建产品的人员的所有权。将管理任务分配给工程师和设计师可以提高对细节的关注。
只在口渴时才雇用
Varun Mohan: "I want the company to almost be like this dehydrated entity. Every hire is like a little bit of water, and we only go back and hire someone when we're back to being dehydrated."
将每一位新员工视为稀缺资源，等到团队真正陷入困境后再增加员工人数。这可以防止组织臃肿，并确保每个角色对于项目的生存都至关重要。
按客户群组织
Sachin Monga: "The teams aren't oriented around product surfaces. We don't have a team that's like the app team or a team that's like the dashboard team or the podcasting team. We have teams that are oriented around customers and solving bit of a timeless customer problem."
根据团队所服务的特定客户群而不是短暂的功能表面来定义团队。这创建了一个更持久的结构，每个团队都有自己专用的跨职能资源。
模板和框架
- 总经理、职能与混合组织模型决策框架（一般管理、职能和混合模型：哪种组织设计最适合顶级公司？） - 用于决定哪种组织模型适合公司的双因素框架，基于 (A) 北极星指标与收入的接近度和 (B) 霍尔的重要性
- 基于指标与基于特征的团队分类（Duolingo 如何构建产品） - 用于决定是围绕定量指标还是围绕产品任务/问题构建产品团队的框架
- AMPED 团队结构（Miro 如何构建产品）- 跨职能团队结构，将分析、（产品）营销、产品、工程和设计集成到按流组织的统一产品团队中
- Notion 的四层产品团队结构（Notion 如何构建产品）- 一种隐喻的分层团队结构，适用于高度互连的产品，其中任何功能都无法完全隔离
- Linear 的无 PM 项目团队模型（Linear 如何构建产品）- 一个在没有传统 PM 的情况下运行产品团队的框架，其中项目团队充当自己的 PM。
- 责任范围 (AOR) 电子表格模板（如何让您的营销团队发挥更大的影响力）- 从 Asana 的内部系统学习的电子表格模板，用于创建跨营销和跨职能团队的所有权领域共享列表。
- 产品速度的组织设计原则（Ramp 如何构建产品）- 构建产品组织以最大限度地提高速度和协作的三个原则
- 管理模糊所有权的三种方法（本周＃9：突破增长，以影响力领导，以及（而不）踩到脚趾🦶） - 随着 PM 团队规模的扩大，从最简单到最复杂的一套渐进策略，用于处理不明确的产品领域所有权
- 公司阶段→组织模型进展（综合管理、职能和混合模型：哪种组织设计最适合顶级公司？） - 基于生命周期的框架，显示随着公司从早期阶段成长为成熟的多产品公司，组织结构通常如何演变
- PM 职业阶梯设计决策清单（产品管理职业阶梯）- 构建 PM 职业阶梯时要做出的关键结构决策，源自 20 多家公司的模式
有关详细信息的完整列表，请参阅 references/artifacts.md。
帮助用户的问题
- “您现在的主要目标是业务速度和敏捷性，还是产品的凝聚力和一致性？”
- “目前降低您的交付速度的三大跨团队依赖性是什么？”
- “您的团队目前拥有功能（输出）或业务成果（指标）吗？”
- “目前你们的产品、工程和设计部门有多少人？”
- “您是否有明确的职业阶梯，以减少规模扩大时角色的模糊性？”
- “您的团队是围绕技术层还是客户群构建的？”
标记的常见错误
- 人员过多的项目 - 添加太多人员会造成沟通开销和组织腐烂，从而减慢执行速度。
- 复制粘贴行业标准 - 实施其他公司的模型而不使其适应您独特的文化和产品媒介通常会导致摩擦。
- 孤立的产品和工程 - 未能将 PM 和工程领导配对会导致战略不一致和执行瓶颈。
- 将组织设计视为静态 - 组织是必须迭代的产品，以便随着业务的发展为团队提供最大的自主权。
- 秘密设计重组 - 隐藏的设计流程会导致员工焦虑，并错过来自最接近工作人员的宝贵反馈。
深入探讨
有关 27 位嘉宾的所有 50 条见解，请参阅 references/guest-insights.md
相关skill
- 招聘产品人才
- 面试评估候选人
- 建立成长团队
- 创始执行团队