什么是价值？精益的思维方式把价值定义为“向顾客提供利益”，除此之外的任何东西都是浪费。

如果能发现和定义什么是有价值的，并能快速交付价值，产品也许就能在竞争中有更多选择。

竞争

易盾是网易从邮件反垃圾开始，积累了19年之后推出来的一个SaaS产品，主要是解决内容审核的问题。传统的内容审核通过人工标注，但是发垃圾的黑灰产不断升级自动化之后，无论从垃圾量还是24小时的发垃圾的频率上，只是通过人工审核已经无法支撑内容审核的要求，人工智能审核的介入就变成更好地选项。而这块的市场市刚需，内容一旦出现问题可能会被拔网线，原因可能是色情，可能是政治相关。

人工智能现在是风口，而且这个领域网易在技术和产品上有优势，并且门槛高，竞争对手少。同时的风险是，竞争对手都不弱而且各有优势。有利用自家云平台的规模优势的，有利用自家产品行业领域优势的，有利用低价策略的，有利用产品差异化的。我们一直以为只要在技术上有优势，我们就可以胜出，直到有一天，我们发现多个竞争对手的官网上产品组合抄了我们，竞争对手在低价倾销，竞争对手的的效果提升了。

我们紧张了。

我们需要更快更多地找到对用户有价值的功能，需要尽快推向市场，需要不断提升技术，这样才能继续领先。

如何发现和定义价值？

一般情况下，我们尝试通过各种方式建立一套可持续地商业模式，通过这种商业模式建立产品和服务，然后推向市场。如果市场反馈不好，我们就尝试花更多时间认真地评估我们的商业模式，然后重新推向市场。问题是：要是还不行呢？继续增加研究需求的时间？总觉得哪里不对。

我们花了很多时间在争论我们应该做什么上面，我们甚至也花了很多时间裁剪我们的需求，把需求变得小一点，分步推向市场，可是这样够了吗？需求池里面依然有大量的需求堆积着，我们花大量的时间调整优先级，研发资源总是不够用，市场依然反馈平平，负责人觉得团队不够努力应该996，研发团队努力提升质量憋屈地开发了一堆卖得一般的功能。客户到底要什么呢？

我们如何找到客户到底要什么？花费我们大量时间的应该做什么的争论是有益的，但是无论花多长时间争论，用户的反馈才能验证结果，如果我们能更多更快的验证结果，也许就能更快地找到价值所在。

《精益创业》中提出了“开发——测量——认知”的循环，首先做出假设，然后为验证假设开发一个MVP，定义好这个MVP的验证方式，然后投入市场进行测量，获取测量的数据，然后确认假设是否正确，研究是否有其他发现，依据这些结果调整策略，然后进行下一个假设，接着重新开始循环。

如果我们能减少这个循环的成本，加速循环的过程，我们就能尽快地找的对于用户有价值的假设，从而找到对的方向，做对的事情，更快地做。

影响SaaS产品的三个因素：成本，收入，增长

收入大于成本，可能就盈利了，如果还能快速增长，那就完美了。那什么影响了成本，什么影响了收入，增长指的是什么？

收入

收入 = LTV * 客户数量

如果我们可以增加LTV和客户数量，就可以扩大收入。

LTV=ARPU x单个客户的平均生命周期 – 服务客户的成本

影响LTV的因素有ARPU，单个客户的平均生命周期和服务客户的成本，如果我们能够增加ARPU和客户的生命周期，同时降低服务客户的成本，我们就可以提高LTV。

ARPU是每月每个客户带来的平均收入。SaaS产品，客户带来的平均收入跟客户的消耗额正相关，客户数量越多，消耗额可能就越接近销售额，消耗额跟用户的数据量和产品的价格正相关，客户消耗的资源越多，产品的价格越高，客户带来的消耗额越高，客户带来的ARPU也就越高。同时，如果消耗额和客户的业务总量是正相关的，SaaS产品对客户的粘性也会加强，对于降低流失率也有帮助。

客户数量 = 引入的潜在客户数 * 销售转化率

我们如果能够提高引入的潜在客户数量和销售转化率，就可以提升客户数量。

成本

成本 = CAC + 研发成本 + 一般性成本 + 售后支出

如果能降低这四个因素，就可以降低成本。

