但是，技术大牛的评估并不具备现实意义。首先，技术大牛完全是从他的角度做出的评估。比如一个腾讯的大牛告诉你这个easy啦，是建立在腾讯内部的程序员非常优秀这个现实基础上。而作为一个初创公司，我们只能找到很普通的程序员。其次，这个产品所涉及的技术，大牛都不一定做过，就算从他的角度出发也不一定估得准。

　　并且，我们把产品交到了一个只是看上去靠谱的传统开发手上。找到这人时，我们无比欣慰。第一，这个人是核心成员的亲戚推荐。第二，这个人简直是暖男一枚，跟他聊项目如沐浴春风。第三，这个人有十年开发经验，金融系统都做了无数，还怕移动开发不成。但事实很惨痛，这人完全是个忽悠范，各种打太极耍嘴皮，至少耽误了产品半年的进度。

　　2.嘴上说着敏捷开发，手上做着重度开发

　　在正式开发前，我们面临一个抉择：先开发web还是app。为了用户体验，我们选择了后者。后来，投资人也问我们为什么不先做web，我们也说为了给用户最好的体验。而后来的事实证明：如果当初做的是web，整个项目完全可能起死回生。第一，我们要处理的是一个低频需求，atv，非常适合做web。第二，做web可以快速试错，验证模式可行性，而app的重度开发做下去简直没有回头路。第三，web的开发成本极低，做app我们技术团队的支出最高达13万/月。第四，做web可以更加聚焦到最重要的功能上，而不是像app重度开发什么功能都想做。

　　理念上，我们内部不断强调“敏捷开发”，但行动上，完全与之背道而驰。第一，是受自身的局限性，懂敏捷开发和实践中遵循敏捷开发是两码事。第二，对用户体验的错误理解，过去我们一直认为保障用户体验就要给用户最完整的功能，但实际上快速做出最主要的功能找用户来体验后，根据用户和数据的反馈优化产品才是真正的保障用户体验。第三，产品逻辑陷进复杂的业务流程中，很多次重要的功能，其背后的业务逻辑异常复杂。第四，核心团队一开始不懂开发，等到逐渐懂的时候，产品开发已经完全脱离了我们的掌控范围。

　　我现在还记得产品开发进行了一年后，负责产品的伙伴对我说：“现在我们的app后台已经和淘宝的后台一样复杂了，坏处是没做到敏捷迭代，好处是产品本身已经具备相当大的弹性，对将来的拓展和再开发非常有利！”但是，我们能拥有的只有现在而已。

　　3.产品上线后我们立刻调整了产品方向

　　产品开发了一年半终于上线了。

　　然后，在还没有正式给用户使用的情况下，没有进行任何试错的情况下，我们做了三件事情。第一，技术团队大规模裁员，因为公司没钱了。第二，重新调整市场模式，因为觉得以前的模式起量不够快。第三，重新调整产品方向，因为市场模式变了。

　　于是，产品的开发又开始了。而下一次上线没几天，项目就支撑不下去了。

　　三、模式探索：大幅试错

　　正式创业前，我们就有个试错的信条：小步快跑，不断调整。但再次遗憾的是，我们再次做了相反的事。 理念和行动在探索的黑夜中特别容易走散。

　　1.主营业务的市场模式经历三次大幅调整

　　第一次调整后，初期特别痛苦，整个团队特别不适应新的模式。但在调整中期，经过磨合和优化后，在关键数据上取得大幅进步，业务量也较初期实现了翻倍。但是第一个模式仍有它的缺陷：起量速度不够快和市场体系不具备很好的复制性。

　　第一个模式试了半年就作废，开始了第二次大幅调整。但第二个模式仍然没有解决第一个模式的问题，业务量反而下降了。并且第二个模式还有一个更大的缺陷：人力成本翻了两倍不止。

　　第二个模式试了半年后又作废，开始了第三次大幅调整。但第三个模式本质上是对第一个模式的2.0版本，可以说是一次倒回。第三个模式依旧没有解决上述问题，反而出现了更致命的问题：业务量指数级下跌。

　　在试错上，市场模式和互联网产品本质上是一样的。 都应该先选择一个小的目标用户群来进行验证和优化，换句话来说就是用最小成本来试错。我们在市场模式的探索上本应该这样做：主体上维持第一个模式（有缺陷但能带来业务量），在小范围里推行第二个模式和第三个模式，以此测试市场反应和ROI。 但实际上，我们的每次调整都是彻底推翻以前的模式再彻底重建，每个模式都只试了半年，每次调整都是大幅投入，最终尝试到业务量崩塌。

　　2.支线业务不断探索但都不了了之