课后分享
今天的课后题是：你在以往需求落地过程中遇到过哪些坑？再来一次的话，有哪些地方可以做得更好？欢迎你在留言 区与大家分享；关于产品你还有哪些问题，也欢迎向腾讯产品专家提问，主讲老师将回复你的问题。

你好，欢迎来到腾讯大学出品的《腾讯产品18讲》。

上一讲，我们学习了产品需求设计的基本原则，产品经理需要面向用户实际的使用场景，弄清楚我们正在解决什么用 户，在什么地方，遇到的什么问题，并建立从基础到高级的需求模型，优先保障可用性，不断优化体验，之后再扩展 更多用户群，放大影响力，实现业务生态布局，从基础到高级依次向上满足。

今天这一讲，我们将继续讨论，这些对用户有价值的需求，应该怎么落地，以及如何检验这些需求满足了设计的初 衷。

品质决定资源投入——用流程机制为长周期产品的落地保驾护航。

首先，我们来看长周期产品。用一句话总结：品质决定资源投入——用流程机制为长周期产品的落地保驾护航。

互动娱乐事业群（简称IEG）作为腾讯最成功的BG之一，陆续推出过许多用户喜闻乐见的产品，并且多数产品都能保 持较高的质量水准。这背后有什么诀窍吗？通过什么办法，能让产品品质都实现80分以上呢？Gate Review（简称 GR）评审，就是IEG取得成功的一个重要方法。

GR是一套产品制作立项的评审帮助流程，由各方具有丰富经验的专家们，在产品研发生命周期中的关键评审点，全方 位给予项目组各方面的指导。GR评审从最初的创意到产品正式对外发布，一共分为5个步骤，从GR1到GR5，只有通 过每一轮GR评审的产品，才可以进入到下个阶段，并获得匹配的资源投入。GR作为制度和流程的保障，为IEG的项目 保驾护航，合理分配资源，并可以把一些明显劣质、不适合的产品从流程中剔除掉，从而缔造精品。

下面，我们来看一下GR评审的流程：

1、GR1又叫Concept（概念）阶段，团队在这个阶段需要筛选和提炼产品的核心概念，同时，需要关注市场分析、用 户定位、用户体验和产品风险等方面。这一轮评审的目的是：产品创意符合当前形势，并能使组织在可预见的未来， 获得进一步的（或可持续的）成功。如果GR1顺利通过，将组建项目核心小组，启动筹备工作。

2、GR2的关键词是 Prototype（原型），项目筹备小组在此阶段需要开发产品原型，验证技术风险，通过真实的美术 资源确立美术风格，同时确立产品特性优先级，确定项目计划和资源计划。这一轮评审关键，是判断在GR1的基础上 所开发的产品雏形，是否符合预期，同时由各领域专家对项目的策划、美术、程序、计划等各方面进行深度诊断和分 析，给出专家意见。如果GR2顺利通过，意味着项目立项，将由HR发文，正式成立项目组。

3、项目组在GR3评审前，需要完成可验证核心玩法的试玩版本。试玩版本需要体现产品核心概念，并达到面向市场的 品质；完成量产工具和制作流程的准备；细化项目计划、资源计划，刷新后续工作量和CP计划。如果GR3通过，BG将 投入资源开始大规模量产。需要关注的是，产品立项和开始大规模量产属于IEG的重大业务决策，为了避免投入较多资 源后再推倒重来的情况发生，需要及早确认和验证技术风险，确保直接关系到产品核心特色、玩法亮点的开发目标能 被顺利达成。

4、接下来，将投入大量项目资源进行量产。项目组在此阶段要完成产品的全部开发，并逐步开启封测，通过用户反 馈，验证和打磨产品品质。如果GR4通过，进入Beta阶段，决定项目可以开启内测。

5、Beta阶段：项目组在此阶段进行反复内测，验证和打磨产品品质，进行上市前的最后Check。团队每月对产品运营 数据指标进行评测，在经过一段时间的内测后，项目组才可以申请进行GR5。GR5要看产品的各项数据，特别是有效 留存，将直接决定产品的定级，也决定了产品能获得的各项资源。如果GR5通过，意味着项目终于可以正式对外发 布，开启公测。

可是等这些都做完了，是不是市场机会也错过了…