CAC=（销售与营销的总成本 + 定制成本）/客户数量

影响CAC的因素有销售成本，市场成本，或者现在我们可能会遇到的大客户的定制成本（这里特意列出定制成本，是因为为了满足每个大客户的各种需求而维护多个版本，或者让客户的这些需求互相融合，需要付出的成本很值得重视，成本会随着客户的数量几何级数的增长），但是这么算实在太麻烦也很难区分哪些能算CAC，哪些不能算，因此就简单用这个方式来计算就好了。如果能降低总的销售与营销成本和定制成本，同时提高客户数，CAC就可以降低。

售后支出 = （故障赔偿金额 + 故障维护成本）* 故障数量

研发成本和一般性成本的增长都还是线性或者可控的，在这里就跳过，直接来看售后支出吧。

故障赔偿金额跟我们承诺给客户的赔偿金额和故障的严重程度有关，故障维护成本和我们的服务效率有关，服务效率又和产品和团队的成熟度有关，故障数量和故障严重程度跟我们产品的质量有关，而质量也跟产品和团队的成熟有关。这个成熟度包括团队的产品的生命周期，服务流程，开发流程，各种规范，团队成员的经验，团队的配合程度，等等。

因此我们要减小售后支出，可能需要在团队的整体能力上有所提升，从而提高产品质量和服务效率，而不只是团队成员的数量上的增长。成员数量上的提升可以降低业务快速推进带来的质量和效率上的妥协，但是同时也会带来整体协作和平均个人能力的下降，因此也是一把双刃剑。

除了CAC，其他成本的占比会随着客户数量的增加而减少，当LTV > CAC，就可以把LTV - CAC的盈余继续投入市场和销售，不断增加客户数量，形成一个正向循环。LTV-CAC的盈余越多，有可能带来的增长也就越多（当然也会遇到增加投入，但是客户增长并没有变多的情况，这时候可能就需要考虑换方向了）。反之，如果LTV < CAC，那么就需要尽快摆脱这种局面，否则即使有外部投资，也无法让亏损收敛，我们期待的LTV和CAC的关系应该如下图：

增长

增长 = 订单增长量 * 订单单价 + 新增产品销售额

新产品有助于销售的拉动，但是在新产品上的投入可能会降低在原有优势产品上的投入，原有产品又需要持续强化和升级来扩大优势提升订单单价，增加销售和营销投入来增加订单量，但是也不可能持续提高销售和营销成本和研发成本，这样总成本就没法降低，因此资源的优先投放始终会是一个核心问题。

我们重新审视一下影响收入，成本和增长的这些因素：

我们要提高：

客户平均消耗额

单个客户的平均生命周期

引入的潜在客户数量

销售转化率

团队成熟度

订单增长量

新增产品

我们要降低

服务客户的成本

销售和营销的总成本

定制成本

研发成本

一般性成本

增加引入的客户数量和销售转化率，就会增加客户数量，持续提高就会提高订单增长量，而增长是判断我们的战略是否正确的重要指标，因此这两点极为重要。

我们需要不停地尝试，通过观测上面的这些因素，来找到对的战略。

作为网易这样的一家大公司，我们的产品化之路常常是由于我们有某个领域的技术积累，积累到了一定时候，尝试着推向市场，在技术上我们比一般的创业公司有优势，但是劣势也是在于我们不能像一般的创业公司那样随意地调整产品。一方面，我们的产品需要对内支撑内部产品，另外一方面又需要对外满足外部市场多变的需求。因此，这些指标的观测也应该融入对内支撑的部分。

建立“开发——测量——认知”的循环

为了更快地寻找到价值，需要在原有团队运行模式的基础上进行改变，逐渐形成“开发——测量——认知”的循环，首先需要建立数据反馈机制，然后需要建立形成认知循环的组织能力，然后分析结果调整假设，让循环运行起来。

建立数据反馈

建立同期群数据反馈

定价体系也决定了同期群的统计方式，客户付费方式可能包含：

包月

包年

包量

按使用量扣费

加上开发周期和toB产品反馈传递的延迟，同期群的建立可以以月为单位，每个月进行比较，来判断之前的策略是否起到了作用（笔者也在尝试以半月为单位进行比较，但这需要缩短反馈周期，产品设计周期和开发周期，这些还需要一些条件和时间的积累，需要团队成熟度的提升）

