产品判断力做成Skill

• Oji Udezue 曾任 Typeform、Calendly、Parable 三家公司的 CPO（首席产品官），也做过 Twitter 创作与创新方向的产品负责人，现在在自己的咨询公司 Product Mind。→ 详细
• 他在演示中间随口说的一句话是整期的动机："我做了 25 年产品经理，一直到现在，才第一次觉得写代码这件事值得我花时间。"——不是 PM 该转行写代码，而是 harness（承载 AI 干活的那层壳，这里就是 Claude Code）终于让产品判断力可以被写成可执行的东西。→ 详细

*▲ 图注：他立论用的那张图：「3 Layers. One Engine.（三层，一台引擎）」——最底下是 CUSTOMERS（问题、需求、需求量），往上依次是 CODE / HARDWARE（造出真能跑的东西）、PRODUCT（做得有用、可爱、有人肯付钱）、BUSINESS（把价值收上来、把增长做起来）。他的点是：只把 coding skill 装进 Claude Code，等于只自动化了最底下那一层。*

• Oji 的框架：现在 GitHub 上全是各种 skill 仓库——把 token 拉满的、把 token 省下来的、改成本结构的——全堆在写代码那一层。但一家成功的科技公司是三层：软件与硬件；产品（客户和商业模式）；生意（怎么把资源分配到整条链路）。这期要教的是拿 Claude Code 这种原始 harness，不只装 coding skill，还装产品 skill、"随时可调用的产品判断力"和商业 skill。→ 详细
• 他的类比是传统的 triad / quad（PM + 开发 + 设计/产品市场组成的小分队）：运气好的话，这几个人围在一起，"这事值不值得解决""该怎么做出来""故事怎么讲"是被同时想的。现在做的事是把这一整套压缩进一个非常聪明的编排者兼建造者。他特意补了一句：这不代表你不需要专才，大公司永远需要专业分工；但在小团队里，让一个握着关键技能的人手上有一批 agent 帮他出初稿，"威力是大得惊人的"。→ 详细

• 客户找 Product Mind 做的第一件事通常是"把一个产品重新构想成更 AI-native 的形态"，但很快就会被拽进他叫作 shipyard（交付现场）的部分——人怎么组织、AI 时代每个人需要什么新技能、环节怎么咬合。他们立刻看到的现象是：开发（尤其早期采用者）在飞快提速，然后其他所有人都成了瓶颈，特别是 PM——产品判断力没提速，编排（orchestration）能力也没提速，跟不上工程师的新速度。→ 详细

• 这套东西最好的体现是 new project scaffolding skill：起点是你用大白话描述一个商业问题，然后它真的做决策——替你跑市场调研、告诉你这个问题值不值得做、不值得做的话该怎么解，再通过问你问题把架构决策定下来，根据架构推导出这东西该怎么测，甚至连持续集成、持续交付（每次提交自动跑测试、自动发布的那套流水线）都替你搭好。按回车之后 Claude 加载出来的是一个 11 步的工作流。→ 详细
• 打开目录看，它是一组 skill：一个总的 skill.md，下面挂着一堆子 skill——做市场调研的、搭测试的，而且"如果你的项目类型需要新的 skill，它会替你去抓回来"。核心那个子 skill 就是跑 viability gate。Aakash 一句话概括对了："scaffolding skill 本质上是一个编排型（orchestrator）skill"，它调用其他 skill、生成文档、一步步走完 11 步。→ 详细
• 这些 skill "每一个都非常密实"，内置了产品框架：一部分是他们自己那本书《Building Rocket Ships》里写的，一部分是业内公认的框架。组合进来最重要的一个是 sharp problem test。→ 详细
• 整条 workflow 的开头是"收集上下文"：你信息给得不够，它会反过来问你；然后判断项目类型（iOS？Android？），再去网上找参考项目和最佳实践，试着搞明白这东西该怎么建。→ 详细

