本文主要内容分为四个部分：第一部分是分享我个人对产品和产品迭代的看法；第二部分会给大家分享为什么要坚持衡量每次产品的迭代；第三部分是本文的主题内容“如何做产品迭代的衡量”，会介绍我们摸索出来比较系统化的一套方法，通过数据来衡量迭代，最后会对整个分享的内容做一个小结。
一. 产品
什么是产品？这个问题我相信每个人可能都有自己的理解和自己的认知，就像1000个人眼中，就有1000个不同版本的哈姆雷特。个人认为：产品是一种标准化的问题解决方案。
产品是一种标准化的问题解决方案
所谓标准化的问题解决方案：
（1）产品是「解决方案」，要解决问题的。
作为产品经理实际上无时无刻不在想我们要解决用户的哪些问题，或者说用户到底痛在哪儿，痒在哪儿？然后我们产品提供的解决方案应该能够很好地把这个痛点、或者痒点给解决掉，这使我们产品的价值所在。
（2）产品还是一种「标准化」的解决方案。
举个例子，比如说若干年前贝尔发明了电话机，首先是解决了人与人之间远距离沟通问题。解决方案通过电话以及电话线，把人的声音从一个地方传输到另外一个地方，让另外一个人听到，这样人们就能通过电话进行远距离的沟通。
这里面的「标准化」包括两个方面：一方面是需求抽象，即把远距离沟通这个需求做了抽象，抽象成大家可以通过声音这个媒介来做远距离沟通，同时忽略掉无关之外的其他四个感官；第二个方面是解决方案的标准化，将声音的跨距离传输用以下技术方案加以解决：用一根电话线，把两个地方的两部电话机连起来。其中一部电话机采集声音，把声音转化成电信号，通过电话线传输到另外一部电话机上，再利用听筒把电信号还原成声音。通过这样一个标准化的解决方案，满足了整个远距离沟通的需求。
以上例子是标准化的问题解决方案。这也是我对产品的一个观念——任何产品都是某一个或多个问题的解决方案，并且这种问题的解决方案经过抽象、标准化的一种解决方案。
产品还是一种商业模式
除此，产品还是一种商业模式。作为一种商业模式，很重要的一个点是要可复制、可规模化。谈到商业，中国有一句古话叫“在商言商”。我们从商业的角度看产品，不可能随便做一个东西，就能够叫产品。公司的发展中起到关键作用，需要通过商业模式从顾客手中获取现金收益，为公司的生存和发展提供资金支持。商业模式中很重要的两点是要可复制和可规模化。
到这儿，有的人可能会有疑问：
用户体验去哪儿了？
在我个人看来，用户体验是很重要的一件事，但是和前面两个方面相比，用户体验更像是锦上添花。用户体验是商业模式中的可复制、可规模化的构成要素之一。如果单单看用户体验，实际上它并没有那么重要，中国有句古话：
皮之不存，毛将焉附。
脱离了解决问题，脱离了商业，单独只提用户体验的话，是站不住脚的。当然用户体验非常重要，是我们每个产品经理和设计师，以及产品线上的每个人需要努力去做的，但是要放在整个商业模式中去看。
在我看来，产品开发是一种过程，这个过程的目的是为了寻找和发现三样东西：
要解决什么问题；
用什么样的解决方案去解决这个问题；
寻求商业上的成功，要可复制、可规模化，能够为公司带来预期的收益。
截止目前，大部分互联网产品采取的产品开发方式是用迭代这种方式去做的。
之所以迭代开发被广泛采用，个人认为是因为产品开发是一件高风险的事情，而迭代的开发方式，能够帮助我们把失败风险控制到一个合理的范围内。我们可以投入比较小的成本，尽快地获取到用户的一些反馈，来验证我们的产品是否符合市场需求。如果符合，就坚持往下走，探索新的方式。第二个是迭代的方式能够帮助我们加速整个产品开发过程。所谓加速是让我们找到合适的问题、合适的解决方案和缩短商业上的探索周期。
三. 为什么要做产品衡量
对于互联网公司，尤其是创业公司来说，每一天都面临着生存压力。对于大公司，要考虑公司怎么样长远地活下去，能够在这个市场上取得一个更好的成果？以小公司为例，生死线是什么呢？在投资人的钱花光之前，达到产品-市场契合点（产品-市场契合点，描述的是一种状态，在这个状态下，产品的用户可能很快的增长，如果没有达到产品-市场的契合点，之前需要做很多的探索工作）。
大家回想一下，中学、大学做过的实验，很重要的一个环节就是验证试验结果。对于产品迭代，我们也同样需要关注每一轮实验（迭代）的结果是否达到我们的预期。但是，产品团队以及研发团队，因为进度压力比较大，很多时候可能会无意的去规避掉验证的环节，这时很不应该的。
分享两个数据：一个来自微软，一个来自亚马逊。
在微软团队内部公认比较OK的想法，真正实施以后：大约有三分之一起到了预期效果，三分之一的想法没有产生明显影响，还有三分之一反而会起到了负作用。亚马逊大约有60%到90%的想法，是无法改善他们的产品的。所以，关于产品验证环节上，大家不要过于盲目自信，应该从扭曲力场中回到现实了。
大家知道我们产品经理有一个很重要的能力，就是把现实扭曲成一个我们想象的样子。当然这不是一个坏事，产品经理如果没有这个能力的话，是无法做好产品的。我们必须首先在头脑中将未来的现实世界扭曲成我们相信的样子，并以此为基础构建出整套的解决方案，才能够产出产品设计稿，最终才能交给产品的研发团队去做。如果没有这个能力，没有这个想像力，实际上是做不了产品的。
但是，如果只是盲目地沉浸在自己的世界里不走出来的话，就会害掉我们。所以，这时候做产品会分阶段来，在想方案、研究问题、做事情的这一阶段，我们要充分利用我们现实扭曲的这种能力，但是真正等发版上线这个事情做出来以后，我们要回到现实看一看数据到底是怎么样的。所以，坚持对每次迭代做衡量，来验证我们的想法。
四. 如何衡量产品迭代？
关于如何衡量，我们做过调研，很多优秀的团队，都在坚持做这个事。大家在日常的工作中，也都有一些自己的这种心得，也都总结出来了一些方法。那么我们是和很多团队一起去研究，沟通了以后，我们也是总结了一套相对全面一点的方法。这个方法的核心是拷问我们五个问题，然后通过数据回答。这套方法，能够让我们比较全面的衡量每次改版的真实效果。
这五个问题是：
新功能（或改进的功能）是否足够受用户欢迎？
用户是否会重复使用我们新功能（或改进的功能）？
这次迭代对对用户留存的整体影响如何？
如果改版是为了优化某个使用流程，那么这个流程的转化率是否得到了提升？
深入了解用户到底在如何使用我们的产品，以及改进的（或新增的）功能？
在正式讲衡量方法之前，简单分享一些基本数据方面的概念。如果我们的产品经理之前完全不懂数据衡量的话，那么首先需要了解一些数据指标。
如果把地球看成一个APP，用户就好比地球上的人。每年出生1.4亿人，目前70亿人活在世界上，已经累计死去1080亿人。其中出生人数就像是新增用户，现存70亿人口等同于活跃，累计死去的人意味着流失，“人活七十古来稀”的概念与留存周期类似，人们生育繁衍又与产品的口碑传播很像。这样，我们可以一一对应这些用户生命周期中的概念：新增（Acquisition）、活跃（Activation）、留存（Retention）、传播（Refer）等，对于互联网产品而言，还有一个商业变现（Revenue）的环节。这五个环节，就构成了我们常说的AARRR用户生命周期模型。
1. 新功能（或改进的功能）是否足够受用户欢迎？
关于迭代衡量系统的方法，首先要考虑新功能是否受欢迎。产品发版以后，这个版本的活跃用户数如何？发版后的一些新功能是否受欢迎？如果用一个指标概括，这个指标叫功能活跃比（使用某个功能的活跃用户占同期活跃用户数的一个比例），这个指标是能够反应新功能是否受欢迎，不能从这一个面去看，仅仅从这一个面衡量是不足的。
2. 用户是否会重复使用我们新功能（或改进的功能）？
第二个方面，是看新用户是否会重复使用，假设这个产品经理长袖善舞，通过各种手段让用户尽可能导到新功能上去。如果用户用起来不爽的话，第一天导过去用了，第二天再导过去用了，第三天发现这个产品有bug，体验也不好，用户就不用了。不用了代表用户同步使用率会下降。但是真正要落实到数据上去衡量的时候，同步使用率是比较难衡量的。因为用户会有流失，因此重复使用率要和留存以及活跃比放在一起去看，才能够得到一个才相对客观结果。
3. 这次迭代对对用户留存的整体影响如何？
第三个方面是新版本对留存的影响。那么这个一般目前主流的这种产品数据分析，或者用户行为数据分析的平台，实际上都有相应的模式和相应的功能都直接看。
从留存的方面去看，如图，红线是两个版本的分界线，红线以下是老版本，红线以上是新版本了。上线新版本后，发现用户的留存率有明显的提升。说明改版提升了用户留存。如果没有变化，或者留存率下降，则说明没有达到我们预期的效果。
4. 如果改版是为了优化某个使用流程，那么这个流程的转化率是否得到了提升？
接下来需要看转化率是否提升了。例如一个内容类产品，会发布UGC或者PGC内容，可以是文章、图片或者是视频。我们的预期是用户看着觉得好并会分享到其他的社交平台上去，通过查看从阅读到分享再到分享完成三个步骤，比较分析改版之后转化率是否有提升。如果没有提升，则需要我们去找背后的原因。
5. 深入了解用户到底在如何使用我们的产品，以及改进的（或新增的）功能？
最后，如果你的老板找你要产品改版结果，给他看用户留存率以及转化率这些数据也就够了，但是对于我们产品经理来说，还需要进一步多去挖掘一些数据，以便我们知道后面版本的这个迭代需要从哪几个方面深入？首要关注的是什么？已经发布的或者是改善的功能，它的使用情况到底如何？可以从活跃、留存率两方面去进行拆分。再进一步，我们还需要去关注什么呢？比如说用户在打开应用的时候，都干了什么。如果版本改动比较大，用户进入应用以后做的事，是否发生一些变化？我们需要把改版之前的一个时间段和改版之后的一个时间段做一个对比，对比主要是找差异。如果改版前后差别不大是一种情况，如果改版前后发生了一些变化，这个变化是否是我们预期的，是需要去分析的。
除了打开应用之后做了什么，还需要分析的是用户在离开应用之前做了什么，也就是说用户是在哪一个环节结束了应用的使用。这样，往往能发现一些问题。比如说一个web产品，用户通过搜索引擎到首页，然后就结束了。这时候，需要我们从产品的角度去分析，看看在首页文案的引导，按钮的摆放，颜色、布局等方面，是否需要进一步优化。
最后就是要对迭代改进的功能或者新增的功能进行重点关注。做法是看用户在使用改善后的功能之前都做了什么，是从哪儿来的。另外用了这个功能以后，又做了什么。也就是把这个功能放在用户的使用场景或者放在用户的使用路径中，来了解用户的来龙去脉。
到此为止，我们需要从大的统计指标上去看一下整体改版的整体情况。包括用户在使用功能的一些整体表现，作为产品经理，做到这一步，依旧不够。我们还要进一步查看用户的整个使用路径。说到这儿实际上在以前讲产品数据分析方面的时候，实际上我有点不太好意思讲这个的。因为我觉得这个事看起来有点LOW，要一个一个查看用户的使用的路径，看看他第一步做什么，第二步做什么，我觉得这个事看起来有点LOW的，所以有点不太好意思讲。
直到后来碰到一些来自百度的产品经理，他们就提到在日常的工作中，很重要的一个部分就是查看用户使用路径，甚至会定出计划来。比如说圈定100个用户，可能花上一周或者两周的时间，把100个用户的使用情况查看一遍，制定相应计划。通过这种方式，很大程度上能够弥补我们对用户的认知不足。
到这儿，我们对整套方法做一个简单的回顾。刚才讲到：如果想利用数据来做好产品迭代的衡量，需要看：新功能是否受欢迎；用户是否愿意重复的使用，这两个分别对应的是产品的功能活跃比和重复使用率；第三个要发现新版本对留存是否产生影响，是否按照我们的预期提高了产品转化率；第四是需要深入地了解用户到底在如何使用我们的产品，包括行为路径统计信息以及对个别用户详细使用记录的查
以我个人的经验，如果大家能够按照这套方法进行每次产品的迭代衡量，第一你很可能会发现很多改版并没有按预期那样产生足够积极的效果。第二，对于每次迭代，你如果按照这些方法做一些分析，可能会从中间总结出一些很重要的认知和经验。
五. 总结
回顾一下，本文主要讲了三个方面的问题，第一个分享了我个人对产品和产品迭代的一些认识以及一些看法。第二个是从我个人对产品的一个认知引出了我个人认为为什么要做产品迭代。无论是对公司，还是产品经理个人的职业生涯，未来预期是一个比较好的发展。第三个方面和大家分享了产品改版衡量的一套系统化的方法。那么基本上是靠回答这几个问题，来拷问我们改版衡量的效果到底如何。
