上一篇产品反思写完之后，很多朋友希望我再多写一些类似的反思，我觉得可以趁此机会将以前做过的产品都复盘一下，有些比较成功，大部分都“死”的很惨。不管是成功还是失败，都是值得好好反思的。

今天说的这个产品经历比较特殊，当时移动互联网刚刚来领，微信日活刚刚破亿，整体渗透还不像如今这般恐怖。我们也曾一度看到挑战微信的可能，也逼迫腾讯做了一款和我们一样的产品来防守，一切还是从2014年开始。

2014年，我们做了一款主打「免费通话」的 *** *** 应用，android和ios双端的峰值月活逼近5000万，目标是快速突破1亿，彼时的微信月活刚到3亿，我们也曾似乎看到了免费 *** 颠覆微信的可能。

当时我们在分析用户需求时，从高频，刚需的角度出发。毫无疑问，打 *** 是一个明确的需求。当时的打 *** 还存在一个比较大的痛点就是资费较高，特别还有漫游费，长途费等等，对于一些在外地打工的用户来说，和家里的 *** 沟通的成本非常高。

为了解决这个问题，出现了很多的 *** *** ，有一部分，通过IP *** 的方式，耗费流量，类似于微信语音 *** ，但是必须要求双方都安装。还有一部分承包运营商一些质量较差的线路，主打低价 *** ，往往通话质量较差，并且没有来电显示的功能，导致接通率非常低。

微信自带的语音 *** ，因为当时主流的 *** 还是2G和3G，一方面流量费较贵，一般都是在WIFI下使用，另一方面2G和3G的 *** 对于语音通话，通话质量还是较差并且不稳定的。在分析了上述的情况后，我们觉得解决用户打 *** 方面有着巨大的空间，也许就像当年微信替代短信一样大的机会。

在明确了用户需求后，我们开始之一个MVP版本的设计，我们定义的用户主路径是，如下图所示：

打 *** 流程

用户的主要路径，就是打开我们的应用，然后在通讯录中找到需要呼叫的人，然后打过去，对方接起，完成通话即可。我们的体验是要比系统的呼叫更好的。

在用户的主路径上，我们保证每一个节点都是和竞品相比体验更优的。首先我们做了一个非常好用的通讯录，在联系人的查找上，我们做了当时领先的九宫格搜索，在通讯录检索中，为了更方便用户找到目标联系人，我们做了滑动字母索引条时，出现对应汉字姓氏，便于选择。在用户的检索和查找联系的效率上和系统的通讯录相比有了明显的提升。

在呼叫环节，我们进行了业内首创的利用流量连接我们的服务器，我们在服务器端，通过购买的通话线路，直接呼叫任意手机号码，座机。在这个过程中，因为用户仅仅连接我们的服务器，需要消耗极少的流量，并且对于 *** 的要求不高，在2G *** 下都可以成功发起呼叫。

呼叫的过程因为是直接使用了运营商的线路，因此，可以直接呼叫任意设备，无论是手机或者座机，这是当时 *** *** 都不能支持的。另外，因为我们采用了运营商的线路，因此通话质量和手机的正常拨打 *** 通话质量相当，远比当时很多 *** *** 质量和稳定性高，当然这里也有着很高的运营成本。

特别是我们大范围使用了可以显号的线路，因此当呼叫对方时，可以直接显示呼叫人的号码，和很多 *** *** 相比，因为正常的显号，极大提高了接通率。

因为这些良好的体验和可以直拨，显号，对方无需安装等特性，外加上初始冷启动时，我们赠送了很多通话时长和话费代币，导致在初期几乎完全免费，我们在上线后，获得了极好的用户留存，以及非常好的用户传播。

为了加速用户增长，我们再2014年就做了最早的基于朋友圈的社交裂变。进行了分享应用，赢取百万话费的活动，在活动进行后的几周内，迅速在朋友圈中传播开来，新增迎来了指数级的增长，日活同样随着新增用户的数量同步扩大，峰值的时候，逼近1000万。

在数据疯涨的同时，我们也遇到很多的问题，更大的问题是每个月的运营成本急剧上升，其中主要是线路费用的暴涨。为了减轻成本的压力，我们开始收紧免费时长的发放，百万话费的活动也逐渐暂停，这个时候，当免费的点没有那么强之后，我们的话费和传统的 *** 相比依然很有竞争力，因此，对于整体数据的影响不是特别大。后来又遇到一些政策的问题，运营商对于线路的控制收紧，导致线路的成本急剧上升。