迭代、运营与增长
本章导读
上一讲结束时，研习团队用一套指标和实验，把错题归集首轮数据的性质说清了：那些上涨的点击和使用，只能证明「有人用」，还不能证明「有用」。数字漂亮，但价值证据仍然没立住。
按说下一步应该继续把价值验清楚。可团队没这么干，而是顺手做了一个看起来最顺、也最累人的决定：既然手上有三十条用户建议，那就把能做的都塞进版本清单，连续发版赶进度。三周后三个新功能上线了，月活没变，复习完成率也没变。
这一讲就从那次复盘会开始，看团队怎么从「发了很多版本」走回「每做一轮都要学点东西」。我会拆五段结构把一轮迭代写完整，再讲三种验证的区别——你是在探索问题，还是在验价值与可用性，又或者是在看真实效果与增长。还会聊生命周期运营，提醒你别把一场活动的峰值当成产品能力，最后怎么把一次失败复盘保留下来。
最后落成的东西，是三份完整的迭代记录和一次失败复盘。下一讲《商业化、风险与长期价值》会从「增长开始发生之后」接下去，讲怎么在长期价值与短期收入之间做取舍。
说明：本讲的故事、角色和数字都是教学案例或教学假设，只用于演示推理。除来源一节列出的腾讯公开材料外，不指向任何真实产品或腾讯数据。
开篇：三次发版，复盘会上没人答得上来
归集 MVP 上线后的一个月里，团队陆陆续续收到三十条用户建议。大鹏在例会上把它们排进版本清单：V1.1 增加错题导出模板，V1.2 增加错题分享给研友，V1.3 增加连续打卡积分。
他带着团队连续交付，三周发完了三个版本。阿May为打卡积分配了一场「连续七天打卡」的活动，那几天的日活确实往上跳了一截。
月末复盘会上，老周把数据投出来：月活跃用户还是约八万，复习完成率仍在两成上下，三个新功能的周使用人数分别只有几十到一两百（教学假设）。
小林问了大家一句：「这一个月，我们学到了什么？」
没人答得上来。三个版本都上线了，可没有一个写明了假设、证据和结论。版本数量不等于迭代，三次发布只是三次交付。
小雨翻开访谈记录补了一句：「提导出模板的是两个要打印错题的学生，提分享的是几个考研搭子，提打卡的是想要有人监督的用户。三批人根本不是同一群人，我们却把他们的意见放在一起，平均处理了。」
至少存在三种解释。
第一种，问题不在功能太少，而在归集与复习计划之间的价值没有被证明，加功能只是在未验证的路径上继续堆。
第二种，用户建议集中在不同人群，团队把所有人的意见平均处理，没有分层，结果每个功能都只服务一小撮人。
第三种，团队把「上线」当成了「学习」，没有在每一轮之后停下来记录哪个判断被支持、哪个被推翻。
三种解释指向同一个缺口：团队缺少一轮又一轮的迭代结构，而不是缺少新的功能想法。
先看最省事的做法：把建议排进版本清单
最直接的简单做法，是把用户建议排进版本清单，能做的都做，发版越快越好。
这种做法在一种条件下有效：产品已经确认价值，用户反馈都是同一核心路径上的修补，此时快速交付能更快把路径补齐。
但它在另一种条件下失效：核心价值还没有被证明，反馈来自不同人群和不同问题，连续发版只会把多个未验证判断叠加在一起。研习正处在这种失效条件里，因为归集的价值证据还不成立。
每个版本都代表一次「做完了」，但不代表一次「学到了」。如果一轮之后，你不知道哪个判断被支持、哪个被推翻，那这个版本只是把更多未经验证的想法放到了线上。版本越多，能怪的东西也越多，反而越难定位真正的缺口。
一次迭代的最小结构：五段
《腾讯产品18讲》强调快速行动、快速试错和快速转型，同时也指出「快」不是平均地给所有方向增加资源，而是在核心优势上持续发展。
我们把一轮迭代写成五段：假设、动作、证据、结论、下一步。
假设，是这一轮仍然不确定的那项判断。动作，是这一轮只改变什么。证据，是观察哪些用户、行为和指标。结论，是假设得到支持、被反对还是证据不足。下一步，是继续、修改、扩大还是停止。
假设：哪项判断仍不确定
动作：这一轮只改变什么
证据：观察哪些用户、行为和指标
结论：假设得到支持、被反对还是证据不足
下一步：继续、修改、扩大或停止
如果一轮迭代没有假设，它只是一次发布；如果一轮迭代没有结论，它只是一次实验消耗。五段缺一段，这轮就不算完整学习。
很多人以为难在「动作」，其实难在「假设」和「结论」。写假设，逼你承认还有什么是你不确定的；写结论，逼你只用三种表达之一收尾，不许含糊。动作再漂亮，没有这两段，也只是一次没有记忆的忙碌。
第一轮：问题探索
第一轮的目标是确认用户问题、场景和替代方案。常用动作包括访谈、观察、人工服务和低保真原型。
研习在归集立项前其实已经做过一轮问题探索，但做得不完整。真正的问题探索轮应当这样写：假设是「重做题用户在每天结束学习后，因手动抄写成本高而无法持续积累错题」；动作是十场访谈加一次行为日志核对；证据是用户表达、实际整理行为和当前替代方案；结论是问题对部分用户成立，但只在记录过五次以上错题的人群中明显。
失败信号是不同证据无法支持同一个问题解释。此时不应进入完整开发，而应回到问题定义，把「我们以为的问题」改成「证据指向的问题」。
第二轮：价值与可用性验证
第二轮的目标是确认用户是否愿意使用核心能力，以及是否能够完成任务。常用动作包括 MVP、可用性测试和小范围灰度。
研习的第二轮就是上一课的 MVP。它的假设是「用户愿意为归集后自动进入复习计划改变行为」；证据是十位用户中多少人确认归类、次日是否打开复习计划。
价值失败与可用性失败需要分开。用户不会使用，不等于用户不需要，可能是入口难找或步骤太多；用户会使用，也不等于结果有价值，可能只是好奇点开。第二轮不能只看有没有人用，还要看用完之后是否完成了任务。
第三轮：真实效果与增长验证
第三轮的目标是确认产品在真实环境中持续产生结果，并找到可重复的增长方式。常用动作包括指标分群、漏斗分析、A/B测试和运营实验。
研习的第三轮对应上一课的实验设计：用对照组判断归集是否真的提高了复习完成率，再分群看新老用户差异。
增长失败可能来自价值不足，也可能来自触达、激活、留存或供给中的某个环节。假设复习完成率没有提高，团队不能直接说「产品没用」，还要检查用户是否被触达、是否在正确场景被激活、是否留存、供给是否充足。把增长失败直接归为价值失败，会错过可修复的环节。
三轮是最低要求，不是腾讯规定
腾讯公开课程没有规定产品必须迭代三轮，也没有规定每轮必须叫什么名字。本课程设置三类最低迭代，是为了避免团队只做界面优化和功能堆叠。
三轮不是产品只能迭代三次，也不是每做一次就要完整走完三轮。它的意思是：在一个方向上投入完整开发之前，至少分别用证据回答过三个问题——问题是否真实、核心价值是否可用、真实效果是否成立。腾讯材料里真正的约束，是快速试错要集中在核心优势上，而不是三轮这个数字本身。
如果有人把你的三轮迭代记录，误读成「腾讯要求产品都要走三轮」，那是一种混淆。三轮是本课程为了让学习结构清晰而设的最低要求，不是腾讯公开课程的官方流程。引用腾讯材料时，只引用能核验的那句话：快速试错要集中在核心优势上。
生命周期运营不是补丁
《腾讯产品18讲》把运营工作放在不同生命周期中讨论。初创期重点是找到种子用户和核心使用方式；成长期重点是可重复拉新、激活与留存；成熟期重点是效率、生态和新增长点；衰退期则需要判断是寻找新场景还是有序收缩。
研习目前处于成长期，归集功能适合观察留存，而不是追求单次峰值。渠道运营、活动运营、内容运营、用户运营和社区运营解决的问题不同。阿May做的那次打卡活动让日活短期冲高，但活动结束后行为回落，这不能解释为产品留存能力的变化。
运营要回答的是：活动峰值结束后仍保留的行为变化，才更接近产品能力的变化。否则运营只是产品上线后的补丁，峰谷之间没有积累。
失败复盘要保留失败
一次完整复盘至少包含七件事：当时掌握的信息和决策条件；原假设与预期指标；实际发布范围和外部变化；总体数据与关键分群；用户反馈和异常案例；哪个解释被推翻；下一轮只改变什么。
研习对 V1.1 到 V1.3 的复盘应当承认：三个功能都没有写假设，也没有对照，所以无法判断是功能无效还是人群不对。如果复盘只记录「做得好」和「待提升」，团队无法积累可复用判断。
保留失败不是写检讨，而是写清哪个解释被证据推翻，让下一轮不再重复同一个错误。
压力测试：把交付当迭代
我们做一次压力测试：如果一个团队每周发一个版本、持续十二周，它的迭代质量如何。
假设这个团队每周都发布新功能，但从没有写过假设和结论。十二周后，产品功能数量翻倍，月活没有变化，团队却说不清哪一次发布改变了哪项判断。交付速度很高，学习速度为零。
反过来，一个团队四周只做一轮，但写清了假设、动作、证据、结论和下一步。哪怕结论是「不支持当前假设，需要缩小范围」，它也完成了学习。因此评价迭代的不是发版次数，而是是否形成了可复用的判断。
逐步执行：迭代与增长流程
第一步，从上一课的结论里取出一个仍然不确定的判断，写成这一轮的假设。研习取的是「归集是否真的提高了复习完成率」。
第二步，限定动作，这一轮只改变一个东西，写清不改什么。研习只改「归集后是否自动进入复习计划」，不改识别和导出。
第三步，提前定证据，写清观察哪些用户、行为和指标，以及什么结果算支持、什么算反对。研习把「七天复习完成率提高五个百分点」定为支持条件。
第四步，运行并记录，只允许三种结论：支持、不支持、证据不足。
第五步，写下一步，明确继续、修改、扩大或停止，并说明依据。
第六步，判断当前处于哪一轮：问题探索、价值与可用性、还是真实效果与增长，避免跳过验证直接堆功能。
第七步，每完成一个阶段做一次失败复盘，保留被推翻的解释和下一轮只改什么。
可直接填写的模板
一轮迭代记录
所属阶段（问题探索 / 价值与可用性 / 真实效果与增长）：
假设（哪项判断仍不确定）：
动作（这一轮只改变什么）：
不改什么：
证据（观察哪些用户、行为和指标）：
支持条件：
反对条件：
结论（支持 / 不支持 / 证据不足）：
下一步（继续 / 修改 / 扩大 / 停止）：
依据：
填完这张表，做一次自我检查：如果这一轮结束后你只能说「我们发了个新版本」，却说不清假设被支持还是被推翻，那这一轮还没做完。补上结论和下一步，才算把「交付」变成「学习」。
常见误区及其可见后果
第一种误区，把版本数量当成迭代。可见后果是发版很快，但团队说不清哪次发布改变了哪项判断。
第二种误区，把用户建议平均处理。可见后果是每个功能只服务一小撮人，没有分层的方案最终谁也留不住。
第三种误区，跳过问题探索直接做完整开发。可见后果是产品上线后才发现问题不存在，前面的开发都是沉没成本。
第四种误区，把价值失败和可用性失败混为一谈。可见后果是用户不点开就急着改功能价值，或者用户点了但没结果却只改按钮位置。
第五种误区，把活动峰值当成留存能力。可见后果是团队为短期流量反复做活动，峰值结束后产品并没有变得更强。
第六种误区，复盘只写做得好和待提升。可见后果是失败的解释被抹掉，下一次继续犯同样的错误。
课堂练习
给出一份教学材料：某个产品连续四周每周发布一个新功能，四周后新增用户、留存和完成率都没有变化，团队准备继续按周发布。这组周期与结果为教学假设。
请在十分钟内完成三件事：指出这四次发布缺少了迭代五段中的哪几段；把其中一个功能改写成一轮完整迭代（假设、动作、证据、结论、下一步）；判断这个功能应属于问题探索、价值与可用性还是真实效果与增长。
写完后交换，检查对方的结论是否只用了「支持、不支持、证据不足」三种表达。
最终作业
回到上一课的指标与实验，提交三轮迭代记录。
要求：三轮必须分别解决问题真实性、核心价值或可用性、真实效果或增长中的不同问题；每一轮都完整填写五段；至少一轮以缩小范围、撤回功能或停止方向结束；另附一次失败复盘，写清哪个解释被证据推翻。所有非来源数字必须标明教学假设。
评分标准
| 字段 | 评分要点 |
|---|---|
| 迭代五段 | 是否假设、动作、证据、结论、下一步都完整 |
| 假设 | 是否只写一个仍不确定的判断，是否可观察 |
| 动作 | 是否只改变一个东西，是否写清不改什么 |
| 证据与结论 | 是否提前定支持/反对条件，结论是否只用三种表达 |
| 三轮覆盖 | 是否分别覆盖问题、价值与可用性、效果与增长 |
| 停止或缩小 | 是否至少一轮以缩小、撤回或停止结束 |
| 失败复盘 | 是否写清被推翻的解释和下一轮只改什么 |
| 数字来源 | 是否标明教学假设或来源事实 |
本课不能证明什么
迭代和运营不能证明产品最终会增长，也不能证明某一轮的价值判断一定正确。它们只能证明，团队在每一轮之后是否形成了可复用的判断，以及下一轮是否基于这个判断做出选择。
一次复盘通过也不能保证下一轮成功。它只能降低重复犯同一个错误的概率，不能消除市场和用户的变化。
把这一点写清楚，是为了在下一次连续发版之后，不会反过来怪「迭代都做了，产品怎么还没起来」。迭代本来就不负责保证增长，只负责让每一轮都留下一个可以被下一次引用的判断。
与下一课的连接
当产品在迭代中站稳、增长开始发生之后，收入和风险问题会变得无法回避：怎样在长期价值与短期收入之间取舍，怎样识别信息、操作、资金、合规和公关风险。
下一课《商业化、风险与长期价值》从这里接下去。它会教我们怎样让商业模式从产品场景中生长出来，而不是伤害用户体验换取收入，并在增长之后重新检查产品是否仍然成立。