根据前面对SaaS产品影响因素的分析，我们需要非常关注的几个指标，我们每个月依据这些指标来判断我们的健康程度：

客户平均消耗额：

如果客户平均消耗额的增长达不到预期，我们就需要思考如何提升，是要改变定价策略，还是提供更多的产品服务来提升用户的消耗，客户是否把他的数据都放入我们的服务，客户是否还有什么顾虑的方面，我们提供的服务是否有让客户不满意的地方。

客户平均生命周期

如果客户平均生命周期低于预期，我们应该关注每个月转化的客户数是否大于每个月流失的客户数，我们的产品和服务是否有什么问题，产品的质量是不是有什么比较大的问题，是否有某个行业发生了重大的变化导致某一类的客户流失得比较厉害，我们是不是需要开拓新的行业。

引入的潜在客户数

引入的潜在客户数是否有增长，如果没有增长我们就需要考虑是否增加市场的投入，如果增加了市场的投入依然看不到增长，我们就需要考虑是否采用了合适的市场策略，是否找了符合我们产品的用户，还是我们选择的目标客户其实并不多，还是我们的产品需要转型。

销售转化率

销售转化率是否有提升，如果没有提升甚至下降，我们就应该关注销售团队和产品团队是否有比较好的配合，是否得到了足够的支持来提升销售转化率，销售团队的人手是否充足，是否是由于引入的客户数量变多导致销售团队来不及处理导致的。

客户数增长

如果客户数的增长少于预期，我们就需要关注前面的4个指标，是否有哪个指标不符合我们的预期。客户的增长从一定程度上反应了我们是否真的找到符合市场需求的产品方向，我们的假设是否成立。笔者在一个活动中问《精益数据分析》的作者，一般应该有多少的增长，得到的回答是：每周5%的增长。也许ToB产品的影响因素更多，但是每周5%的增长也许是一个不错的参考。

销售和营销的总成本

在定制成本还没有的时候需要关注总收益是否大于销售和营销的总成本，从而关注LTV是否大于CAC，如果CAC过大，就要仔细检查市场和销售的投入产出比是否合理，研究当前的模式是否有问题，当初的假设是不是验证失败，需要尽快调整策略让LTV大于CAC，这样才有可能持续下去，否则获客越多亏损越多。有一个参考是David Skok（在一家名为Matrix Partner的投资公司从事风险投资工作，观点源自几位来自不同SaaS公司的CEO和管理层）提到的客户全生命周期价值（LTV）要大于3倍以上的CAC。

每一项指标增长或者减少，我们都需要尽可能找到背后的原因，找到因果关系，这样才有助于我们做下一个决策或者假设。

建立用户体验数据反馈

我们常常会对网站的页面进行改版和优化，因此需要建立每次修改之后的实际效果反馈。以下几个指标也是我们需要经常关注，尤其是在改版之后需要重点关注的：

注册转化率

毋庸置疑，最重要的就是为了这个

落地页的跳出率

跳出率升高，改版可能就存在问题

页面停留时长

停留时长并不是越长越好，toB产品主要目的是为了节省使用者的时间。但是太短肯定是有问题的，比如页面上存在Bug，比如页面被某些人刷了，笔者就遇到过几个IP近1000的页面访问，页面平均停留时长不足2秒。

热点图

新增加的功能和按钮是否真的有人使用，用户关注和常用的功能有哪些，是否可以考虑换一下位置。

浏览器分布

不同浏览器的兼容和覆盖会占据不小的资源，因此依据这个数据进行取舍也许是不错的选择。

页面的下游页面

看用户的操作路径是否符合我们的设想

当然还有很多，比如来源渠道，搜索关键词，PV，UV等等。

打通用户反馈渠道

用户反馈是我们调整产品最重要的依据，根据用户的阶段和我们的工作环节我们需要打通以下的几个反馈

打通售前和销售阶段的用户反馈

售前和销售阶段的用户反馈不能只是停留在销售团队内部，应该能够比较全面和原生态地反映到产品一侧，通过建立一个统一的需求池和定期地向销售收集用户反馈，通过建立IM群的方式，让研发，产品，运营在销售和售前阶段就能够了解用户的真实情况，甚至提供来自产品侧的问题解答。

打通产品阶段的用户反馈

