目录
还首先还是上产品驱动增长的公式：增长=需求×方案×共识×体验×场域×效率×口碑×流量，篇幅问题，这篇我们讲最后两个，分别是口碑和流量
一、口碑
所谓口碑就是用户如何向其他用户介绍我们的产品。这里的用户不一定是真正使用我们产品的用户，包括所有了解我们产品的人。这些人就包括认同我们产品的用户，对我们产品不关心的用户，以及对我们产品不满意甚至退款的用户。那么谁会更好地将我们的产品介绍给其他用户呢？有人可能会讲，肯定是第一种了！事实可能并不如此，第一种可能给别人介绍我们的产品可能与我们的方案相反，而第三种也很有可能如实地介绍了我们的方案，要了解这个问题，首先要了解谁是核心用户。
1.1谁是核心用户
那么谁是我们的核心用户呢？花钱最多的大客户？到处夸我们产品的用户？行业专家？都不是！按照李睿的说法是：核心用户的标准是：愿意说且能说对我们产品的解决方案的人。注意，是人，没有购买也可以。
举个例子，在国内证券IT行业最近几年兴起分布式架构的交易系统。某H公司是这种建构的倡导者，公司的所有产品都基于分布式架构开发。某个该行业的大佬以行业资深专家自居，总要跟最新的行业潮流，于是也开始研究分布式架构并各种场合鼓吹，他要拿示例出来支撑自己的论点，可自己又没做出在市场上有影响力的产品，此时就只能拿H公司来举例了，那么这个大佬也算H公司的核心用户了。H公司就应该跟该大佬深入交流，将自己分布式的理念和架构实现的优势大方地告诉这个大佬，让他能更准确地说出该公司产品的解决方案。
1.2怎么让转介绍有效
既然让人介绍我们的产品，那是不是介绍的人越多越好呢？当然多比少好，但更重要的是的介绍要有效？那什么才是有效的呢？答案是：基于正确的解决方案的介绍才是有效的。
还是举交易系统这个例子，最重要的一条解决方案是：采用分布式的架构，提高系统稳定性和可扩展性。现在有用户A和用户B，分别这样介绍。A一直在用该产品，跟其他券商的潜在用户说，“G公司挺不错的，我们使用中不管遇到多少问题，他们都能很短时间内发版本解决。”用户B的公司也让G公司做过投标，但是最终没使用，原因是“他们用了分布式的架构，为了保证系统的稳定性和可扩展性，需要很多服务器，我们公司没那么多服务器的预算”。虽然A用了该产品，B没有用，但B的转介绍是有效的，因为正确的转介绍了这个产品的解决方案，某个潜在客户很可能为了系统的稳定性不在乎服务器的多少，于是选择了这个产品。而A用户的转介绍，很可能给别人一种印象“这公司的产品质量可能不行，需要频繁发版本解决问题”
1.3转介绍活动怎么做
那我们要怎么做转介绍活动呢？ 这个其实我们前面几个活动一直在做准备，需求、方案、共识、体验、场域、效率一直做得好，那么有效的转介绍就水到渠成了。
所以尽量不要让用户用自己的理解去转介绍我们的产品，而是直接用我们的解决方案去做介绍。
1.4怎么避免负面口碑
前面说的基本上都是认可我们产品的用户，只要保证跟用户的接触都正确地宣传了我们的解决方案，拉动正面的口碑应该不难。如果碰到用户退款，是不是就一定会是负面口碑呢？其实不一定，我们是可以避免负面口碑的。
退款一般包括两种，一种是被忽悠进来的，说的功能没有实现。例如前面说的交易系统，解决方案是采用分布式架构，可分布式架构的一个前提是需要的服务器比较多。但是销售为了拿单，应标的时候将所需服务器数量降到必备服务器数量之下。中标后做实施时用户才发现，按照招标书上服务器的数量系统根本部署不起来。碰到这种情况，用户就会非常不满，很可能合同都不会付尾款了。这个属于过度承诺。
另外一种是，购买的时候解决方案达成共识了，但买了后想法变了，或产品还不够完善，承诺没兑现。这种情况用户可能还会回头的。例如用户想要一个高效稳定的交易引擎的交易系统，也非常认可分布式的架构可以实现这个需求，G公司的产品架构没有问题，但是业务还不够完善，功能也还有一些瑕疵。用户使用的过程中也还是有很多不满，但是总体的共识在，使用过程中有其他问题，只要解决问题的态度诚恳，而且系统越做越好，用户传播产品的负面口碑。
二、流量
互联网兴起后，大家都非常关注流量，有了流量就相当于有了矿，只要挖下去，总能赚到钱。但产品所处的阶段不一样，对与流量的要求是不同的，产品阶段要和流量匹配，如果不匹配，产品可能会被流量淹没，从而早早结束了自己的生命。
产品一般分为0-1阶段，1-10阶段，10-100阶段。
2.1 0-1阶段
0-1阶段，是产品的初创期，这个阶段的关键是产品的完善，需要的不是流量的多少，而是种子用户。
对于2C产品，有少数几个、几十个，最多几百个，可以跟我们产品达成共识的核心用户就足够了。此时产品尚不完善，用户过多，也没时间跟用户去共识，很可能会产品频繁暴雷，失败率极度提高。
对于2B产品，0-1阶段，我的看法是找到一个跟自己可以达成共识的用户，并且原因帮助你晚上产品的用户就够了。用户多了，不同用户之间会争夺资源，自己产品也不完善，产品仓促上线会有很多问题，一是会导致自己口碑变差，另外研发人员也要疲于应对各种问题，导致没有足够的精力去完善产品。例如我知道的做正确交易系统的H公司，在17年真正开始做证券交易系统，找了很好的一个用户A公司，愿意将自己的业务和竞品公司的系统实现全盘告诉H公司，并且对产品产权没任何要求，只关注自己业务的开展。从17年9月开始做，到元旦第一期上线试运行，春节后跑实盘，并有用户开始交易。18年初开始做第二期，将产品重构，并加新的业务。由于跟H公司达成了共识，认可系统的架构，虽然业务没什么增加，但A公司还是愿意配合，也愿意等重构后再做新的业务。很快6月第二期上线，A公司内部测试过后系统正式上线接投资者做交易。按这个节奏走下去，跟A公司深入合作，借助A公司的业务背景，集中精力在一到两年内可以把产品完善，然后度过0到1这个阶段。但是H公司在下半年重新找了一个行业前三的B公司，跟B公司合作开发系统，对A公司的投入极度减少，只做一些维护工作了。但B公司对产品有野心，合作开发的业务要保密，自己的业务也不想透露出来，几个月后产品就成了完全不同的两条线，此时A公司的产品业务落后很多，如果要升级，基本上要把生产的系统铲掉重新部署，而金融公司对数据非常看重，升级难度非常大。为了更对拉更多客户，H公司在下半年又应标了C公司，此时在C公司又开发新的业务。这样3个公司的产品都经常有bug要修复，新的业务在一个公司的分支上作无法直接应用到另外公司的分支上，结果导致在A公司产品重构后过来一年，H公司这个产品自己的标准产品是哪个都不知道了。为了市场铺开，19年拉了更多客户，但产品还在0-1阶段，导致到了21年，过了5年了，还没有一个完善的产品，每个客户使用的产品都有问题，版本也不一致，维护成本非常大，产品也还没有度过0-1这个阶段。
2.2 1-10阶段
当到了1-10阶段，可以适度地引入一部分流量了，对于B端客户，可以做一定的推广了。但这个时候关键不是做转化率，而是跟用户达成共识，同时继续打磨自己的产品。由于度过了0-1阶段，产品已经基本趋于完善，此时接入少量用户，根据不同用户的需求再打磨自己的产品，此时就一方面可以有一定的营收，同时产品也在短时间内得到进一步完善，而且这些少数的用户跟自己达成共识，会是自己的产品在业内快速形成非常好的口碑。
2.3 10-100阶段
当度过1-10阶段，此时我们就可以在市场上铺开了，以投资回报率作为牵引。但真的到了这个阶段你会发现做市场已经水到渠成了，已经有了一批核心用户跟自己达成公司，并在业务形成了很好的口碑，产品也已经趋于完善。接新的用户只要投入很少的力量做一些必备需求的开发就可以投产。
三、总结
到这里产品驱动增长的公式就搬运完了。前面有较长一段时间没有更新，主要是这个阶段去学NPDP课程，集中投入了一些时间去赶进度了，最近才赶上来，所以将最后这一篇搬运完成。
我们把公司最后写一次：增长=需求×方案×共识×体验×场域×效率×口碑×流量
做到不内耗、不失焦、不浪费、不外求，这样产品一定会健康茁长地增长。