• viability gate（可行性闸门）的六个维度是：营收、技术可行性、差异化、竞争格局、目标用户定义、问题的清晰度与紧迫性。框架来自他们那本书里的产品管理方法，其他维度还包括问题出现的频率、有没有一个清晰的客户。→ 详细
• 它的输出不是一段意见，是一张评分卡加一个动作。CodeMemo 那次的结果原文照录："viability gate 通过，可以继续：零个弱项、三个强项、三个中等，但不是无条件放行——那三个中等项被标成了 de-risking（降风险）待办清单。"→ 详细
• 拦停规则是写死的：**只要有三个维度是弱的，它会直接建议你这事儿别做了。**Oji 认为这一点最重要——"LLM 是极少会对你说「不」的，而这个 skill 会斩钉截铁地告诉你：绝对不行，别做。"→ 详细

• viability gate 是 sharp problem test 的压缩版，依次过一遍问题是否清晰、目标用户、竞争格局、差异化——它只回答"这条赛道里还有没有你的位置"。→ 详细
• sharp problem test 挖得更深，最大的不同是死磕你到底有没有创造出 3 倍的价值（这条不在 viability gate 里），以及你究竟能不能赚到钱。→ 详细

• 他把这套东西要解决的问题说得极直白：如果你在聊天框里上来说"我有个想法"，那么除非你 prompt 功夫特别好、除非你懂对抗式提问（adversarial prompting，即刻意让 AI 站到你的反面来挑你毛病），甚至有人会拿好几种不同的 LLM 交叉验证——否则你听到的结论一定是：你这想法不错。→ 详细
• 区别在于这个 skill "内建了一份责任"，就是告诉你这想法到底成不成立；而且它不靠模型的直觉判断，落在一套非常清晰、带 evals（评测样例）、按部就班往下走的框架上。→ 详细
• 那该不该完全信它？他自己先否了：不该。"它会产出真实的交付物，你得去检查……但它是你的第一稿，是你一出门就能给你一个「行还是不行」、并告诉你该往哪儿走的东西。"→ 详细

• 他输进去的原始想法很粗：他一直执着于"根本没人会去读代码"，所以想做一个 SaaS 或 agent，帮那些没多少软件经验的 vibe coder 判断自己的代码到底行不行——安全性、健壮性、复杂度、简洁度，"把他们代码的来龙去脉讲给他们听"，因为哪怕在公司环境里也没人在看代码。→ 详细
• 跑完之后它自己写出来的价值主张是："贴一个 GitHub URL，或者上传一个 vibe coding 出来的文件夹，一分钟之内就给你一句大白话的结论：这段代码能不能安全上生产。"Oji 的评价是这个价值闭环"很扎实、很有劲"。→ 详细
• 中间的两份交付物：市场调研包（市场概览、正在塑造这个领域的趋势、直接竞品和相近竞品各自怎么收费、关键结论、周边产品）和 product brief（把想法固化成问题定义、目标客户、核心价值主张、成功标准，再写出可衡量的目标）。写完 brief 它才下沉到代码层。→ 详细

• 第二个想法很常规：做一个叫 Standup Zero 的东西，抓 Slack 里的评论、生成每日站会摘要，技术栈填的是 TypeScript + Slack。他给的指令是"先走到 gate 就停"——因为"如果 gate 说不行，那我们还折腾什么"。→ 详细
• 评分卡出来是偏弱：三项中等，意思是"我不太确定，你要做可以，但得睁着眼睛做"。逐条拆开——问题的清晰度和紧迫性中等，"这只是流程上图个方便，不是什么深痛点"；目标用户定义不够扎实；竞争格局"非常强"，但他明确指出在这儿「强」是坏事，说明赛道竞争太激烈；差异化也不够强。→ 详细
• 合起来的结论是："你要杀进这个市场会非常难，而且守不住，谁都能造出一模一样的东西。"他把这类判断称作用这种 skill 真正的超额价值——它帮你把该做的和不该做的分开。→ 详细
• 他顺带给了一句很扎的观察："感觉有了 Claude Code 之后，GitHub 成了大家唯一能表达自己的地方——什么都造，往 GitHub 上一扔，然后零 star 烂在那儿。"所以这类 gate 的意义是帮你"把时间、注意力和精力都省下来，花在真正对的地方"。→ 详细

