Marty Cagan 认为产品管理行业正在经历一场清算：疫情过度招聘 + 资金成本上升 + AI 冲击，让 Feature Team PM（本质是项目经理）变得极其脆弱。更致命的是，行业 90% 的内容、培训、认证都在教错误的产品管理。真正的 PM 负责 value（客户价值）和 viability（商业可行性），是创造者而不是协调者。但大多数 PM 连这个定义都说不出来。
Marty 说让他"上火"的导火索是一篇来自最大 PM 认证机构的文章，配了一张大图描述"PM 的工作内容"。他看了之后的反应是：这 100% 是项目管理，他们甚至没有假装放一点产品相关的内容进去。
这揭示了一个系统性问题：新入行的 PM 在线上搜索"如何做产品经理"，90% 的结果来自 Feature Team 世界——包括文章、书籍、会议演讲、社区讨论。善意的人在社区里回答问题，但他们分享的是在"糟糕公司"学到的做法。这成了一个自我繁殖的循环。
有人在社区里提问，一群好心人跳出来用他们在烂公司学到的方法回答，提问者说"谢谢，我懂了"。而我在旁边看着想：完了，又失去一个。
— Marty Cagan
Marty 的核心区分：Feature Team 被给一个功能列表（output），Product Team 被给一个问题（outcome）。
Feature Team 的 PM 收到来自高管、大客户的功能需求，设计、开发、测试、上线。这是有价值的工作，但本质是项目管理。Product Team 的 PM 每季度收到 1-2 个需要解决的问题，不限定解题路径，用 outcome 衡量——上线不算数，解决问题才算。
一个残酷的测试：如果你团队里的人抱怨 PM 没用，这几乎可以确定你在 Feature Team。因为在 Feature Team 里，PM 确实没有带来独特价值——工程师和设计师完全可以自己管理那个 Jira backlog。
Marty 认为 PM 职业最大的悲剧是信息环境被污染了。认证课程教的是 Jira backlog 管理；畅销书描述的是 Feature Team 经验；LinkedIn 上的"PM 成长建议"大多来自从未见过 Product Team 的人。
唯一的出路是批判性思维。他建议 PM 在面试时做一件事：研究你未来直属上司的背景——在 LinkedIn 上看他之前在哪些公司、做什么产品。因为你的成长 80% 取决于谁 coach 你，而不是公司品牌。
Marty 最受不了的说法是"PM 的工作是说 why"。他的反驳很直接：说 why 只需要 10 分钟，你剩下一周干什么？而且 why 来自产品策略，那是产品领导做的事，不是你的 job。
真正的 PM 是和设计、工程并肩创造的人。要做到这一点，你需要：成为用户和客户的专家（他被要求亲自拜访 30 个客户才能上岗）、成为数据专家、理解合规/销售/营销/法律/定价等商业约束。
如果你不想在团队里放一个懂这些的人，你打算怎么做决策？猜吗？还是开一个 20 人的会让委员会来决定？
— Marty Cagan
Marty 的框架：工程负责 feasibility（能不能做），设计负责 usability（好不好用），PM 负责 value（客户要不要）和 viability（商业行不行）。
Viability 在 AI 时代变得更重要。概率性软件 vs. 确定性软件带来了前所未有的合规和伦理问题：如果这是关键业务，你能接受一个概率性的答案吗？这个问题正在落到 PM 身上。
Marty 明确说：远程员工的速度和创新都受到了打击。他承认这是一个"宗教话题"，但坚持自己在大量公司的一线观察。
他的立场不是回到全员坐班，而是承认一个事实：创新的速度和深度确实在下降，而很多公司在假装这个问题不存在。
Marty 画了一个光谱：一端是 Product Owner（Jira backlog 管理员），中间是 Feature Team PM（项目经理），另一端是 Empowered PM（负责 value + viability 的创造者）。
AI 从最左端开始吃。backlog 管理已经可以被 AI 大幅替代；Feature Team 的项目管理也在被侵蚀。但 viability——理解合规、法律、商业模型、伦理——这些需要深度判断的工作，AI 目前做不到。
NVIDIA CEO 说不要学编程。我不确定这是好建议，但一个世界上最厉害公司之一的 CEO 说了这话，这本身就是颠覆性的。
— Marty Cagan
Marty 新书《Transformed》提出了"产品运营模型"（Product Operating Model）——他观察到最好的产品公司共享的 20 条原则。三个维度：
1. 如何决定做什么——产品策略是领导做的，不是团队自己决定的。Meta 的 Zuck 制定战略方向，团队负责执行——这不是"自上而下"，而是各司其职。
2. 如何解决问题——Product Discovery 的核心原则：拥抱实验、快速验证、负责任地测试。
3. 如何交付——小批量、频繁、解耦发布；全量监控和埋点。大多数好的产品团队每天发布约 20 次。
Marty 的建议是：太早招 PM 会制造冲突。在产品找到 PMF 之前，value 和 viability 是创始人的工作。太早引入 PM 等于"厨房里太多厨师"。
他的启发式规则：工程师到 20-25 人时，创始人开始管不过来，这时引入真正的 PM（不是项目经理）。招来之后也不是放手——是让他们负责新产品线或新市场。
Marty 最让人振奋的信息：太多人把自己当成公司的受害者——"我困在 Feature Team 里，除了辞职什么都做不了。"
他的反驳：你可以自我评估、提升技能、从 Feature Team PM 升级到 Empowered PM。最差的情况是公司注意到你并提拔你；最好的情况是公司说"让我们试试用你的方式跑几个团队"。
变革不一定要从上到下。一个 IC 也可以从下往上推动——前提是你先让自己变得不可替代。
Marty 的方法论是寻找"最好公司的共性"——20 条原则。但 Netflix 的 Keeper Test、Airbnb 的 CEO Review、Meta 的 Move Fast，这些让各家公司成功的恰恰是它们的差异化做法。如果所有公司都遵循同样的 20 条原则，竞争优势从何而来？共性是必要条件，但不是充分条件——Marty 的框架可能低估了差异化的重要性。
Marty 认为 Feature Team "不值得做"，B2B 销售驱动的产品之所以差，就是因为用了这种模式。但 Oracle 和 SAP 虽然产品难用，却是全球最赚钱的软件公司之一。在某些市场（政府、医疗、金融），合规和客户关系比产品创新更重要。全面否定 Feature Team 可能忽略了不同行业的不同成功模式。
Marty 鼓励困在 Feature Team 的 PM "提升技能，推动变革"。这在硅谷的文化中可能可行，但在大多数传统企业中，一个 IC 试图改变公司的产品开发模式，更常见的结果是被视为"不合群"而被边缘化。Marty 自己也承认"大多数公司对此充耳不闻"——如果连 SVPG 的合伙人都改变不了，一个 IC 怎么能？