产品不能闭门造车，需要和销售一起拜访客户，或者和关系比较好的客户进行一些深度访谈，这样能够比较深入地了解用户的痛点和需求。在产品设计和规划上会更有依据。

打通运营阶段的用户反馈

用户接入产品之后，运营的同事就会响应用户的各种使用过程中的需求，这些需求也应该像新增的产品需求一样对待，统一放入需求池，和其他功能一样一起进行优先级的排列。

设计组织能力

把问题分层，依据不同角色的职责，拥有的信息量，专长的方面，把“开发——测量——认知”循环的过程分解到不同层级的组织角色上，同时保证在横向上的同步

战略层：由各部门总监组成，需要解决方向的问题，做出假设，定出优先级，分析反馈结果，最后调整策略。

管理层：由各部门主管组成，需要解决资源分配的问题，依据战略层定下的假设和优先级分配资源，执行验证并收集反馈结果。

执行层：由各个虚拟团队组成，需要解决快速交付的问题，依据管理层分配好的资源和任务，快速地完成任务得到结果，每个虚拟团队组成

加速“开发——测量——认知”的循环

建立合适的迭代周期

迭代周期能够控制反馈的频率，一个迭代就是一次反馈的机会，找到合适的迭代周期很重要。

大的迭代意味着更多的工作内容，更多的返工，更多的问题，更多的干扰，这些更多会随着迭代周期的变长而快速上升，而且会因为一个小的问题而延迟所有的部分：团队做了ABC三个功能一起上线，却因为C功能的一个问题，导致已完成的AB得一起等着。

小的迭代带来的好处就是能够尽早地发现问题，减少已经完成但是没有交付的价值，但是太小的迭代有可能还不足以让问题暴露出来。

以下的这些周期是根据笔者团队的情况逐渐调整出来的：

战略层的迭代周期：双周为单位，即使这样，1年也只有27次的反馈和调整的机会。

管理层的迭代周期：以周为单位，每周反馈，调整和同步。

执行层的迭代周期：以周为单位，让工作内容尽可能在一周之内可以交付，一方面笔者做过统计，团队1周完成的任务比2周甚至以上的任务效率更高，Bug也更少，另外一方面，也强迫团队把任务尽可能地拆小成1周能独立上线。现在由于有持续部署的存在，理论上来说，每一个小的改动都可以持续地发布和部署，这方面笔者还在学习和思考如何让持续部署能够落地，现在Devops的热门程度已经足以吸引世界各大互联网公司，如果能够解决持续部署的问题，执行层的效率会有极大的提升。

建立分析根源问题的文化

依据数据分析，发现了问题，就需要对问题进行分析，常见的就是5Why方法，通过问为什么，来找到问题的最根源，定位到是什么导致了数据的变化。通过处理根源问题来真的影响到数据的变化。还有其他的工具，比如鱼骨图，可以和5why的工具一同用起来。

比如线上Bug就是典型的需要进行5Why分析的案例，通过5Why分析，我们找到线上Bug产生的根源问题，分析的目的不只是为了找到技术上的问题，也是为了找到流程的问题：

是什么导致了这个Bug？我们的账号过期了

为什么我们的账号过期了而我们没有准备？因为我们之前和其他团队提过，以为其他团队就接手了。

为什么其他团队接手了最后还会导致这个问题？因为他们忘记了

为什么他们忘记了我们没有发现？因为我们上线前没有检查，我们的软件系统也没有自动检测的功能

为什么我们上线前没有检查，我们的软件系统也没有自动检测的功能？因为我们没有上线检查这个流程，也不清楚哪些需要检查，我们的系统也没有这个账号的检查机制。

OK，到这里，我们就可以做一点事情了。

每发现和解决一个根源问题，团队就会获得成长，团队成熟度就会提升，效率就会提高，一旦组织形成了这种寻找根源问题的文化，组织就能够从错误不断地学习和完善，团队就能够自我适应各种情况。

提升执行层的演进

执行层是最终实现产出的层级，这一层的效率会影响产出的效率。

研究型团队和工程团队的协同

研究型团队对于研究结果是很难承诺的，人工智能有很大一部分较难做出承诺和计划的，因此对产出结果负责的工程团队相比就会很不同。但是工程和研究又需要同步起来，咋办？

