如何验证产品可行性
作者：张博超
转自：微信公众账号InfoQ
ID：infoqchina
该微信是中高端程序员的意见领袖，想要窥探程序员脑子里都在想什么的同学千万不要错过。
你做过“虽然没有人要但是很牛逼”的产品吗？
今年的北京QCon我和Daniel分享了一个话题《原型之前的傆型》。很多人也对这个话题比较感兴趣，甚至有出版社建议为此出本书。这是很多产品经理都碰到的问题，却很少人仔细思考过。
不知道大家是否都经历过类似这样的产品或项目：有个产品总监很推崇现在流行的云计算，想把现有的企业产品放到云里。于是和技术骨干进行了讨论，加深了对这个技术的理解。云计算可以帮助客户大幅减少IT运维的成本，客户应该很高兴。于是开始和客户沟通，客户听说可以省不少钱，都很感兴趣。产品总监信心大增，投入100多人力，耗时一年完美的完成了这个产品，质量、进度都不错！还召开了庆功会。然而最终结果呢？这个产品完全无人问津。当初哪些很感兴趣的客户哪去了？过去一问，客户说：这个的确省钱，我们也很希望降低成本。但是要把我们公司的财务和企业策略放到一个不受我们控制的服务器上，我很不放心啊！我宁可多养一些人来看着我的数据！
我们需要更高效更可靠地验证假设
这样的故事屡见不鲜。到底是什么原因导致的呢？很多时候我们在产品上做的各种决定都是基于假设的。我们经常卖我们能做的，而不是做我们能卖的。这是假设我们能做的就一定能卖。我们前期做了市场调研，很多人表示很感兴趣，愿意买我们的产品，销路肯定没问题。这是假设这些感兴趣的客户他们说到做到一定会买。类似的假设有很多，我们做一个产品会做许多的决定，这些决定都是基于假设的。任何一个假设的不成立都会导致产品最终的失败。 意识到各种假设的存在，我们就需要验证这些假设来规避风险。那么如何验证假设呢？
其实我们或多或少都会验证假设，只不过我们花了大量的人力物力构建出完美的产品，然后让最终市场来一次性告诉我们这些假设是否都属实。这样的验证方式代价是我们难以承受的。因为我们已经浪费了许多的成本，时间等等。我们需要低成本的方式来验证，并且验证失败的唯一原因是假设是错误的，也就是说不会受其他因素影响。我们需要设计低成本的受控试验。我们把这种试验叫做傆型（Pretotype）。
有一种方式很常见，许多互联网创业公司一开始都会上线一个页面叫做着陆页面（LandingPage），这个页面上只有简单的文字和图片的介绍，然后就是一个输入框让访问者留下联系方式，这里会用各种名义：关注最新进展，订阅，申请内测等。这种方式成本十分低，只需一个静态页面，后台记录一下联系方式就可以了。通过记录的联系方式就可以知道大概有多少用户对产品感兴趣（即上套指数Initial Level of Interest），验证产品的用户假设。这种验证方式往往创造一个假的入口测试有多少人会进入这个入口从而知道用户的感兴趣度，我们把这种方式叫做仿真门（Fake Door）。那为什么不直接去访谈客户或做调查问卷呢？访谈和问卷都是基于语言的，语言比行为更不可靠，让用户通过行为来告诉你更加可靠。
有一家公司SendWithUs把仿真门做到了极致，他们上线了一个产品有各种功能，但这些功能都只有入口，没有任何实现。他们通过这样的方式收集了许多数据，了解到这个产品到底哪些功能是客户想要的，明确产品市场定位。傆型中另一个比较重要的原则是把用户行为转变为数据，让数据来帮助我们做决定。
除了仿真门，还有哪些傆型呢？
看门人 - 有了感兴趣的用户，他们会真的用么？他们会“正常”的使用么？那就做个真的界面出来，但是后台其实是人工操作的。
探索者 - 知道了用户的行为，根据行为来研究一下用户，这个时候让用户解释一下他的行为更确切。
试点区 - 只针对特定的用户群，比较效果以及控制风险。
大篷车 - 很多时候没必要去准备好完善的基础设施来进行你的业务，可以使用其他廉价的方式来快速开始你的业务从而及早发现业务风险。
MVP - 不要尝试一次做出一个完美的产品，用最小的代价来验证你的商业可行性。（Minimum Viable Product –最简化可实行产品）
匹诺曹 - 做一个假的产品来试用，可以帮助你理清产品的功能。
“傆型”是产品快速迭代的发动机
傆型还有许多的方式，大家可以一起来研究尝试。但是傆型不是只在你开发产品前才做的事情。产品探索与产品交付本来就是一体的。有一个想法出来，就立刻找出假设，设计受控试验，然后收集数据，根据真实的信息完成想法的交付，接着下一个想法，周而复始。整个过程是非常快的，正所谓天下武功，为速不破。
