1/4
工程师跑太快，PM 反而成了瓶颈 —— Oji & Ezinne Udezue 的 4 个反直觉判断 | Lenny's Podcast 精读 No.009
产品领导夫妻档 Oji & Ezinne Udezue 合计超过 50 年经验，带来 4 个 AI 时代 PM 的反直觉判断：工程师用 AI 大幅提速后，PM 变成新瓶颈；AI at Core vs AI at Edge（在核心逻辑重写 vs 旧产品加功能）决定两种命运；Shipyard「造船厂」框架让 AI 团队拥抱可控的多线并行；以及 Sharp Problem——边界清晰、用户付钱、时机刚好，才是真正值得做的问题。
2026/6/13 · 8:15
ギャラリー
Oji Udezue 和 Ezinne Udezue 是一对夫妻，合计超过 50 年的产品领导经验，先后在 Microsoft、Twitter、Atlassian、WP Engine、Typeform、Calendly 带过产品团队。他们也是《Building Rocketships》的作者——一本关于如何打造伟大产品的实战指南。
这集最有价值的地方在于：他们带着 50 年积累去做 AI 时代的「初学者」，Oji 在 40 岁后重新开始写代码，他们向年龄一半的工程师请教。从这个位置出发，他们看到的 AI 时代 PM 处境，比大多数人诚实得多。
图 1：封面
本期 4 个反直觉判断：
01 AI 让工程师大幅提速，决策者反成慢点
02 AI at Core vs AI at Edge：两种命运
03 Shipyard 框架：拥抱可控的混乱
04 50 年经验的最大教训：「锐利问题」
图 2：AI at Core vs AI at Edge + Shipyard 框架
AI at Core vs. AI at Edge
这是 Oji 在访谈里说得最重的一句话：「仅仅在旧产品上撒 AI 功能，迟早输给那些从零用 AI 重写代码库的公司。」
差别在哪里？旧代码库是按人类决策速度设计的，系统每个环节都有摩擦。新的 AI-native 代码库把决策逻辑直接编进产品流程，用户体验不再割裂。他们观察的公司案例：Atlassian 和 Calendly 的内部 AI 团队正在把核心业务逻辑从头重写，而不是在旧界面上加 copilot 按钮。
Shipyard 框架
传统产品流程追求秩序：一次跑一个实验，等结论出来再动下一步。但 AI 时代的节奏要求多线并行。Oji 把最好的 AI 产品团队比作「造船厂」——厂里同时造十几艘船，不同进度、不同方向，工人在船之间穿梭，整体看起来乱，但每条线都在往前走。
关键是：这种混乱是「可控的混乱」。团队需要清楚每条线的边界和依赖关系，而不是让所有人都不知道彼此在干什么。
图 3：Sharp Problem 方法论
如何找「锐利问题」（Sharp Problem）
Oji 做了 25 年产品，他说真正有价值的问题都符合三个特征：
01 边界清晰
问题的范围明确，不是模糊的大方向。「帮助全球教育系统提效」不是锐利问题；「帮北美高中生在 3 天内完成申请材料整理」是。
02 对的人愿意付钱
目标用户有强烈付费意愿，不是「很多人有这个痛点但没人想掏钱」。
03 时机成熟
这个问题现在可以被 AI 解决，但半年前还不行。时机窗口本身就是竞争壁垒——入场太早，市场不在；入场太晚，格局已定。
反直觉之处：大多数 PM 在找「足够大的市场」，但 Oji 说锐利问题不一定对应最大的市场，它对应的是「现在这个时机最值得解决的问题」。
图 4：金句收束
「工程师已经不是瓶颈了，PM 才是。」
50 年合计经验，见证了从 Waterfall 到 Agile 到 AI 的全部变革。
——Oji Udezue & Ezinne Udezue，《Building Rocketships》作者
Lenny Podcast 精读 No.009
来源
发布日期：2025 年 9 月 7 日 | 时长：1 小时 18 分钟
コメント