工程和研究之间尽可能做分离，保持低耦合和独立演进的能力，在做同步的时候以同步接口为主，研究团队需要配合工程团队的迭代节奏完成接口的提供，但是接口之后的实现可以独立演进。同时，研究的演进也需要有所控制，这种控制是对节奏的控制，如果结果不可控就应该控制AB测试或者Demo的频率。AB测试和Demo的频率也可以像工程团队一样以周为单位。

各角色协作的提升

需求从需求加工阶段到交互设计，到视觉设计，再到开发测试，最后上线，中间经过很多阶段，在确定了各个阶段或者角色的资源情况之后，需要确定合适的同步模式。笔者的团队经过了5次改进演变成了下面这种模式：

提升研发团队的工程能力

团队的工程能力的提升会极大地加速循环的提升。软件的Bug发现的越早，为解决Bug花费的时间和成本就越低。笔者和ode-e的专家交流的时候也讨论到产品间最后的竞争可能会落到团队的工程能力的提升上。

下面的这些工程工具可以很好地帮助团队提升工程能力：

UT和软件静态检查工具：可以让软件的Bug在编译阶段就可以被发现。UT和静态检查工具大家都知道，可是真用起来比较难，开发的同学大多都不喜欢写UT，静态检查工具的结果也常常没有人关注，这里就需要首先在CI上建立起来一个数据反馈的功能，让UT的覆盖率，代码的复杂度和静态检查的结果都展现出来，然后规定新增代码必须增加UT和处理静态检查结果，对于原有代码中静态检查结果位critical的，必须处理。

CI的使用：可以让团队更多地提交代码，更快地获得反馈，更早地发现问题而不是等到最后全都完成了才做集成和发现Bug。问题在于自动化测试用例覆盖率的提升，第一步需要做的就是把自动化测试用例的添加变成Task进入项目计划，然后对所有对内和对外的接口进行覆盖，新增的接口和功能必须自动化用例覆盖。然后就需要制定CI的流程，CI在初期执行的时候为了让团队适应，并且一般代码checkin发生在下班前，所以运行时间定在每天晚上跑10次，如果失败，多位相应提交代码的同事就会收到邮件，第二天收到邮件的同事就需要第一时间处理让CI通过。

Review：最方便的在团队内部互相学习提升的方式，同时可以尽可能地让问题早点被发现。笔者团队之前的Review通常就是在Gitlab上看看，口头给一些反馈，从0.5到1需要建立Review工具，团队用了Review Board，来记录Review的结果和确认review完成。

高效创新组织的设想

通过减小团队规模和增加团队数量来增加试错的机会和提升组织效率，通过测试团队来保证质量，另外一方面通过一个评估委员会来做一些宏观调控。通过让创新团队对自己的产品和功能负责，提升团队的效能和创造性。

为了保证原有产品的持续演进和对内支撑，继续保持一支团队或者一组团队维护

建立小型的创新团队，每个团队由4名开发和一名产品经理组成，团队负责开发新的产品和功能，并且自己负责完备的功能测试。

新产品的创意需要向战略评估委员会提出并包含验证策略，由委员会进行可行性评估，但委员的主要任务是让小团队能够自主高效地运行，应该尽可能少地干预这些创意。

战略评估委员会还负责需求池里的优先级排列。

测试团队主要负责测试工具的提升，持续交付系统的维护和探索性测试。

上线评估由测试团队和产品团队出具测试数据，战略评估委员会确认上线，这步在完善了持续部署之后可以考虑取消。

创新团队不一定都要全都自己想创意，有很大一部分工作是完成需求池里面优先级最高的需求。

总结

精益的核心是要消除浪费，所有对用户没有价值的工作都是浪费。史玉柱曾说：“一个企业付出最大的成本、最大的浪费并不在于他的实际操作，实际上决策失误所付出的代价是最高的。”柳传志也说：“做正确的事，比把事做正确更重要”。虽然我们不能做到完全没有浪费，但是我们应该用更少的代价更快地找到用户的价值，用更快的速度交付价值来减少浪费。探究如何获得产品的成功也是一门科学，我们要做的不只是建立精益的思想，而是建立精益的组织，从而帮助产品的成功。精益没有完美状态，现在的模式也只是适合于当下，我们需要通过持续改进来不断地解决新的问题。