Playbook：产品经理

One of the open secrets of product management is that most PMs don't actually manage anyone. PMs generally manage a product, and will work across many people and teams (design, eng, data science, marketing, support) to achieve a goal. The reason the "mini-CEO of the product" trope is BS is because no one reports to (or has to listen to!) said mini-CEO.

产品经理圈子里有个公开的秘密：大多数 PM 其实谁也不管。PM 管的是产品，要跟设计、工程、数据、市场、客服很多人协作才能成事。把 PM 叫成「产品小 CEO」是瞎吹，因为根本没人向这个小 CEO 汇报，也没人必须听他的。

In 2026 the role of the PM is very much in flux, as is the product toolchain. There are now many tools out there that help PMs expand from "idea guy" to full-stack product, design, eng, and GTM builder.

2026 年，PM 这个岗位还在变，工具链也在变。现在有不少工具，能让 PM 从「出主意的人」扩成产品、设计、工程、GTM 都能上手的全栈建设者。

At SpaceXAI, our product team ships code, prototypes new ideas, and works in small teams to build ambitious products. I've tried many AI coding tools and general knowledge-work agents for PM work, and Grok Bot has definitely been the biggest change to my workflow this year.

在 SpaceXAI，我们产品团队自己交代码、做原型，小团队去做比较猛的产品。PM 这摊活我试过不少 AI 写代码工具和通用知识工作代理，今年对工作流冲击最大的，就是 Grok Bot。

I've been using Grok Bot internally for a few months ahead of launch to build the product. It definitely comes with a learning curve, but once you figure it out it's very empowering and fun to use if you love to build.

上线前几个月，我就在内部用 Grok Bot 做这个产品。上手确实有坡，但摸清了之后很带劲。你要是爱做东西，会觉得好玩。

What is Grok Bot? Grok Bot is a team of always-on agents with their own computer that can learn and amplify your work. So for perhaps the first time, if you're a PM you can now have a "team" (of agents) that reports directly to you and helps you ship.

Grok Bot 是什么？一组一直在线的代理，有自己的电脑，能学、能放大你的工作。所以也许是第一次，PM 可以有一支「团队」（一群代理）直接向你汇报，帮你把东西发出去。（「自己的电脑」是作者的说法；正式文档写账号下所有 Bot 共用一台云电脑、各自屏幕。）

Many PMs create weekly goals or priorities that quickly go stale. Rather than creating a "priority list" (which will become outdated throughout the chaos of a day) I've started to have Grok Bot follow my attention across Slack, email, and meetings / Granola to create something different: an "attention list."

很多 PM 会写周目标、周优先级，很快就过时。与其做一张「优先级清单」（一天乱下来就会旧），我改成让 Grok Bot 跟着我的注意力走：Slack、邮件、会议 / Granola，做出另一种东西——「注意力清单」。

Am I active in a bunch of incident channels? Am I working with the recruiting team to close a candidate? Has someone sent me a launch blog post to review? My Chief of Staff sees all this work happening and can maintain an implicit priority list as I work.

我是不是泡在一堆事故频道里？是不是在跟招聘一起催一个候选人？有没有人丢给我一篇上线博客要审？幕僚长看着这些正在发生的事，就能在我干活的同时，维持一份隐含的优先级。

PMs often work across a bunch of different teams and contexts. I've found that what I'm actually talking about and doing throughout the day is a much better live view of what matters than trying to keep a list of priorities updated. This feels like a new type of work primitive, the "attention list." It differs from a set of goals, priorities, or a to-do list in that it is emergent from your work and attention.

PM 经常横跨很多团队、很多场景。我发现：一天里我真正在聊、在做的事，比硬更新一张优先级清单，更能实时看出什么要紧。这像一种新的工作原语，叫「注意力清单」。它不是目标、优先级或待办，它是从你的工作和注意力里长出来的。

I've found it to be useful in two ways: (1) Agents can apply the attention list as a filter. Throughout the day there are thousands of Slack messages and emails that can distract or need me, so agents can use this to guide my attention to threads relevant to what I'm focused on. (2) You can compare stated priorities and goals vs. what I'm actually focused on.

我觉得有两个用处。一，代理拿它当过滤器。一天里几千条 Slack 和邮件会吵你、找你，代理可以用它把你的注意力领到跟当前焦点相关的帖子上。二，你可以拿「嘴上说的优先级和目标」对照「我实际在盯什么」。

To set this up: "Create an attention list: every hour, review email, Slack, Granola, and calendar and create a succinct set of projects I'm focused on and their current state, what needs to happen next." To use: "Review my attention list and archive any emails that are not relevant to my focus list." "Where did I spend time this week that I can offload to an agent going forward?"

怎么建：「做一份注意力清单：每小时看一遍邮件、Slack、Granola 和日历，简洁列出我在盯的项目、现状、下一步该发生什么。」怎么用：「对照我的注意力清单，把跟焦点无关的邮件归档。」「这周我把时间花在哪了，哪些以后可以卸给代理？」

