三个方面分析：为什么产品第一个版本很久也出不来？

　　产品的第一个版本常常由于各种原因被各种耽搁，最终导致晚产甚至夭折，而本文就针对在这一问题分享了解决这一问题的三个方面，供大家参考借鉴。

　　经常会参加一些创新产品早期辅导和讨论，我发现一个普遍性问题——产品第一个版本总是要花费很长时间，迟迟做不出来。

　　我说的“久”是真的久，不是心理上感觉久。作为一个创新产品，无论是创业者、投资人，亦或企业内部的领导，都会对第一个版本报以厚望，就像腹中胎儿，所有人的注意力都集中在它身上，恨不得今天说好，明天就做出来。这本质是着急。

　　除去心理因素，很多产品的第一个版本是真的很久，久到错过时机，再也无法挽回。搜索一下这篇文章《2016倒闭的“互联网+”名单!》，可以看到很多企业已经死在刚刚开始的阶段。

　　为了快，大家也是想尽办法。比如，设定“Deadline”，结果是赶工出来的东西，一演示就漏洞百出，然后再改，结果交货时间一拖再拖。再比如学习《精益创业》中的MVP，设定最小可行产品，把早期的功能减少，可是做的过程中发现很多细节功能不得不做，又或者不断修改，结果仍然需要花费很长时间。

　　好的方法不一定会有好的结果，错误应用或片面应用都无法达成预期效果。

　　要想彻底解决“第一个版本慢”的问题，要从以下三个方面下手。

　　第一，一致的初始目标

　　(我去，这不是废话吗?谁做不到吗?)这个看似很初级的工作实际上很多人都做不到!举个简单的栗子，曾经在一个咨询项目里，两周前大家确定了产品的方向、第一个版本的功能、交付的时间。仅仅过了两周再回到团队的时候，随便问了三个人交付时间，居然一个人不知道、一个人说了大概范围，一个很肯定的说了一个错误时间。OMG!之前不是说好了吗?大家天天在一起工作怎么会不知道?没办法，就是不知道!!!

　　这才只是时间问题，目标能够都知道吗?很多产品早期的目标是非常模糊的，即便经历过无数次PK，我敢跟你打赌，一定是“每个人嘴上说我们达成共识了，但实际上脑子中的目标全不一样!”

　　这个时候，你心理可能会说：“好吧，我同意你说的，那么有什么好办法呢?”

　　我有一个必杀的办法叫做“不急这一时”。

　　对于目标，最简单的达成一致的方式，就是“复述澄清”。让每个人都用自己的语言重复阐述一遍对目标的理解。“WTF，这不是虐待吗?太反人性了!!!”没错，很多真正的有效方法都是反人性的，因为人性是有缺陷的。不但要复述，而且时间还不能少于10分钟，还不能说一样的话!一定要确保自己的真实理解被充分阐述，并被其他人充分理解和确认!

　　我的经验是，如果五个人在一起“复述澄清”时间绝不会是50分钟，而很可能是一天!甚至更多。因为每一个人复述完，你都会发现很多理解不一致，甚至是之前根本没考虑过的事情，于是又要进一步讨论。如果发生这种情况，建议第二天再来进行一轮“复述澄清”，这一轮时间可能会缩短到半天，那么在第三天再来一轮，直到能够在1小时以内结束，便可确认大家“目标一致”。

　　你肯定会觉得这个过程太烦、太费时间，没这个必要。但实际上，你最多只花三天时间，却能节省下未来三个月的时间。因为之前没说清楚的目标，会带来的无数次讨论、返工、多做、检查等等各种时间浪费。“不急这一时”。

　　第二，不能再小的MVP

　　我一直觉得《精益创业》是本好书，但是包括他介绍的方法在内其实都只是思路，不是方法，因为有太多可理解的空间和太多可操作的空间。就比如说MVP里的Minimum并未给出定义或标准，不易掌握和应用。很多人确定下来的MVP离最小还差的远，只是比他心里那个伟大蓝图小了很多罢了。

　　我想说MVP的最小应该包含两重含义，这两重含义分别是针对两种不同对象来说的。

　　首先，是对用户的。也就是对用户来说最重要的核心功能是什么，那就是MVP。但是这更加取决于产品的第一批用户是谁?大多数的创新产品首批用户并不是真正的用户，可能是以下几种中的一种：投资人、公司领导、主创团队、种子用户。即便是种子用户，也是很特殊的一类小众用户，他们的诉求是非常鲜明特殊的。如果是投资人，事实上你要做的并非是一个实用产品，而是一个Demo，目的是让投资人感受到产品的想象空间。此时的系统会非常简单，只需要关注你最能打动投资人的那一两个产品特性就够了!所以在这个角度上，搞清楚第一批产品用户是谁，他们最关注的是什么，那才是你选择MVP的标准。

　　其次，是对技术的。也就是说对技术实现来说最简单的方式是什么?所有做过互联网产品的人都知道，用户量每上升一个数量级，复杂度也会上升一个数量级。也就是说，做10个人的产品和做100个人的产品是很不一样的，复杂相差很大。早期阶段产品复杂度应该是很低的。所以最开始如果仅仅是给几个投资人做演示，可以完全砍掉与网络传输、并发处理、分支业务逻辑、后台管理、平台选择、成本考量等诸多复杂问题。所以，一定要避免传统架构师对可扩展性和基础框架的执念，在技术方面，能省则省。技术能够加速对想法的验证速度才是最重要的!

　　所以，在MVP的选择上，多花点时间精打细算是值得的，不要拍脑袋，草草决定，多花三天时间就能省去未来几个月的时间。“不急这一时”。

　　第三，有边界的产品定义

　　有了MVP，很多团队就开干了。因为大家都觉得自己很清楚要的是什么了。但MVP只是明确了范围，并未给出清晰的边界。比如，MVP确定要有上传图片的功能，但是到做的时候才发现还需要考虑是否需要剪裁图片、是否需要压缩图片、是否需要保存原图等细节问题。而这每一个细节都有可能会花上你几天时间来实现和调整。

　　所以这个时候，还需要确定详细的产品定义，说清楚做什么和不做什么。通过正反表述，给出一条清晰的边界。如果没有这条边界就会出现，技术团队自行决定实现到何种程度，往往他们会选择一种复杂的全面的方式来实现，或者反复确认反复讨论拖慢了后续的进程。

　　然而几乎没有一个创业团队会在早期花时间写这个，要么觉得没必要，要么一刻也等不了的去实现想法。但其实写的时间可能也就一周时间，却让产品的边界非常清晰，既让创始人的想法更加落地，也让实现人更加快速交货。能够节省未来相当可观的时间投入。“不急这一时”。

　　这篇文章举得栗子不多，原因是不想用过多笔墨去分析栗子，让大家无法理解整体逻辑。所以最后，给大家一个产品可以做个思考练习，有答案可以给我留言。

　　我一直都为深圳没有好吃的、方便的、种类丰富的早餐发愁，如果你想做一个互联网+产品来解决这个问题，你会如何设定初始目标、第一个版本的MVP、明确的产品定义?

作者：艾老思