• 跑完你拿到的是一个完整的 repo：prototypes 文件夹、一整包思考成果、第一个 milestone 文件夹；架构定了，持续集成定了；把 GitHub repo 给它，它能直接开项目、替你完成第一次 push。→ 详细
• 它还会为这个项目生成一份量身定做的 CLAUDE.md。他专门点了这件事："很多人花大把时间琢磨我这份 CLAUDE.md 该怎么写、front matter 里放什么"，而这个 skill 直接说：针对这个项目，这就是最适合你的一份。生成的这份会主动抓 bug、遵循目录规范、遵循 prototype 规范，而且目录结构（文档放哪、里程碑放哪）也全写进了 CLAUDE.md。→ 详细
• "这基本上已经是一个自组织的 repo 了"——每个文件夹都写明白里面该放什么（既说给 Claude 听，也说给你听）；建好 test 目录；把持续集成和质量体系搭起来（每次提交所有代码跑一遍测试）；配好安全（尤其把 secrets 加进 gitignore，避免 push 到 GitHub 时泄密）；质量上从一开始就留档，还会随时间把犯过的 bug 编成目录、再从这些 bug 里学。更难的活儿（CI 模板、CLAUDE.md 的写法模式）它会外包给别的 skill。→ 详细
• 他把这一切的意义说成"给 PM 和 vibe coder 兜住所有难的地方"：既包括前面的市场调研和该不该做，也包括交接给开发那一环——架构是什么？他见过很多 vibe coder 根本没有持续集成、也不知道怎么测代码。这套东西让你一开始就有"一副非常扎实的产品骨架和一个非常扎实的代码库"。→ 详细

• 前提是他反复强调的那句："这类 workflow 最大的危险，就是你把它的输出当圣旨。你真的得把所有产出都过一遍，确认它对你是成立的。我们自己也天天这么干，因为我觉得百分之百信任 LLM 还是很难的。"→ 详细
• 只看两份文档，剩下的"基本都是模板化的东西"：市场调研和 PRD。他还讲了个人的旧习惯做类比——"我以前带过一些开发，得反复跟他们强调：哪怕你是跟 AI 一起写的，code review 该做还是得做。"→ 详细
• 扫市场调研的具体标准：它有没有提到你预期它该提到的工具（那些就是你的竞品）？每个分类底下你想到的东西它是不是都写了？然后做常识校验——如果提的是过时的工具、跑不起来的工具、只是充数的摆设，你就不该信它；反过来，如果提的都是当下真在用的工具，还包括"你琢磨这个问题时脑子里冒出来过、但其实并没有真正解决你问题"的相邻方案，那说明方向对了。再看差异化地图排得合不合理、你的产品该落在哪个位置。他给这个动作起的名字是"你的第一遍可信度扫描"，打的比方是"想象自己正站在一屋子 PM 面前做 PRD 评审"。→ 详细
• 扫 PRD 的具体标准：先看市场调研的结论和 PRD 对不对得上。它自己写出来的核心论断是："今天代码被生产出来的速度，已经超过任何人能读懂的速度；AI 代码生成把「写代码」和「看懂代码」拆开了……扎得最狠的是两类人：独立创始人发出去的是自己没法审计的代码；刚接手陌生代码库的企业开发者。"他的反应标准是：如果你看完的感觉是"这个我愿意投钱、我愿意花时间，它把我想说的全说中了"，那就对了；否则就该反过来问：它漏了什么？漏了哪类人群？→ 详细
• 他当场给了一个具体的挑刺示范：它写主要用户是"非技术背景的创始人"——合理；小公司——没问题；但它没有再按公司规模限定一层（大公司创始人资源多、工具多，大概率不是目标）。另外它把企业开发者列成了 anti-persona（明确排除的人群），理由是这类需求需要一套持续演进的方案、为保住聚焦判成 out of scope——他读完输出后认可这个判断，因为对企业开发者来说"能干这些事的工具多得是"，价值主张要弱得多。最后的自问是："这是不是我自己会写的那种高层产品简报？缺了什么？如果我要拿去讲给别人听，还缺什么？"→ 详细