Product teams have an ever-growing dataset that is useful for understanding new products or gaps in existing products. Every customer meeting is recorded and transcribed with Granola and Gong. We're in customer Slack channels where product feedback is streaming in. Our user researcher Stan has built a database with every interview, user insight, and synthesis. Usage and subscription data lives in Databricks. Support tickets live in Plain or Intercom. Complex product decisions are documented in Notion.

产品团队手里的数据越堆越多，能用来看新产品，也能看现有产品的缺口。每次客户会都用 Granola 和 Gong 录音转写。我们在客户 Slack 频道里，产品反馈一直往里涌。用户研究 Stan 建了库，访谈、洞察、综述都在里面。用量和订阅在 Databricks。工单在 Plain 或 Intercom。复杂产品决策写在 Notion。

The challenge is making all this raw context legible to agents, and using it to inform and shape product direction going forward. Which of our recently onboarded enterprises are using a given product feature? Where in the funnel are our customers getting stuck? Agents can now answer these questions and inform product direction in much more holistic ways by synthesizing info across raw sources.

难的是：让代理读得懂这些生上下文，再用它来影响后面的产品方向。最近接入的企业里，谁在用某个功能？客户卡在漏斗哪一层？代理现在能跨原始来源综合信息，用更整全的方式回答这些问题，给产品方向当输入。

To set this up: make sure you've enabled plugins for all the core tools where customer context lives, and authenticated into any system on the VM that doesn't have an MCP.

要先做到：客户上下文所在的核心工具，插件都打开；没有 MCP 的系统，在虚拟机上自己登录进去。

The thing I've been most surprised by is how good Grok Bot is for actually shipping software. Grok Bot now represents a double-digit percent of our internal merged PRs. Grok Bot agents can use Cloud Agents, operating in an environment that's equipped with the codebase, dependencies, secrets, and everything agents need to test their work.

最让我意外的是：Grok Bot 真能把软件发出去。我们内部已合并的 PR 里，现在有两位数百分比来自 Grok Bot。这些代理能用 Cloud Agents，环境里有代码库、依赖、密钥，以及测试自己成果需要的一切。

For a PM, this allows you to operate at a higher order of abstraction. Rather than managing individual threads or juggling many individual agents, you can express much more sophisticated goals to a Grok Bot agent who can decompose and allocate work to other agents, then review and integrate the outputs in new ways. With Grok Bot, frontier models, and the right cloud agent environments, PMs can take on much more ambitious builds.

对 PM 来说，你可以在更高一层做事。不用自己管一条条线程、同时耍很多单个代理，你把更复杂的目标丢给一个 Grok Bot，它再拆开、派给别的代理，然后用新的方式审和拼结果。有 Grok Bot、最强那档模型、配好的云端编码环境，PM 能接更猛的活。

The roster I actually run: Chief of Staff (calendar, Slack, inbox — the only generalist; stays quiet if nothing changed); Eng mgr Emily (does not code; breaks work down, delegates to IC eng agents, checks the output against the goal); Eng ×5 (spin Cloud Agents and receive work from the EM); Data analyst Ashley (warehouse, charts, tracking goals; reviews the dash every morning); PM Pete (RFCs, research, feedback, docs; sits in the work; hardware too); Recruiter (finding undiscovered talent and managing recruiting loops).

我实际在跑的编制：幕僚长（日历、Slack、收件箱——唯一的通才；没变化就闭嘴）；工程经理 Emily（自己不写代码；拆活、派给一线工程代理、对照目标验收）；工程师 ×5（拉起 Cloud Agents，接 EM 派来的活）；数据分析 Ashley（数仓、图、盯目标；每天早上过仪表盘）；PM Pete（RFC、研究、反馈、文档；人就坐在活里；硬件也沾）；招聘（找还没被发现的人，管招聘闭环）。这是作者自己的实验编制，不是产品硬限制。

This is the one on my calendar, Slack, and inbox. General day-to-day. Owns the attention list. Example: Chief of Staff reads Slack throughout the day and keeps my focus list up to date. Hourly it archives Gmail unless the thread names me and maps to that list. Last week it sent holds and asked me to pick a start time. I said 10am. It moved the hold.

这是盯我日历、Slack、收件箱的那个。日常杂事。注意力清单归它。例子：幕僚长白天一直读 Slack，把我的焦点清单保持最新。每小时归档 Gmail，除非那条线程点了我的名、又对得上焦点清单。上周它先占了时间，问我几点开始。我说上午 10 点。它就把占位挪过去了。

Trick: one of the biggest complaints with LLMs is that they are bad at writing. Have it write a personal style guide from your outbox and Slacks, then sample the exact thread before it drafts so it sounds like you, not a bot. I still keep final review for any external email sends, purchasing anything, or destructive actions like deletes.

窍门：大家最嫌大模型不会写。让它从你的已发邮件和 Slack 里写一份个人文风指南，起草前再抽样看那条原帖，听起来才会像你，不像机器人。对外发邮件、买任何东西、删除这类破坏性动作，我仍然自己做最终审。

Sadly, my EM is not supposed to code! Just manage. EM is responsible for breaking down technical work, delegating and managing IC eng agents, and validating outputs against the goal. I had my EM onboard by reading all of @danielstjules's Slacks, to learn what great looks like.