腾讯高级副总裁马晓轶在接受《腾讯月刊》采访时说过：“我们观察过所有的项目，发现最浪费的时间是来回折腾。 为什么大量的项目花了很长时间，甚至三年五年？如果一个项目的开发时间超过了四年、五年，一定是在中间改变了 它的方向，就是做到一半觉得不行，这个方向看来是不对的，或者这个功能当初想得很好，但是发现技术上是不能实 现的，或者其实和其它的功能是有冲突、有矛盾的，没法做下去了，或者市场已经变了……最大的浪费是在这个点上。 所以，事先我们要求一定要先把文档写好，你的Concept（概念）是怎样的，你要做一个Prototype（原型）出来，你 的原型能够验证你的Concept（概念），你要做好最核心的Feature（特性），能够确保这些Feature技术上可实现， 拿出来也很好玩，我们才允许你做全面铺开的产品，看起来是浪费了很多时间，但是这样真的是减少了你后面反复的 时间。我们最怕的就是你拉了一百个人，做了一年之后发现这个功能看起来是有问题的，我们需要推掉重新来做，这 是最浪费时间的。看起来是前面浪费了很多时间，但这是为了后面不浪费时间，风险降低太多了，这点时间是值得 的。”

随着移动客户端APP、H5、小程序等产品新形态的涌现，IEG也推出了更加轻量化的流程规范，以匹配和适应新的产品 形态，但在它们背后，把控方向、控制资源投入以及预防风险的指导思想，始终是没有变的。产品评审流程的所有努 力，都是为了让“产品品质决定资源投入”这一原则深入人心，通过流程机制，倒逼团队更有动力打造精品、为用户 创造价值。

短周期产品：在不断试错中验证对用户的猜想

我们讨论了对于长周期产品，可以通过阶段性的评审把关，减少执行落地过程中的风险。那么对于短周期，或者已经 发布上线正在迭代优化中的产品，对应的需求应该怎么落地，以及如何检验我们所实现的需求，都满足了设计的初衷 呢？

用一句话回答：在不断试错中验证对用户的猜想。具体如何试错，这门课的第4讲《不断试错，校正需求》给出的四条 秘方，同样适用于这里，现在我们一起再来回顾下。

第一条秘方：引导发声。

产品策划之初，我们需要聆听用户心声；产品上线之后，我们更需要获取用户使用后的反馈，来验证曾经的想法，或 者发现新的问题。所以我们一定要创造足够多的渠道和通路，让用户更愿意、更简单地发声。

比如，在产品之外，组织用户群进行自由交流。
推荐大家使用1对1、或者3-5人的小群方式与用户交流，人少，沟通可以比较深入，也因为具有一定的私密性，用户会 更自然地吐露自己的心声。“听其言，观其行”，除了听用户怎么说，产品经理也可以邀请用户参加线下的体验活 动，现场观察真实的用户实际上是怎样使用产品，还可以使用眼动仪等专业设备来监测是什么吸引了用户的注意力， 用户在什么地方停留时间比较久，又在什么地方感到困惑，往往会有意料之外的发现。

又比如，在产品之内，设计契合用户场景的发声通路。
在产品中规划用户反馈意见的入口，应该是大家普遍的常识。但常常被忽略的是，在用户受阻场景中设计适合的发声 通道，比如在用户播放视频卡顿时，能出现播放异常反馈的入口，此时系统可以收集用户的网络环境、观看内容、故 障时间等，为故障判断做一定的参考；又比如在外卖订单中，我们可以看到一些「催单」功能的设计，当用户等待时 间过久，已经超出等待耐心时，可以让用户非常方便地表达诉求。这一类型的用户反馈，融入到细节的产品设计中， 既能让我们更容易定位问题，又可以在用户受阻路径中，帮助用户缓解和发泄受挫情绪。

第二条秘方：灰度策略。

灰度策略往往应用于新产品或新功能的尝试。通过向不同数量级的用户逐步开放，在过程中根据用户的反馈和行为数 据，来优化调整产品细节。

灰度策略一般有三种方式，可以应用于不同的场景。
1. 随机灰度。一般在发布适合全局用户的新功能或新特性时使用，也就是在全局用户中随机测试一批用户来观察效 果。

2. 定向灰度。它适用于在产品中根据细分群体去发布的一些新功能。就像前面课中讲到的QQ厘米秀的案例，就是巧妙 地对目标用户群进行灰度，从而推广创新产品。