• "你大概不该只靠 LLM 来做市场调研。但在你去找真实信源之前，用 LLM 先干掉六七成是完全可以的。"→ 详细
• 他对质量的评价：读过它做的几份市场调研，"基本能做到 Perplexity 那个水准"，会实际扫竞品、扫定价、扫这个领域里别人已经做过什么；执行上它会起一个 web search 会话，装了 Chrome 工具就走 Chrome，没装就自己用 HTTP 抓。→ 详细

• 想法确认值得做之后，他没让 AI 直接出界面，而是先定"能交付价值的基本交互模型"——他强调这一步不能跳："正常情况下你不一定一上来就做原型，但你一定要先定交互。"具体指：这东西到底有没有一套用户体验？还是就是一个跟 agent 对话的聊天界面？它长什么样？你怎么把它启动起来？→ 详细
• 他调用了一个 survey skill，让它拿一组选择题来审自己。四道题原样照录：① 入口是贴 GitHub URL 还是连上 GitHub？（他的回答是"一和二都要"，因为作为 vibe coder 他要分析自己正在写的代码）② 结论怎么呈现在屏幕上——评分 / 单张 verdict 卡片 / 叙事式长滚动 / 对话式聊天？（他选了仪表盘 + 逐层下钻）③ 结论出来之后用户能做什么，也就是参与深度？（他选了二、三、四）④ 最初的 60 秒——用户来这儿要的核心价值到底是什么？（他选"理解代码"）他对好几道题的现成选项都不满意，直接改。→ 详细
• 答完之后它生成三个自包含的 HTML + CSS 原型。他特别指出这个顺序是 skill 强制的："是 skill 本身要求它先做原型、再下判断的。"三版分别是：贴 GitHub 链接后快速讲清代码来龙去脉；同类但数据更多、逻辑放在前面；以及一个侧边栏形态。他提醒这只是"找感觉""还不是真正的设计，重点是从哪儿起步"。→ 详细
• 他自己实际工作时的做法更狠：手上装着五六个设计 skill（提到了 shadcn 这类前端组件库，还有一个他叫 UI/UX Pro Max 的），有六个设计 skill 就让它出六版原型；再让它每次组合两个 skill 来做，又能多出六版。理由是"原型你可以做成百上千个"。→ 详细
• 分层逻辑他自己复述了一遍：先是商业层（这里有没有我们的位置？我们对客户的判断对不对？定价、能不能进入市场、推广计划这些商业问题留到后面），再是产品层（客户调研怎么做才能把问题挖深、这东西到底长什么样、解决问题时用起来什么感觉、怎么制造惊喜）。关键是这一切压缩在同一个 Claude Code session 里——他专门说"我们既不在 Claude 桌面端、也不在 Cowork 里"。→ 详细

• 与原型并行，他让另一个 agent 跑 customer discovery week（客户访谈周）skill，产出一份客户调研计划。计划本身是"完整、可执行"的：访谈脚本、问卷、综合分析模板、一周的时间预算全都写好了。→ 详细
• 但它卡住了，卡点值得原样抄下来："缺的只有一项输入，而缺了这一项，这个 skill 不会放行：一份真能约到人的名单，必须是真实的目标人群，而不是创始人自己人脉里那些沾边的联系人。如果真实目标联系人少于五个，skill 会把这件事本身当成一个信号——说明你可能根本进不去这个市场。" Oji 的解读是："它等于在说：你不能靠拍脑袋糊弄过去，你得有活人可以聊；你告诉我他们是谁，我才知道你准备好了。"→ 详细
• 计划里内置的是他们书里那套三步访谈法：第一步只问开放式问题，"不带动机、不给方向，也完全不拿原型出来"（"跟我说说""带我过一遍你上一次是怎么做的"——目的是走一遍人的真实工作流）；第二步把收上来的东西整理成"我到底需要回答哪些问题"并固化下来；第三步放大成数据——把定死的问题变成问卷，让回答可以量化。它还顺带给出怎么招募、卡点在哪、去哪儿找目标用户、要验证哪些假设。→ 详细

