The Complete Guide to AI PM OS

George (prodmgmt.world) 2026-10-03 13.9 KB 5.9K 46 𝕏 文章列表

文章介绍了 AI PM OS——一套面向产品经理的 Agent Skill 体系。作者强调：与其信任模型凭提示词自由发挥，不如为 Agent 配备结构化技能，确保输出质量稳定。核心方法论是'监督比你更聪明的人'：通过间接提示让 Agent 自己复述问题、避免被先入为主的假设带偏，并用 /first-principles、/mckinsey-issue-tree、/causal-tree、/jtbd-forces 等技能栈按'定义问题、选择赌注、理解用户、定义成功、塑造构建、写作、推动组织'分阶段组织工作。同时利用记忆和历史会话，让 Agent 继承过往决策背景，提升产品判断力。

# The Complete Guide to AI PM OS **作者**: George from prodmgmt.world **日期**: 2026-10-03T12:02:12.000Z **来源**: [https://x.com/nurijanian/status/2106354126838022497](https://x.com/nurijanian/status/2106354126838022497) --- ![Image](/doc/7726/image/img_5fd754e7d4f8.jpg) In the last year I showed you skills like `[/mckinsey-issue-tree](https://x.com/nurijanian/status/2081707189853642988)`, `[/problem-first](https://x.com/nurijanian/status/2063186118409929161)`, and `[/causal-tree](https://x.com/nurijanian/status/2082065077021335632)` - the small, sharp tools that make agents useful for product work. The key lesson inside AI PM OS is simple: giving agents skills is important, regardless of the harness, model or your own skillset. A model may do well without a skill, but are you trusting it to do it correctly every time, based on your prompt - or even without one? It's like saying, "I have great staff, they'll figure it out," and doing away with useful processes that save time and effort and errors for everyone, regardless of their skill. Any harness should be able to push the skill further, make it do more, reach the right information and result, too, but there are nuances to how each does it. But once verification exists, the next question for PMs is different from shipping code. Not “how do I produce more docs?” How do I reach stronger product judgments with a collaborator who can generate drafts quicker than I can reason, without turning into the phony PM who drops Claude straight into the PRD? This is the exact workflow I use inside AI PM OS: the art of supervising someone smarter than you on a product surface you don't fully hold in your head anymore. ![Image](/doc/7726/image/img_62c666e7835b.jpg) ## The skill of directing someone more brilliant than you Back in the old days of 2023, to change a product you first needed a mental model: users, metrics, constraints, org politics, eng reality. That took interviews, dashboards, and years of scars. Agents remove the typing barrier. You can generate a PRD, a research plan, a roadmap rewrite in minutes - regardless of how thin your context is. Keeping judgment and user value high is still hard. Especially if you're not already deep in the domain. I constantly see two failure modes: 1. The agent doesn't understand your intent because the problem was under/poorly specified. 2. The agent doesn't have enough context on how this product, team, and user actually work. Both are the same root cause: bad priming of the context window. ![Image](/doc/7726/image/img_f0f7704195ce.jpg) You can ship “working” docs without fixing that. Outcomes are much better when you give the agent everything it needs to do a high-quality job - then supervise the judgment closely. ## In simple terms Frontier models are very capable writers and synthesizers. Micromanaging every sentence is the wrong game. The balance I want: - tell it what outcome matters - leave room for solutions I wouldn't have thought of - catch misunderstandings before it floods the team with polished wrongness One technique baked into PM OS: the indirect prompt. Draw the problem out of the agent - in its own words - instead of dumping your assumptions first. When a messy Slack thread, customer call, or stakeholder dump lands: ``` /de-clever read this thread. restate in your own words and in plain english what you think the underlying product problem is — not the feature request ``` Or go upstream before any rewrite: ``` /brief-to-problem turn this stakeholder dump into a problem statement. then /structure-problem it so we know what decision we're actually making. ``` That does three things: 1. Forces compression of noisy conversation into a structured problem. 2. Lets me catch red herrings before any PRD gets written. 3. Avoids leading the agent with my own (possibly wrong) hypothesis. ![Image](/doc/7726/image/img_1b44fabacdd0.jpg) ## Establishing a mental framework Asking the agent to restate itself in a way you can understand is how you supervise someone smarter than you. That's why PM OS leans on skills that force structured judgement, given good context: - `/first-principles` - strip a decision to the core underlying bare bones, as close to the metal as possible - `/structure-problem` + `/mckinsey-issue-tree` - structure the problem space, visualise and explore it with an agent - `/find-the-strategic-crux` - squeeze the problem until you solve the right refined problem, not the first, second or third that comes to mind - `/metric-drop` + `/success-metric` - real signal vs noise, and what “winning” even means - `/eng-shape` + `/engineer-for-progress` - shape work & prototypes to get to the results faster - `/where-did-we-land` - reconstruct a meeting into where every thread landed so this too can be visualised, analysed and solved - `/critical-decision-method` + `/jtbd-forces` - drive excellent research execution to the heart of the customer's expertise and JTBD - `/causal-tree` - explore and prevent 2nd/3rd order effects for every decision or plan - `/decision-journal` - calibrate your judgment over time Under the hood, good PM supervision in PM OS keeps asking two questions: - How does this product/system actually behave today? (usage, funnels, support, eng constraints) - Why did we end up here? (old bets, politics, incidents, “temporary” that became permanent) I use a teach-back loop constantly: ``` /first-principles + teach me why this roadmap bet is the right one. what must be true? what evidence do we have? what would falsify it? ``` The research isn't only for humans. Agents that have to teach you also stop confidently hallucinating product reality. ![Image](/doc/7726/image/img_f85b57fa7efb.jpg) ## The full skill stack (use it) Don't treat skills as a random tip feed. Group them by the job you're supervising: Frame the problem - `/brief-to-problem`, `/structure-problem`, `/mckinsey-issue-tree`, `/mece-tree`, `/good-question-brainstormer`, `/via-negativa` Choose the bet - `/first-principles`, `/find-the-strategic-crux`, `/causal-tree`, `/decision-journal`, `/working-backwards`, `/opportunity` Understand the user - `/jtbd-forces`, `/jtbd-market-canvas`, `/critical-decision-method`, `/requirements-from-talk`, Bounded ICP, Sensemaking, Demand-Side Sales + Learning to Build Define success + learning - `/success-metric`, `/metric-drop`, `/experiment-design`, `/tracking-schema` Shape the build - `/eng-shape`, `/engineer-for-progress`, `/gherkin-stories`, `/edge-cases`, `/requirements-reconcile` Write without slop - `/de-clever`, Minto Pyramid pass, `/requirements-reconcile` Move the org - influence skill, `/review` (product-org-of-one reviews) ![Image](/doc/7726/image/img_dbf742ad8ac4.jpg) ## Learning from history Most PM work spans many chats: discovery, then a week later a prioritization fight, then a postmortem. Fresh agents forget the scars. Your past transcripts, Notion specs, Linear tickets, call notes, and old PRDs are a gold mine. PM OS is built so standards and prior decisions can ride along - so you're not re-explaining the company every morning. ``` recall the work we did on [initiative] last week, then read this new customer complaint. restate the conflict in plain english before proposing anything. ``` Some days I don't even have to do that - because PM OS has specific memory functions and project orientation, it can figure out what this is about. When the raw material is a call: ``` /requirements-from-talk on this transcript. then /jtbd-forces — what job is the user hiring us for? ``` ![Image](/doc/7726/image/img_4a68f58eae34.jpg) ## Working backwards The usual “planning approaches” for PMs are bloated with feature requirements yet thin on what’s essential: user difficulty, success signal, cancellation bar, engineering design. I don't put stock in planning-as-performance. I design by generating artifacts that can be inspected: - a problem statement the agent restated (`/brief-to-problem` then `/structure-problem`) - a first-principles brief - a metric that is precisely calibrated, and the process it describes over time (`/success-metric` + `/metric-drop`) - an understanding of the technical solution options (`/eng-shape`) - edge cases that seem obvious in hindsight (`/edge-cases`) When documentation goes ragged, `/de-clever` is the razor. `/requirements-reconcile` delivers that matching momentum for PRDs that are at odds with themselves. Distinct drafting modes so a PRD isn’t functioning as a pep memo, a strategic overview, and an API compendium all at once. A compound prompt that actually works: ``` (1) recall recent work on [area]. use /metric-drop on the dashboard claim. (2) /first-principles the decision we think we're making. (3) /causal-tree the 2nd/3rd order effects if we're wrong. (4) /eng-shape a version we could ship in 2 weeks. (5) /edge-cases what we will miss. (6) teach me why this is better than doing nothing — with falsifiers. ``` ![Image](/doc/7726/image/img_b39c44db7ff7.jpg) ## Measure a hundred times, cut once Two common PM-agent mistakes: 1. Accepting the agent's first framing of the problem. 2. Overcooking a strategy doc with no empirical contact with users or the product. When humans planned, we iterated design docs. With agents, people accept the first beautiful wrong PRD. Prototype product thinking the way `/engineer-for-progress` teaches shipping for learning: - spawn 2–3 competing problem framings (`/mckinsey-issue-tree` helps) - prototype ways to invalidate assumptions (`/experiment-design`, `/working-backwards`) - test drive your judgement - only then write the ship plan (`/gherkin-stories` if eng needs scenarios) ``` prototype three framings of this opportunity. for each: user struggle, must-be-true, metric, eng-shaped MVP, why it might be wrong. I'll choose before any PRD. ``` Prototyping is planning - with contact with reality. ![Image](/doc/7726/image/img_314884e19d43.jpg) ## Architecting bigger product changes In the agentic era, PMs should spend more time on: - which problem is worth solving - which bets compose - what the system of metrics and incentives will do Agents fill in drafts. You own value and viability. A PM architect loop inside PM OS: 1. Ground - how/why of current product + org constraints 2. Sketch - competing bets as thin packages (user, metric, MVP shape) 3. Cross-judge - attack each with falsifiers (`/causal-tree`, `/find-the-strategic-crux`) 4. Implement the thin slice - real learning, not a 40-page plan 5. Scrap when wrong - Kill Your Darlings for real: don't beat a dead horse ## Okay but I really want a planning doc Fine. After the framing is solid: ``` turn this decision into an execution plan. each step needs proof: what we'll learn, how we'll verify, what would make us stop. use /tracking-schema so we don't ship blind. ``` Every step structured around proof. Not “write more docs.” Tests for product thinking: did a user contradict us, did a metric move, did eng say the shape is fake? For long initiatives, keep the live plan where agents can see it. Delete or archive when done so the OS doesn't become a graveyard of abandoned certainty. That's the point of Kill Your Darlings and v2.8 company standards: the OS enforces taste, not just generation. ## The workflow in practice Example 1: Ambiguous metric freakout ``` /metric-drop on this “we're down 12%” claim. /success-metric — what should we have been optimizing? give me what we know, what data you used, and your best hypotheses. do not propose a roadmap yet. ``` Example 2: New bet that will spawn a dozen tickets ``` /structure-problem + /mckinsey-issue-tree first. architect this opportunity. answer open questions with competing framings. /eng-shape + /edge-cases before any Jira. ``` Example 3: Multi-week initiative ``` create a plan to migrate [area] to [new approach]. break into small, verifiable slices (/working-backwards + /experiment-design). each slice must have a learning goal and a kill criterion. /decision-journal this choice so we can calibrate later. ``` Example 4: Messy Slack / meeting residue ``` /where-did-we-land on this transcript. then /first-principles: what decision is actually open? ``` Example 5: Stakeholder politics ``` Map the game (Games People Play / influence skill). Then /find-the-strategic-crux — what actually unlocks the decision? ``` Most of the time you can stay in one mode: problem, then restate, then evidence, then thin slice, then verify - and let PM OS skills do the compounding. ## The art of planning (for product) ![Image](/doc/7726/image/img_1c9e0644fa85.jpg) ![Image](/doc/7726/image/img_105a1c36b04a.jpg) AI PM OS is how I combine investigation, empirical evidence, and judgment. When you work this way, product work with agents stops feeling like a slot machine. It becomes repeatable. I don't know if this is the final shape of how we do work, but I can tell you right now, I am never going back to the old ways. # [Get AI PM OS today 🕹️](https://prodmgmt.world/x/supervising-smarter_041026) ## 相关链接 - [George from prodmgmt.world](https://x.com/nurijanian) - [@nurijanian](https://x.com/nurijanian) - [1.8K](https://x.com/nurijanian/status/2106354126838022497/analytics) - [/mckinsey-issue-tree](https://x.com/nurijanian/status/2081707189853642988) - [/problem-first](https://x.com/nurijanian/status/2063186118409929161) - [/causal-tree](https://x.com/nurijanian/status/2082065077021335632) - [Get AI PM OS today 🕹️](https://prodmgmt.world/x/supervising-smarter_041026) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [8:02 PM · Oct 3, 2026](https://x.com/nurijanian/status/2106354126838022497) - [1,805 Views](https://x.com/nurijanian/status/2106354126838022497/analytics) --- *导出时间: 2026/10/3 23:43:42* --- ## 中文翻译 # AI PM OS 完全指南 **作者**： George from prodmgmt.world **日期**： 2026-10-03T12:02:12.000Z **来源**： [https://x.com/nurijanian/status/2106354126838022497](https://x.com/nurijanian/status/2106354126838022497) --- ![Image](/doc/7726/image/img_5fd754e7d4f8.jpg) 过去一年里，我向你展示过诸如 `[/mckinsey-issue-tree](https://x.com/nurijanian/status/2081707189853642988)`、`[/problem-first](https://x.com/nurijanian/status/2063186118409929161)` 和 `[/causal-tree](https://x.com/nurijanian/status/2082065077021335632)` 这样的技能——这些小而锋利的工具，能让智能体在产品工作中真正派上用场。 AI PM OS 的核心经验很简单：给智能体赋予技能非常重要，无论使用什么框架、模型，也无论你自身水平如何。模型也许在没有技能的情况下也能表现不错，但你会信任它每次都能根据你的提示词——甚至在没有提示词的情况下——正确完成任务吗？这就像说：“我的员工都很优秀，他们会自己想办法的”，然后废弃那些能为所有人节省时间、精力和减少错误的实用流程，而不考虑他们的能力高低。任何框架都应该能进一步拓展技能，让它做得更多，触达正确的信息和结果，但每个框架在具体实现方式上各有细微差别。而一旦验证机制存在，产品经理面临的下一个问题就不同于交付代码了。不是“我如何产出更多文档？” 而是：当协作者生成草稿的速度比我推理还快时，我该如何借助它做出更强大的产品判断，同时又不变成那种直接把 Claude 扔进 PRD 的虚假产品经理？这正是我在 AI PM OS 中使用的工作流：一门在产品面上监督比你更聪明者的艺术——而这个产品面已不再完全装在你的脑子里。 ![Image](/doc/7726/image/img_62c666e7835b.jpg) ## 指导比你更聪明者的艺术回到遥远的 2023 年，要改变一个产品，你首先需要心智模型：用户、指标、约束、组织政治、工程现实。这需要访谈、数据看板，以及多年积累的伤疤。智能体消除了打字这道门槛。几分钟内你就能生成 PRD、研究计划或重写路线图——不管你的背景信息有多贫乏。让判断力和用户价值保持高水平依然很难。尤其当你尚未深入某个领域时。我经常看到两种失败模式： 1. 智能体不理解你的意图，因为问题被描述得含糊或糟糕。 2. 智能体缺乏足够的背景信息，不了解这个产品、团队和用户的实际运作方式。两者的根本原因相同：上下文窗口的预填充（priming）做得不好。 ![Image](/doc/7726/image/img_f0f7704195ce.jpg) 不解决这个问题，你也能交付“看起来能用”的文档。但当你给智能体提供它所需的一切、让它能高质量完成工作——然后密切监督其判断时，成果会好得多。 ## 简单来说前沿模型是非常出色的写作者和综合者。对每一句话进行微观管理是错误的游戏。我想要的平衡是： - 告诉它什么结果才是重要的 - 留出空间，让它提出我没想到的解决方案 - 在它用精致却错误的输出淹没团队之前，抓住误解 PM OS 中内置的一项技术：间接提示（indirect prompt）。先让智能体用自己的话把问题讲出来，而不是一开始就倾倒你的假设。当一条混乱的 Slack 讨论串、客户通话或利益相关者的信息轰炸落到你面前时： ``` /de-clever read this thread. restate in your own words and in plain english what you think the underlying product problem is — not the feature request ``` 或者在重写任何内容之前先向上游追溯： ``` /brief-to-problem turn this stakeholder dump into a problem statement. then /structure-problem it so we know what decision we're actually making. ``` 这带来三个好处： 1. 迫使模型把嘈杂的对话压缩成结构化的问题。 2. 让我在写下任何 PRD 之前就发现干扰性的错误线索。 3. 避免用我自己（可能是错误的）假设误导智能体。 ![Image](/doc/7726/image/img_1b44fabacdd0.jpg) ## 建立心智框架要求智能体用你能理解的方式复述自己，就是你监督比你更聪明者的方法。正因如此，PM OS 依赖那些在良好上下文基础上强制进行结构化判断的技能： - `/first-principles` - 把一个决策剥离到最底层的基本要素，尽可能贴近本质 - `/structure-problem` + `/mckinsey-issue-tree` - 结构化问题空间，与智能体一起可视化并探索它 - `/find-the-strategic-crux` - 挤压问题，直到你解决的是真正精炼的正确问题，而不是脑海中冒出的第一、第二或第三个 - `/metric-drop` + `/success-metric` - 真实信号与噪音的区分，以及“赢”到底意味着什么 - `/eng-shape` + `/engineer-for-progress` - 塑造工作与原型，更快抵达结果 - `/where-did-we-land` - 把会议重构为每条线索的最终结论，使其同样可以被可视化、分析和解决 - `/critical-decision-method` + `/jtbd-forces` - 推动卓越的研究执行，直达客户的专业领域和 JTBD 核心 - `/causal-tree` - 探索并预防每个决策或计划的二阶/三阶效应 - `/decision-journal` - 随时间校准你的判断力在底层，PM OS 中良好的 PM 监督会不断追问两个问题： - 这个产品/系统今天究竟是如何运作的？（使用情况、漏斗、客服、工程约束） - 我们为什么走到了这一步？（过去的押注、政治、事故、“临时”变成永久的东西）我经常使用一种“回授”（teach-back）循环： ``` /first-principles + teach me why this roadmap bet is the right one. what must be true? what evidence do we have? what would falsify it? ``` 研究不只是为了人类。被要求教会你的智能体，也会停止对产品现实自信满满地产生幻觉。 ![Image](/doc/7726/image/img_f85b57fa7efb.jpg) ## 完整技能栈（用起来）不要把技能当作随机的技巧合集。按你所监督的工作来分组：界定问题 - `/brief-to-problem`、`/structure-problem`、`/mckinsey-issue-tree`、`/mece-tree`、`/good-question-brainstormer`、`/via-negativa` 选择押注 - `/first-principles`、`/find-the-strategic-crux`、`/causal-tree`、`/decision-journal`、`/working-backwards`、`/opportunity` 理解用户 - `/jtbd-forces`、`/jtbd-market-canvas`、`/critical-decision-method`、`/requirements-from-talk`、有界 ICP、Sensemaking、需求侧销售 + Learning to Build 定义成功与学习 - `/success-metric`、`/metric-drop`、`/experiment-design`、`/tracking-schema` 塑造构建 - `/eng-shape`、`/engineer-for-progress`、`/gherkin-stories`、`/edge-cases`、`/requirements-reconcile` 写出不含废话的文档 - `/de-clever`、Minto 金字塔校对、`/requirements-reconcile` 推动组织 - 影响力技能、`/review`（一人产品组织的评审） ![Image](/doc/7726/image/img_dbf742ad8ac4.jpg) ## 从历史中学习大多数 PM 工作跨越多个会话：先是探索发现，一周后是优先级之争，再然后是复盘。全新的智能体会忘记那些伤疤。你过往的对话记录、Notion 规格、Linear 工单、通话笔记和旧 PRD 是一座金矿。PM OS 的构建方式使得标准和过往决策能够随行携带——这样你就不必每天早上重新解释一遍公司。 ``` recall the work we did on [initiative] last week, then read this new customer complaint. restate the conflict in plain english before proposing anything. ``` 有些日子我甚至不用这么做——因为 PM OS 具备专门的记忆功能和项目定位能力，它能自己弄清楚这是关于什么的。当原始素材是一次通话时： ``` /requirements-from-talk on this transcript. then /jtbd-forces — what job is the user hiring us for? ``` ![Image](/doc/7726/image/img_4a68f58eae34.jpg) ## 逆向工作 PM 常见的“规划方法”充斥着功能需求，却在真正关键的东西上很薄弱：用户痛点、成功信号、取消门槛、工程设计。我不迷信把规划当作表演。我的设计方式是生成可供检验的产物： - 一份由智能体复述过的问题陈述（`/brief-to-problem` 然后 `/structure-problem`） - 一份第一性原理简报 - 一个精确校准的指标，以及它随时间描述的进程（`/success-metric` + `/metric-drop`） - 对技术方案选项的理解（`/eng-shape`） - 那些事后看来显而易见的边界情况（`/edge-cases`）当文档变得杂乱时，`/de-clever` 就是那把剃刀。`/requirements-reconcile` 能为自相矛盾的 PRD 提供相应的修正动力。不同的起草模式让 PRD 不至于同时充当打气备忘录、战略概览和 API 手册。一个真正有效的复合提示词： ``` (1) recall recent work on [area]. use /metric-drop on the dashboard claim. (2) /first-principles the decision we think we're making. (3) /causal-tree the 2nd/3rd order effects if we're wrong. (4) /eng-shape a version we could ship in 2 weeks. (5) /edge-cases what we will miss. (6) teach me why this is better than doing nothing — with falsifiers. ``` ![Image](/doc/7726/image/img_b39c44db7ff7.jpg) ## 百般测量，一次裁切两个常见的 PM-智能体错误： 1. 接受智能体对问题的第一次框定。 2. 把战略文档过度打磨，却从未与用户或产品有过实证接触。人类做规划时，我们会迭代设计文档。而面对智能体时，人们却接受了第一份漂亮却错误的 PRD。像 `/engineer-for-progress` 教授的“为学习而交付”那样，对产品思考进行原型化： - 生成 2–3 个相互竞争的问题框定（`/mckinsey-issue-tree` 有帮助） - 原型化各种证伪假设的方法（`/experiment-design`、`/working-backwards`） - 试驾你的判断力 - 然后才写交付计划（如果工程需要场景，用 `/gherkin-stories`） ``` prototype three framings of this opportunity. for each: user struggle, must-be-true, metric, eng-shaped MVP, why it might be wrong. I'll choose before any PRD. ``` 原型化就是规划——与现实保持接触的规划。 ![Image](/doc/7726/image/img_314884e19d43.jpg) ## 架构更大规模的产品变革在智能体时代，PM 应该花更多时间在： - 哪个问题值得解决 - 哪些押注可以相互组合 - 指标和激励体系将产生什么影响智能体负责填充草稿。你负责价值和可行性。 PM OS 内部的 PM 架构循环： 1. 落地 - 当前产品的现状/缘由 + 组织约束 2. 草绘 - 把相互竞争的押注做成轻量包（用户、指标、MVP 形态） 3. 交叉评判 - 用证伪标准攻击每一个（`/causal-tree`、`/find-the-strategic-crux`） 4. 实现最薄的切片 - 获得真实的学习，而不是一份 40 页的计划 5. 错了就放弃 - 真正做到“Kill Your Darlings”：不要鞭打死马 ## 好吧，但我就是想要一份规划文档行。在问题框定足够扎实之后： ``` turn this decision into an execution plan. each step needs proof: what we'll learn, how we'll verify, what would make us stop. use /tracking-schema so we don't ship blind. ``` 每一步都围绕证据构建。不是“写更多文档”。产品思考的检验标准：是否有用户反驳了我们？指标是否动了？工程是否说这个形态是假的？对于长周期项目，把实时计划放在智能体能看到的地方。完成后删除或归档，免得这个 OS 变成被遗弃的确定性的坟场。这正是“Kill Your Darlings”和 v2.8 公司标准的意义所在：OS 强制执行的是品味，而不仅仅是生成。 ## 实践中的工作流示例 1：指标异常引发的恐慌 ``` /metric-drop on this “we're down 12%” claim. /success-metric — what should we have been optimizing? give me what we know, what data you used, and your best hypotheses. do not propose a roadmap yet. ``` 示例 2：将催生十几个工单的新押注 ``` /structure-problem + /mckinsey-issue-tree first. architect this opportunity. answer open questions with competing framings. /eng-shape + /edge-cases before any Jira. ``` 示例 3：持续数周的项目 ``` create a plan to migrate [area] to [new approach]. break into small, verifiable slices (/working-backwards + /experiment-design). each slice must have a learning goal and a kill criterion. /decision-journal this choice so we can calibrate later. ``` 示例 4：混乱的 Slack / 会议残留 ``` /where-did-we-land on this transcript. then /first-principles: what decision is actually open? ``` 示例 5：利益相关者的政治博弈 ``` Map the game (Games People Play / influence skill). Then /find-the-strategic-crux — what actually unlocks the decision? ``` 大多数时候，你可以保持在一种模式中：问题，然后复述，然后证据，然后最薄切片，然后验证——让 PM OS 的技能为你带来复利。 ## （面向产品的）规划艺术 ![Image](/doc/7726/image/img_1c9e0644fa85.jpg) ![Image](/doc/7726/image/img_105a1c36b04a.jpg) AI PM OS 是我结合调查、实证证据和判断力的方式。当你以这种方式工作时，与智能体协作的产品工作就不再像一台老虎机。它变得可复现。我不知道这是否是我们工作方式的最终形态，但我现在就可以告诉你：我绝不会回到老路上去。 # [立即获取 AI PM OS 🕹️](https://prodmgmt.world/x/supervising-smarter_041026) ## 相关链接 - [George from prodmgmt.world](https://x.com/nurijanian) - [@nurijanian](https://x.com/nurijanian) - [1.8K](https://x.com/nurijanian/status/2106354126838022497/analytics) - [/mckinsey-issue-tree](https://x.com/nurijanian/status/2081707189853642988) - [/problem-first](https://x.com/nurijanian/status/2063186118409929161) - [/causal-tree](https://x.com/nurijanian/status/2082065077021335632) - [立即获取 AI PM OS 🕹️](https://prodmgmt.world/x/supervising-smarter_041026) - [升级到 Premium](https://x.com/i/premium_sign_up) - [2026年10月3日下午8:02](https://x.com/nurijanian/status/2106354126838022497) - [1,805 次浏览](https://x.com/nurijanian/status/2106354126838022497/analytics) --- *导出时间： 2026/10/3 23:43:42*