可惜，我的工程经理按规定不写代码！只管理。职责是拆技术活、派活并管一线工程代理、对照目标验收产出。入职方式：让它读完 @danielstjules 的 Slack，学习「好」长什么样。

EM delegates work to eng IC agents. I currently have a team of five, but you can have as many as you want. These eng agents use Cloud Agents under the hood, can manage many of them at once, validate and test their outputs, and coordinate work with each other. It's agents all the way down.

EM 把活派给一线工程代理。我现在养了五个，作者说「想要多少就能有多少」（作者自己的说法；账号硬上限是 Bot+群合计 50）。这些工程代理底层用 Cloud Agents，能同时管很多个，验收、测试产出，彼此协调。一层套一层，全是代理。

This is the one I use the most. Hooked up to the warehouse, I've asked my data analyst to mostly speak to me in well-synthesized charts. Throughout the day, I'll have a bunch of different questions that could be answered with data. Previously these questions would just go unanswered, because the friction of asking and answering them was too high.

这个我用得最多。接到数仓上，我让数据分析尽量用综合好的图跟我说话。一天里我会冒出一堆其实能用数据回答的问题。以前这些问题就这么悬着，因为问和答的摩擦太大。

I don't look at this as displacing a traditional data science or data analytics team. We still have many hard, ambiguous questions that need to be answered with high degrees of taste and interpretation. But for more tactical questions, or questions that have been answered before but need to be refreshed or cut slightly differently, I'm now turning to Grok Bot.

我不把这看成取代传统数据科学或数据分析团队。仍有很多又难又含糊的问题，需要很高的品味和解读。但更战术的问题，或者以前答过、现在要刷新、换个切法的问题，我现在丢给 Grok Bot。

I've wanted a product sidekick forever. Most tools fail because they are not in the mix. PM Pete is my go-to for general product exploration: new product ideas, research, feedback, docs. RFCs and product reviews that sound like a PM, not an intern summarizing Slack.

我一直想要一个产品搭档。多数工具失败，是因为人不在局中。PM Pete 是我做一般产品探索的首选：新产品点子、研究、反馈、文档。RFC 和产品评审要听起来像 PM，不像实习生在总结 Slack。

Example: turn a channel, thread, or DM discussion about a feature split into an RFC (P0–P2) with quotes. We've even started hacking on some hardware together. PM Pete researched a missing Raspberry Pi part and ordered it off Amazon, then taught me how to wire it up.

例子：把某个频道、帖子或私信里关于功能拆分的讨论，整理成带原文引用的 RFC（P0–P2）。我们甚至一起鼓捣硬件。PM Pete 查到缺的树莓派零件，在 Amazon 下了单，再教我怎么接线。

Probably the biggest design question is whether to just have one omniscient agent or many specialized agents. The way I use Grok Bot cuts against the current paradigm of the blank text box with a general-purpose agent that in theory should be able to do everything.

最大的设计问题大概是：要一个全知全能的代理，还是很多专职代理。我用 Grok Bot 的方式，跟现在流行的「空白输入框 + 理论上什么都能干的通用代理」是反着的。

I've found the partitioning of workloads to specialized agents useful for a few reasons: referenceability (you know who does what); parallelism (many working at once on discrete tasks, coordinating on shared ones); scoped memory (they learn different things on the job). Outside of that, I generally find having these different agents more fun to work with.

把活切给专职代理，我觉得有几条用处：可指认（你知道谁干什么）；可并行（很多人同时做分开的活，共享的活再协调）；记忆有范围（上班学到的东西不一样）。除此之外，跟这些不同的代理共事，我通常觉得更好玩。

1. Named agents, separate memory. Each agent has a broad goal or mission but scoped memory relevant to their type of work. Chief of Staff should not be debugging computer-use evals. The eval agent is not archiving my mail.

1. 有名字的代理，分开的记忆。每个代理有一个宽目标或使命，但记忆只跟自己那类活相关。幕僚长不该去调 computer-use 评测。评测代理不该去归档我的邮件。

2. Agents learn on the job. Agents can learn from your past work, and you can continue to teach them things. "Read my past Slack messages and develop a Slack style guide for me" is the highest-leverage instruction I've found.

2. 代理在岗上学。它们能从你过去的工作里学，你也可以继续教。「读我以前的 Slack，给我做一份 Slack 文风指南」是我找到的杠杆最大的一条指令。

3. Agents shouldn't be noisy. Grok Bot agents bias to action but can also over-communicate. Ask them to stay quiet unless something needs your attention to reduce distraction and noise.

3. 代理不该吵。Grok Bot 偏向动手，但也会话太多。让它们没事闭嘴，除非有事需要你看，噪音才会下来。

4. Human on the important stuff. For now, I continue to send most messages and edit most docs and ideas. Both to de-slopify, and because I've found people want to know that the messenger spent some time thinking through any ask.

4. 要紧的事留给人。目前大多数消息还是我发，大多数文档和想法还是我改。一是去掉 AI 味，二是我发现别人想知道：开口的人自己想过这件事。