A Guide to Agent-native Product Management

原文：A Guide to Agent-native Product Management

产品管理的学科演变

"产品管理"诞生于 1930 年代的消费品巨头宝洁公司。当公司扩大产品线时，领导者意识到，如果将控制权下放给产品的直接管理者，产品会更成功。每个产品都需要有人负责，他们称这个人为"品牌经理"（Brand Man）。产品管理的存在理由——所有权和问责制——一直延续至今。

然而在随后的岁月里，产品管理的职位描述被改写了数次。1940 和 1950 年代，惠普的产品经理成为客户与工程师之间的中间人。到世纪末，互联网创业公司的 PM 将用户体验设计、敏捷开发和 A/B 测试加入了工具箱。

如今，PM 需要擅长一切：设计和外交、销售和统计。数千家创业公司筹集了数十亿美元来帮助 PM 跨越这些学科。但这引入了一个新问题：今天的公司平均拥有超过 100 个软件订阅，考虑到 PM 需要与多少其他角色和学科互动，这种过载对他们的影响比其他职能更大。难怪我认识的许多产品管理人员感到精疲力竭。

现在，产品管理中大部分跨学科工作可以由 LLM 在几分钟、有时几秒钟内完成。过去需要三小时的分析调查，现在只是与 Claude 的简单对话。过去每两周一次的产品审查苦差事，现在从一条充满拼写错误的聊天消息中就能产生。

至少这是我最近的经历。我不再纠结于 SQL 查询中的分号，甚至不再编写工单。我所有的产品管理工作都在与 Claude Code 的对话中完成。对话即工作。

本质上，当工具的能力追上了工作的复杂度，工作本身就从执行变成了对话——这是劳动形态的根本转变。

以下指南是我如何使用代理进行产品管理的时间点快照。新的 AI 工具每天都在推出，我的工作流至少每周都在变化。我试图在这里捕捉工作流中可能几个月不会改变的主要支柱。如今很难看得更远。

核心 PM 循环

这是一个熟悉的软件开发生命周期（SDLC）循环。产品管理主要发生在"计划"和"审查"阶段。关于"发布"阶段的更多信息，请查看我的同事 Kieran Klaassen 的复合工程指南。

发布的一切都是实验。你永远无法确定用户会如何反应新事物。你发布得越多，学到的就越多——这些学习随着时间推移会自我强化，让你能更好地服务客户。一旦积累了足够的学习，就该重新审视策略了。根据我们现在所知，这仍然是制胜方法吗？答案可能是肯定的，但如果是否定的，就改变它并继续发布。

这意味着，产品开发不是线性的执行过程，而是螺旋上升的认知循环——每次迭代都在用数据重写假设。

但一切都始于……

策略文档

正如 Kieran 所说，软件开发已经从 20% 规划和 80% 执行转变为 80% 规划和 20% 执行。所有软件规划的基础是策略。

新的复合工程命令 /ce-strategy 的结构来自管理学教授 Richard Rumelt 的著作《好战略，坏战略》。正如标题所示，他调查了大量来自公司和政府的真实案例，并将它们分类为好策略或坏策略。

当你第一次在代理环境（Claude Code、Codex 等）中运行 /ce-strategy 时，系统会问你一系列问题，最终生成一个 strategy.md 文件。strategy.md 的组成部分包括：愿景、核心挑战、指导原则和工作轨道。

还有两个可选部分。"不做的事"是一个明确的清单，列出可能诱人但不是近期优先事项的事情。提前声明这一点有时有助于避免分心。"营销/定位"是产品团队将为支持增长而开展的工作清单。

策略文档不包含产品需求。没有详细描述的具体功能、问题或状态。它是产品的大局观。规格说明稍后再来。

填写策略

从零开始写策略文档很难。我发现最好的方法是让代理采访你。ce-strategy 技能就是这样做的。它按顺序浏览各个部分，并内置了关于什么是好答案（以及应该反驳什么样的答案）的指导。输出是 docs/strategy.md。你可以随时重新运行命令来重新审视特定部分，而无需重写整个文档。

采访是刻意对话式的。如果对"这个产品解决的核心问题是什么"的第一个答案很模糊，代理会深入追问："具体是谁的情况？他们今天尝试什么，为什么不起作用？"这里的指导来自个人经验和 Rumelt 的书。

换句话说，AI 不是在等待完美的输入，而是在主动引导你完成思考过程——这是从"工具"到"思维伙伴"的跃迁。

复合策略

假设你正在使用复合工程并以后 AI 速度发布，你应该每隔几个月重新运行策略访谈。下次进行访谈时，你的代理将拥有数周或数月的上下文，来自规划功能、发布它们和审查数据。代理的问题会更尖锐，对话会更艰难。

发布

我过去花很多时间写工单。我为详细的验收标准（给定、当、那么）感到自豪，这些标准不给工程不确定性留下任何空间。

现在我不再写工单了。一旦你有了包含工作轨道的策略文档，我建议使用复合工程的构思（ideate）、头脑风暴（brainstorm）和计划（plan）技能来想出要构建什么。

你需要一个问题跟踪器，它应该有 MCP（模型上下文协议）或其他代理集成。我使用 GitHub Issues，但过去在 Linear 上也有很好的体验。你的代理应该为你编写工单，在看板上移动它们，并保持状态最新。你不再阅读或编写工单；你只是与代理讨论它们。