3. 邀请灰度。它通常适用于一款新产品的诞生，并且具备一定的社交或社区属性。一方面，能在产品诞生之初，更加 聚焦于典型的种子用户群体；同时，还通过邀请码的方式，让用户形成自传播，为产品带来自增流量和口碑效应。

第三条秘方：善用实验

通过A/B Test实验，可以同时对不同的图片、标题、按钮、样式，甚至不同的业务分支逻辑等进行不断尝试，找到最 优解，通过数据驱动产品，帮助我们降低验证成本，快速达成共识，提升创新效率。

第四条秘方：关注异常

异常，意味着问题或机遇。对产品中的异常表现和异常数据，产品经理一定要保持足够的敏感度，它往往能够成为帮 助我们挖掘新需求的起点。

腾讯视频的产品经理就曾经发现一些不正常的播放数据，比如有些视频的播放完成度居然超过百分之一百，仔细分析 后才发现，绝大部分来自于动画片等少儿品类，原来是小朋友对一个内容喜欢重复观看；于是，团队针对少儿内容， 做了循环播放功能，方便家长为孩子进行设置，更好地满足小朋友的需求。

image.png

腾讯敏捷开发的目标，在于快速验证我们对于用户的猜想，不论是灰度、实验还是关注异常，这里共同的前提，是需 要保障关键数据的收集，在符合相关法规及保护好用户隐私的基础上，增加用户行为的监控埋点。用户所做的，往往 比他所说的，更能代表他的真实想法，我们可以通过用户的操作步骤，来分析他们的实际想法，不断打磨和完善我们 的产品。

需求落地最后一公里

讲完了长周期产品和短周期产品，在需求落地方面的注意事项。最后，我们聊聊在需求落地的过程中，除了要有流程 机制和方向性的保障，以及不断迭代的意识来验证和打磨需求外，在需求真正发布前，还有哪些准备工作需要做呢？

首先，要做好产品层面的准备，确保功能实现符合预期，并且没有明显影响用户体验的Bug。作为每天都有数亿用户 使用的产品，QQ在每次版本灰度之前，会组织一个Show Case体验会。在这个会上，QQ团队的GM（总经理）、总 监，还有产品、设计、开发、测试等同事会一起来体验新功能，看新功能有没有一些特别的体验问题、可用性问题。 同时，在发布之前，QQ会有各个角色的check list，由各个负责人进行最后的检查：产品经理确认是否都已经体验完 毕，开发人员确认代码Review是否都已经OK，测试人员确认是否还有严重Bug，设计负责人进行UI视觉的走查。当这 些检查全都结束，电子流走完了之后，QQ的新版本才会开始灰度发布。

其次，要做好技术层面的准备，做好性能和压力测试，根据新版本发布后可能的用户访问量、交易量，做好系统容量 评估，及时对服务器、带宽进行扩容，避免热情涌入的用户把系统压垮。

再次，要做好数据的准备，避免因为前端上报或后端统计报表的缺失，无法及时监控产品发布后的数据表现，给运营 和后续的优化造成被动局面。

最后，也是最容易被忽略的，要做好运营和传播方面的准备，需求发布前，准备好相关的公告及用户指引，提前与客 服、PR等同事沟通对齐新需求的内容及可能造成的影响，输出话术和FAQ提前应对，并在发布后密切关注用户的反 馈，以及各种媒体评论，避免用户投诉和舆论带来的风险。

总结

这一讲，我们分享的是需求应该怎样落地，以及如何检验我们实现的需求，是否满足设计的初衷。归纳起来，主要有 这么几个观点：

首先，对于长周期的产品，可以通过评审流程机制和阶段性的资源投入，降低来自产品方向调整和技术实现方面的风 险，避免来回折腾。

其次，对于短周期和迭代优化阶段的产品，需要关注用户反馈和系统异常，并通过灰度和实验，来验证我们对于用户 的猜想，不断打磨和完善体验。

最后，在需求正式发布前，要在产品、技术、数据、运营和传播等方面做好充分准备，避免因一时疏忽，造成团队的 努力“一夜回到解放前”。

今天这一讲，虽然标题是《需求落地最后一公里》，但其实，我们一直都不知道，什么时候是真正的最后一公里。产 品经理需要永远保持如履薄冰和求真务实的心态，把控节奏、把控质量、不断校正和还原用户真正的需求，在被用户 真正买账之前，在获得用户真正的认可之前，永远都是最后一公里。