• 主持人问这套只适用于全新产品吗。回答：不。很多 vibe coder 的诉求是"我以前根本做不出东西"，scaffolding 对他们完美（CodeMemo 的第一版 demo 就是这么做的）；但大多数 PM 并不会从零起新项目，所以有一个叫 Vet a Feature 的 skill——"我有一个功能想法，我到底该不该费劲去做它？我还有别的功能想法，做这个的机会成本是什么？"它把一个功能想法拆开来撕一遍，找反模式、看置信度；关键差别是它不光看有没有赛道，还死磕"在你手上这一堆功能里，这个到底值不值得做"，sharp problem test 在这里嵌得特别深。→ 详细
• Aakash 提炼的动作项："对任何 PM 来说，这里最关键的启发就是去做一个像 Vet a Feature 这样的 skill……以前我们要么全靠自己闷头想，要么干脆把这一步跳过去。而现在这等于给了我们一个思考伙伴，保证我们每一次都真的把这一步做了。"→ 详细

• 他管这叫三段速度问题：过去四五十年，最长的那根杆一直是开发——写高质量代码要时间、把质量做扎实要时间、上云之后做到健壮不宕、DevOps 能快速恢复也要时间。现在这些正在被砍掉，"可能 10 倍，五年内可能 20 倍"。→ 详细
• 但造东西不只是写代码，前面还有"我们为什么要造它"、后面还有"把它交到客户手里"。中间这一段突然变快，整个等式就失衡了——因为前后两端都被客户绑住：想清楚为什么要造，得跟人聊、跟市场聊；把东西送到用户手上，同样得跟客户打交道。→ 详细
• 他举了两个"发得快不等于做对了"的例子：一是 Anthropic——按他的估计"30 天里大概发了 60 个功能吧，他们已经开始递归了"，而他自己"根本记不住所有斜杠命令，所以其实吸收不了他们做出来的全部功能"；二是 Claude Cowork 刚被彻底重做——发出来时看着惊艳但采用率很低，于是又被揉回聊天里，而不是保持 code / Cowork / chat 三个 tab，"因为它自己撑不起来"。结论：现在大家不只要发得快，还得确保自己做的是对的东西。他还提到一个还没发的方向——怎么把反馈机制建进 skill 里，让有些 skill 自动帮你把反馈深深嵌进产品。→ 详细
• Aakash 的两句总结正好收在这里："这些 skill 在逼着你把 PM 的基本功做扎实，而它们给你的是这些基本功的第一版草稿""要当一个真正的 builder PM，你得能以工程的速度把这些事做完"。→ 详细

• 把这套东西放进开发所用的同一套技能体系里，"速度提升非常巨大"，因为这个 repo 可以同时就是你开发的 repo。他描述的形态是把过去的割裂直接压平——PM 活在 Notion 里、设计师活在 Figma 里，现在全部收进一个 GitHub repo：写代码的人在 source、test 底下（安全那套、Playwright、Vitest 都在那儿），产品的人在上面这一层；但它是同一个 repo 里的共享上下文，团队里每个需要碰这些东西的人随时都能拿到全部内容。→ 详细
• 被问到"团队落地都犯哪些错"，他的第一个答案是共享上下文。他引用 Claude 那边的 Boris（转写此处公司名被 ASR 糊掉了）的做法：Boris 自己的 CLAUDE.md 非常薄，可能就六行，实际在做的事是引用一份共享的 CLAUDE.md；中心那份被持续维护和优化——"几乎每分钟，所有人学到的东西都会汇进那份中心的 CLAUDE.md；它小、它短，装的是精华，还把人连到组织里所有该用的工具上"。他建议把 CLAUDE.md 理解成"某种基础 skill"。→ 详细
• 所以最大的一课是：**别让大家随随便便各自 fork。**他举的例子是一家有正式"工作方式"文档、还有一套要求产出特定交付物的 SDLC（软件开发生命周期）的企业——他的做法是把 scaffolding、vet a feature 这些 skill 拿过来，改造成产出该组织真正需要的东西。原话："我们的 product brief 凭什么要跟组织想要的不一样？不该不一样。一份市场调研文档，凭什么要跟产品市场团队会产出的、或者他们认为该产出的东西不一样？"→ 详细
• 但他专门补了一层平衡：他喜欢"开源式"的组织，因为 CPO 不可能什么都懂，所以要给人创新的许可；只是创新必须回流到一个中心位置，让所有人都享受到。最大的坑是"AI 的推广完全没有治理，也没有共享上下文"。他的收尾比喻很漂亮：科幻里我们总怕 hive mind（蜂巢思维，指众多个体共享一个心智）——怕 AI 互相协作就要灭了我们——"但事实是，我们人类才是最原始的那个 hive mind，我们能活过这么多个世纪，唯一的原因就是我们会互相学习。所以推 AI 的时候要想办法把它塞进一个结构里，做到一个人学会了就等于所有人都学会了。"→ 详细

