产品的工作流程 | 基础 | 做产品

产品的工作流程

十六个环节，每一步都有明确的交付物。跳过哪一步，欠的债都会在后面某一步还。

读完你能回答

这套流程是大团队协作磨出来的，不是仪式。它的价值在于把「交付物」定死了：上一步交不出东西，下一步就开不了工。你一个人做产品的时候，人少了，交付物一个都不会少，只是从文档变成了脑子里的判断。

想清楚 1–4 步调研报告 · 用户画像 · 产品路线图 · 带优先级的需求列表这一段决定「做不做」，做错了后面全部白干

画出来 5–9 步站点地图 · 信息结构图 · 原型 · 交互文档 · UI 稿这一段决定「长什么样」，评审是唯一的刹车

做出来 10–13 步用例文档 · 可运行的东西 · 埋点方案 · 测试报告埋点在这一段就要定，不是上线后补

放出去 14–16 步版本说明 · 操作手册与 FAQ · 反馈汇总 · 下一轮迭代计划没有这一段，产品只是发出去了，不算上线

四段之间是硬交接。信息结构图没画完就开始画原型，页面会越加越多；埋点没定就开发，上线后只能靠猜。

把十六步按「AI 能替你干多少」重排一遍，能看出你的时间该花在哪。

压缩很多

6 原型设计 9 UI 设计 11 产品开发 10 用例编写

原来几天到几周的活，现在按小时算。这几步不再是瓶颈

压缩一些

5 信息结构 7 交互设计 13 产品测试 14 发版资料

它能给出方案，但选哪个、边界怎么处理，还是你定

几乎没压缩

1 市场调研 2 用户调研 3 产品规划 4 需求管理 8 评审

被压缩的四步，原本占了大团队一半以上的工时。它们变快之后，瓶颈整个前移到了「想清楚」那一段——也就是最没被压缩的那一段。

这解释了一个常见的感受：做得越快，废弃的东西越多。产出速度提高了十倍，判断速度没有变。

把十六步压成五步，交付物保留，形式从文档换成能直接喂给 AI 的东西。

想清楚给谁、解决什么列内容页面和数据写规格状态和边界让它写一次一件验收走查加埋点

交付物换了形式

调研报告→一句话产品 + 一份反面清单信息结构图→内容清单 + 页面地图 PRD 和用例→一份 spec 文件，AI 直接照着写

形式变了，问题没变。规格文件回答的仍然是用例文档那几个问题：有哪些实体、会出现哪些状态、异常怎么处理。

先规格后代码这条流程里 5 到 10 步的交付物，一个人做的时候全部压进一份规格文件。这一篇讲那份文件长什么样。

产品的类型与方向同一套流程，做 C 端和做 B 端的重心完全不同：前者在调研和数据上花时间，后者在流程和权限上花时间。

先埋点后上线流程里第 12 步。它排在开发和测试中间，不排在上线之后，这个位置是关键。