【补充：MCP 是一种让 AI 代理能够直接访问和操作外部工具的协议标准】

对于状态，我使用现在/下一步/以后的列表，大致对应本周、下周和……未来某个时候。我不做冲刺，只做 看板（Kanban）。有"进行中"，有"完成"。这就是你需要的全部。

产品脉搏

产品脉搏是策略与现实相遇的地方。脉搏命令是我了解产品实际使用情况、功能是否成功以及系统健康状况的主要窗口。脉搏按需生成，脉搏的集合就是产品的记忆。

创建产品脉搏

这假设你的产品已经被检测并且日志存储在某处。如果不是这样，我建议你停止阅读并去设置它。（Posthog 有一个自助设置向导。）

像策略命令一样，/ce:product-pulse 命令在你第一次运行时会采访你。

脉搏的组成

一个好的脉搏报告适合单页（大约 30 到 40 行终端输出），涵盖四件事：指标、错误、性能和用户反馈。

让它运行

数据源

脉搏从产品堆栈中最多四类工具中提取数据：遥测、错误跟踪、性能监控和反馈平台。

只有其中一个的团队仍然可以运行有用的脉搏。当所需的数据源不可用时，报告会跳过相关部分。在数据源数量上，质量胜过数量。

连接 MCP

让代理在每次运行时查询这些工具的最快方法是通过 MCP 连接它们。如果你运行 Claude Code，/mcp 列出已连接的内容。你的代理的 MCP 注册表是查找连接器的简单方法，或者你可以使用 Google 搜索它们。

如果工具没有可用的 MCP，脉搏仍然可以工作。代理只需要一个有凭证的路径（如 CLI 或 API），但代理似乎更喜欢 MCP。

反馈渠道

脉搏涵盖反馈的定量部分——指标、错误、性能。定性方面必须直接来自用户。我喜欢与用户通过电子邮件交流，所以我在产品中显眼地放置了 Spiral 电子邮件地址，发送到该地址的邮件会进入我的工作收件箱。我还在发送给用户的每封营销邮件中包含 15 分钟通话预约链接。与用户交谈没有替代品。你永远不会停止对他们所说的话感到惊讶。

像 Canny 和 Featurebase 这样的平台也是收集和组织功能请求和错误报告的好方法。它们有 MCP，可以成为脉搏的另一个良好输入。

记忆：保存的报告

每次脉搏运行都会将副本保存到 ~/pulse-reports/ 作为 Markdown 文件。单个脉搏回答"今天发生了什么？"一个脉搏文件夹回答"本月发生了什么？""这个趋势什么时候开始的？""那个功能改变了什么吗？"随着时间推移，文件夹成为团队对产品的工作记忆。

这揭示了，AI 时代的"记忆"不再存储在人脑中，而是外化为可查询、可追溯的结构化文档——组织智能从隐性变为显性。

按节奏运行

Claude Code 有一个例程（Routines）功能，允许你安排频繁任务，因此你可以自动化重复的脉搏运行。我让它每天早上 8 点运行，这样我就能以最新的视角开始工作，了解产品的表现。我通常在一天的其余时间手动运行 /ce:product-pulse 几次。

像创始人一样阅读

代理被指示组装报告，从创始人的角度阅读它，注释异常，并在必要时运行后续查询。例如，如果某个端点产生了更高的错误，它会深入研究这些错误：它们来自一个用户吗？它们与报告的第三方中断同时发生吗？在代理的第二次审查中，除非一切完全正常，否则它会在最后添加一个部分，预先回答自然的后续问题。这样，代理不仅仅是提取数据，而是作为分析师评估和呈现数据。

默认情况下，没有硬编码的阈值，代理会根据这些阈值标记指标。代理使用常识并通过与以前的脉搏数字比较来评估报告。例如，如果响应时间突然平均高出三倍，它会标记并可能进一步调查。如果你确实有特定的性能目标——比如平均系统响应时间——你可以要求代理在相关部分中引用这些目标。

插件

本指南中描述的 ce-strategy 和 ce-product-pulse 技能包含在 Every 的开源 compound-engineering 插件中，可在 Claude Code 中安装：

`` /plugin marketplace add EveryInc/compound-engineering-plugin /plugin install compound-engineering `

欢迎贡献。

更进一步

PM 技能如何融入复合工程

当 docs/strategy.md 存在时，其他复合工程技能（ce-ideate、ce-brainstorm、ce-plan`）将其作为自己工作的基础。策略流入功能构思、规格说明，最终流入发布的代码。下一个脉搏读取结果。这些规划技能也应该参考过去的脉搏报告运行，以便做出更好的功能设计和优先级决策。

产品管理现在关乎有趣的部分

LLM 让我们的工具赶上了产品经理的多方面职责。对我来说，产品管理已经简化为有趣的部分：构思功能、思考设计、查看有趣的数据以及与用户交谈。我们都感受到拥抱 AI 工具的经济必要性，但我认为更好的理由是让工作更有趣。

核心启示：代理原生产品管理不是用 AI 替代 PM，而是用 AI 处理机械性任务，让 PM 回归本质——战略思考、用户洞察和创造性决策。当对话成为工作本身时，产品管理从执行密集型转变为认知密集型。