产品经理：把散落的输入变成能落地的交付

一、产品经理每天在跟什么较劲

真正坐下来写文档的时间，可能只占产品经理一天的三成。剩下七成花在别处：需求从业务群里冒出来，用户访谈录了音还没听，上周评审到底定了什么得翻纪要，开发问一个字段口径的问题，你要回去查三个文档才敢回。等把这些捞齐，一天已经过去大半。

这个岗位的输入极度分散，输出却高度结构化。输入是几十个群、十几份文档、几场会的录音、老板走廊上说的一句话；输出是一份 PRD、一张需求台账、一版原型、一次评审的结论。中间那段把分散变成结构的活，才是产品经理每天在干的事。

这一段也正好是豆包工作接上飞书之后最能帮上忙的地方——它能直接读到那些分散的输入，不需要你先把它们复制粘贴一遍。

二、你的上下文散在飞书哪儿

先花十分钟画出你自己的这张表，后面所有场景都建在它上面。

不同公司叫法不一样，有的用飞书项目管需求，有的用多维表格，有的还在用文档里的表格。你得先知道东西在哪，才能让它去取。

这张表里最容易被忽略的是「讨论过程」那一行。结论有人记，过程没人记，三个月后有人问「当初为什么不做 B 方案」，全组没人答得上来。群聊记录其实一直在，只是没人愿意翻。这恰好是 Agent 擅长的事。

三、五个高频场景

获取昨天到现在飞书上未读的群聊记录，把跟我有关的待办全部提出来，标明每条的来源群和提出时间，再按「需要我做的」和「Agent 能做的」分成两份清单。拿不准算不算待办的，单独列一栏问我，不要自己判断。

获取飞书妙记里今天下午那场需求评审的会议记录，整理成纪要：分会议结论、待办事项、悬而未决三部分。待办必须标明责任人和截止时间；讨论过程不展开，只保留结论和结论背后的关键理由；发言人有分歧的地方要写明分歧双方的观点，不要只留一方；拿不准的地方标注出来问我，不要臆断。

基于刚才这份纪要，加上「XX 需求」这份现有 PRD，把评审确认的改动更新进去。改动的地方在文档里标出来，原来的写法保留在旁边的批注里。悬而未决的部分不要自己拍板，写成待确认项列在文末。

调研这四个竞品：A、B、C、D。对比维度：定价方案、核心功能清单、目标客户、最近半年的版本更新节奏。用浏览器操作打开各家官网和更新日志抓取信息，关键页面截图留档。整理成一张对比表，每条信息标注来源链接和抓取日期。官网上查不到的维度留空并说明，不要用行业常识补。

基于这份 PRD，做一版可交互原型，覆盖主流程的四个页面：列表页、详情页、创建弹窗、结果页。界面按管理后台的常规样式，不用做视觉设计。每个页面上把对应的 PRD 章节号标在角落，方便对照。做完发布成链接。

获取妙记里这周五场用户访谈的录音记录（会议名：用户访谈 01–05）。每场整理成一份访谈记录：
一、用户的基本情况，只记他自己说的，不推测；
二、他提到的每一个问题和需求，附原话，原文引用不要改写，标明是第几场第几分钟；
三、他实际的操作路径和卡住的地方，按他描述的顺序记；
四、访谈者的追问和他的回应。
五场都整理完后，再做一张汇总表：把五场里出现过的问题归类，同一件事的不同说法合并，标明每类被几个人提到、代表性原话。
不要给结论，不要写「用户普遍认为」，五个人不是普遍。

四、该装哪几个技能、伙伴、连接器

自定义技能是产品经理最值得投入的一项。每家公司的 PRD 结构都不一样，把你们的模板、必填章节、评审标准写成一个技能，往后所有需求文档都按同一套骨架产出，新人也能直接用。判断标准是第五章说的三条：反复在做、结构固定、你已经跑通过一次。

五、成果怎么回流飞书

产出留在本地就只是你一个人的草稿，回到飞书才是团队资产。产品经理这个岗位尤其明显——你的输出本来就是给别人看的。

• 纪要写成飞书文档存进项目空间，@ 相关的人，比在群里发一段文字更容易被回查
• 待办直接建成飞书任务派给负责人，做完了状态自己会变，不用你追着问
• 需求台账写进多维表格，可以转成实时看板给老板看进度
• 原型发布成链接，业务方在上面直接评论，评论又变成下一轮的输入

这里有个容易被忽略的连锁反应：今天沉淀回飞书的东西，是明天的上下文。 这次的纪要存进了项目空间，下次它写复盘的时候就能读到；这次的需求台账建在多维表格里，下个季度做规划时它能直接统计。回流不只是给同事看，也是在喂你自己的下一个任务。

六、产品经理指令卡

括号里换成你自己的信息，直接复制改。