前八章讲的是产品本身——什么是产品、怎么定义、怎么设计、视觉怎么做。后面四章讲怎么把产品做出来。这一章讲迭代。
先说一个判断:没有"持续优化能力"的开发流程很危险。
很多团队对"开发流程"这四个字的理解,是"按计划交付"。他们做计划——版本一做什么、版本二做什么、版本三做什么。然后照着干。看起来很有秩序。
这种流程是危险的。因为它的前提是"我们一开始就知道要做什么"——这个前提几乎从来都不成立。
做产品最大的不确定性,不在执行,在判断。我们一开始以为用户要 A,做出来发现他要的是 B;我们以为这个功能用户喜欢,做出来发现他不在意;我们以为竞争对手不会出招,做出来发现他抢先了。这些不确定性是产品开发的常态,不是例外。
所以好的开发流程,不是"按计划交付",是"快速优化"。它的核心能力,不在于计划做得有多好,而在于面对意外的时候,能多快地调整方向。
如果一个团队不具备这种"持续优化能力",一旦遇到判断错误——而判断错误一定会发生——它就会被锁死在错误的路径上。它做了一年,做出来一个用户根本不要的东西。这种团队不是不努力,是它的流程让它的努力没法转弯。
我那时候反复跟团队说一句话——目标大致正确,过程持续优化。英文叫 Roughly Right。我们一开始的目标不需要 100% 精确——只要大方向不太离谱就行;真正的精度,是在迭代过程中,通过一次又一次反馈,逐步打磨出来的。
我画过几种开发方式的对比——
最差的方法:瀑布。需求一次定死,设计一次画完,开发一次完成,测试一次跑通,上线。这个流程在传统软件时代可能还能用,但今天做产品,几乎注定失败。原因是它没有任何机会修正一开始的判断错误。
较差的方法:阶段性瀑布。把瀑布切成几个小瀑布——每个阶段允许小范围调整,但整体节奏还是单向的。比瀑布好一点,但仍然慢、仍然脆弱。
理想的方法:多线程并行 + 短周期迭代。客户、运营、设计、开发、测试、部署——这些角色不是接力跑,而是并行跑。研究、建模、需求定义、设计框架、设计细化、设计调整——这些工作不是一次性完成,而是在每个迭代里反复做。
这种流程画出来很乱——是的,它本来就乱。真实的产品开发不像建筑工地那样有秩序,它更像一群人一起跑步,每个人节奏不一样,但大方向一致,中间相互喊话。
迭代是什么?我有一个比较严的定义——
迭代是用强制的时间约束(节拍——beats),将设计过程、实现过程、和体验反馈过程彼此推动不断优化,达成产品目标的完成过程。
这个定义里有几个关键词,我拆开讲:
强制的时间约束。迭代不能是"做完再发"——那不叫迭代。迭代必须有一个固定的时间窗口,到点就发,做完做不完都发。这种"硬节拍"是迭代的命脉。
节拍——beats。我特别喜欢"节拍"这个比喻。一个团队的迭代节奏,就像交响乐里的节拍——所有人按一个共同的节奏走,设计、开发、测试、运营在每一拍上各自该干什么是清楚的。节拍乱了,合奏就崩了。
设计、实现、反馈彼此推动。这是一个三角形——设计驱动实现,实现支撑反馈,反馈又反过来驱动下一轮设计。三角形里的三个角,每一个不能脱节。
具体到工作上,一个迭代周期内,三类工作并行——
每一拍走 X 天,X 一般是 1-2 周。
为什么"强制"?因为人性是反对强制的。
每一个开发到了发版前一天,都觉得"再给我两天我能做得更好"。每一个设计到了上线时,都觉得"这个动效再调一下更舒服"。每一个产品经理到了交付前,都觉得"再加一个小功能用户会更喜欢"。
这些感觉都是对的——但你不能放任它们。如果每次都"再给我两天",你的迭代周期就垮了。
强制节拍的好处是这几个:
目标在变,需要实时优化资源安排。产品做着做着,新的优先级出来了——你必须有一个固定的时间节点,把所有人拉到一起重新对齐。如果没有节拍,大家就各做各的,半年后回头一看,产品和当初的方向已经差了十万八千里。
拆分出最小可用的需求。强制节拍逼着团队思考"两周内能做出来的最小版本是什么"——这种思考本身就是好东西。它逼着 PM 把一个大需求砍成一个个可交付的小块,每一块都能独立验证。
节约时间——时间是最宝贵的资源。一个团队的时间是有限的。如果你没有节拍,大家就会把时间花在"完美"上——这是一个无底洞。强制节拍是一种"够用就发"的纪律。
推动团队合作。节拍逼着所有角色围着同一个时间节点协作——你的设计要在某一天交,我的开发要在某一天开始,他的测试要在某一天闭环。没有节拍的团队,各角色之间的对齐成本是巨大的。
让团队专注于持续优化,而非完美设计。这是节拍最深的好处——它让"完美主义"无法成为延期的借口。你这一拍做不到完美,下一拍可以继续优化;但你这一拍必须先把东西交出去。
减少上架窗口等待期。很多产品要走审核(App Store、应用商店、合规)——审核本身有等待时间。如果你的迭代周期太长,这些等待时间会被放大。短周期迭代能让审核排队和开发排队并行进行。
我那时候团队的标准答案——10 天。
为什么是 10 天?
前端产品(APP、Web、小程序)可以采用 Apple App Store 上架审核的最小周期作为参考——大概 7 天审核 + 3 天迭代开发。10 天是一个能让审核和开发都跑起来的最小周期。
后台产品(服务、平台、数据)需要满足两件事——一是要能跟上前台的迭代周期,二是要留出性能余量和架构调整的部署时间。后台不能比前台慢——一旦后台慢了,整个产品的节奏就被它拖死。
10 天不是死的,但它是一个"危险下限"——比 10 天再长,迭代的好处就开始流失。比 10 天再短,团队会喘不过气来,反而做不出有质量的版本。
不同产品类型可能有不同的最优周期,但一旦定下来,就不要随便改。改周期比换 CEO 还伤——它会让团队所有的协同节奏全部重来。
很多 PM 跟我说"老板要我们提高迭代速度"。我每次都问他——你打算怎么提高?
他给出来的答案,经常是这几个:更多的设计、更多的开发、更多的测试、更多的加班。
这些都不是答案。
更多的设计和开发——说明你的设计和开发本身有效率问题。更多的测试——通常是因为前期质量太差。更多的加班——这是慢性自杀,半年内必然崩。
迭代速度的真正提高,来自一个东西——节奏。
形成固定的开发节奏,就像交响乐里的节拍一样。每个人在每一天都知道自己今天该做什么。设计师知道今天交什么稿,开发知道今天 push 什么 commit,测试知道今天跑什么场景,产品经理知道今天 review 什么。节奏的稳定本身,就是效率最大的来源。
我观察过节奏好的团队和节奏差的团队的对比——同样的人数、同样的预算,节奏好的团队产出能是节奏差的团队的 3-5 倍。这不是因为他们多聪明,是因为他们没有把时间浪费在"等"和"切换"上。
节奏怎么建立?要靠两件事—— 第一,一个清晰的迭代周期(就是上面讲的 10 天); 第二,每一拍内部固定的关键节点——比如周一对齐、周三 review 设计稿、周五 code review、第二个周一发版。这些节点不变,所有人围着这些节点排自己的工作。
迭代周期一长,问题就来了。
最致命的一个字——失败。
我那时候见过几个产品,迭代周期是 3 个月、6 个月,甚至一年发一个大版本。这种节奏下来,结果几乎是注定的:
目标早已偏离。3 个月前定下的目标,到 3 个月后回头看,80% 是错的——市场变了、用户变了、技术变了。但因为发版周期长,中间没有任何机会修正——一旦上线,要么发现做错了再花 3 个月改,要么硬着头皮把错版本推下去。
团队失去节奏。3 个月内,大家变得"看心情干活"——前一个月放松,中间一个月加班,最后一个月赶死。这种波动让团队疲惫,也让管理失控。
反馈链路断了。用户的反馈拿不到、拿到了用不上——因为下一次迭代是 3 个月后,用户已经走了、问题已经积压成山。
上架窗口堆积。如果产品要走审核,长周期意味着每一次上线都要走完整流程,上架审核成为一个独立的灾区。
人员流失。这一条最隐蔽,但最致命。迭代周期长的团队,优秀的人会离开。优秀的人喜欢看到自己的产出快速变成用户手里的东西——长周期让这种成就感被无限拉远,他们就会去别的地方找。
所以迭代周期过长 = 慢慢失败。不是一次性的崩盘,是慢性的死亡。
最后,讲一下我对产品管理核心任务的总结。
四件事——拆分需求、产品定义、节拍驱动、收集反馈。
拆分需求:把一个大目标,拆成可以在一个迭代内交付的最小单元。这是产品经理的根基能力。
产品定义:每一个迭代要做什么、为谁做、解决什么问题、怎么衡量。这是上面好几章讲过的事。
节拍驱动:让团队保持一个稳定的迭代节奏,不被业务方、不被老板、不被外部干扰打断。这一项最难——因为产品经理常常没有"说不"的权力,但他必须有"说不"的能力。
收集反馈:每一个版本上线之后,系统化地收集用户反馈——数据反馈、定性反馈、客服反馈。然后用这些反馈驱动下一个迭代。这是迭代闭环的关键一环——很多团队前三件事做得不错,死在最后一环上。
这四件事看起来简单,真正做到的团队不到 10%。绝大多数产品经理把自己的时间花在写 PRD、画原型、开各种会上,而上面这四件事——核心的四件事——他们都没做。
我对产品经理的判断,从来不看他写多厚的 PRD,看他做不做这四件事。一个 PM 如果只把时间花在文档和会议上,他做的不是产品管理,他做的是文档管理。