▲ 图注：配套的公开仓库 ProductMind Skills——他把这一整套产品判断力 skill 开源了出来（截帧是仓库首页的文件列表与说明，具体地址请以视频简介为准）。这是本期最直接的「可抄物」。

• 这些 skill 是开源的，可以逐个翻看；除了进 Claude Code，也能直接对话调用。他点名的有：new project scaffolding、vet a feature、sharp problem test，以及他"特别兴奋"的 vibe memo——一个很简单的系统，逻辑是"现在你写的代码是被记录下来的，但 vibe memo 说：把「为什么」也记下来"，它在构建过程中把每个决策连同原因一起留进日志，等代码库变大之后能回头查"当初到底为什么那么定、当时怎么想的"。→ 详细
• 他另外挑出来的几个：roadmap from strategy（替你把一整套战略搭出来）、listening machine（把产品里所有界面都变成反馈工具，持续收集信息）、scope cutter（给你一套干脆的办法把要做的量降下来）、一个判断第一版该做 MVP（纯粹为了学到东西）还是 SLC（真拿到人面前、要让人眼前一亮）的 skill，以及定价该怎么设计这类进阶内容。他的评价："这些都是别人琢磨好多年才摸出来的东西，我们把它做进一个 skill，让你立刻就能上手。"→ 详细
• 他对趋势的判断很硬："光有 code skill 正在变得没什么稀奇"——他前几天看到有人因为模型已经足够好，把一整套 skill 从 repo 里删了，"有些 skill 就这么被废掉了"。但业务 skill、产品 skill"仍然是让我们有能力做对的东西的那部分"，他认为这是新的前沿。→ 详细

• 演示时 Claude Code 跑在 Antigravity 里（VS Code 的一个 fork，看起来像 Cursor / VS Code）。被问到是不是非它不可，他答得很干脆："什么 harness 都行……我其实是在终端里跑的，Antigravity 的功能我一个都没用。界面挺好看，但没什么特别的。"→ 详细

闪电问答：（本期无）

收尾

• Aakash 的落点是把这期定性成一套可复制的打法："你可以把它变成你自己的——这才是关键：把你们自己的东西加进去，让它长成你们的样子，然后作为一个开源 repo 部署给团队用。这就是那套打法。如果你一直在琢磨「我怎么才能让团队更 AI native？怎么让我的 PM 团队跑出工程师那样的速度？」——我们刚刚把这些全都免费送出来了。"→ 详细

• Oji 的最后一句："我也希望大家能靠我们做的这些东西，成为更高效的产品打造者、成为超级创造者。"→ 详细

• 嘉宾：Oji Udezue，Product Mind（他自己的产品咨询公司）。本期没有给出个人社交账号或邮箱。

• Product Mind Skills Library（开源 skill 库）：Aakash 在收尾时说 GitHub 仓库链接放在原视频简介里。→ 详细

• Oji 还口头提到 Product Mind 的一个 labs 页面（放他们在客户项目里能对外分享的产品，他明说"这不是个能变现的站"）——该域名在自动转写里被识别得含混，这里不臆测，以原视频简介为准。→ 详细

• 他们的书：《Building Rocket Ships》（skill 里的多个产品框架出自这本书）。→ 详细