## 这篇文章也是MVP版本V0.1
假如你从0-1启动做了一件2C产品（假设是一个小程序），那么围绕这个产品的MVP最大的困难是什么？
- 是凑齐产品开发技术团队么？不是的，这是资源，可以被整合。
- 是通过QuickStart工作坊来完成用户旅程地图的梳理和排序么？不是的，这是能力，可以被训练。
- 是通过自己的伙伴来找到第一批可用的种子用户么？是的
如果你读过精益创业，你会了解到MVP的著名实验，计算机背后其实是人给出的运算结果。
接着你会开始思考，在企业中拆分成了迭代，一次次的更新，及时的响应客户的需求是多么的美好。
一旦进入这种逻辑回路，你将会遭受到：
- 开发人员对你的无尽鄙夷，认为你对产品完全没有自己的长期思考和建设，除非你发工资（可以暂时听不见）..
- 市场人员对你产品的无尽鄙夷，认为这是一个放眼整个斗气大陆都是毫无竞争力无法销售的存在，除非你找自己的客户..
- 一些号称早期使用者但其实完全不打算付费的用户的无尽鄙夷，认为一个没有思考完整的产品，不应该拿出来见世面。
等等，我们似乎触碰到了这里面的关键点：
- 为什么要发布最小可用的价值版本？
- 因为我们需要快速的验证产品的假设，是否有客户会为此买单。
等等，这里面的客户是谁的客户？客户为此买单的后果由谁承担？
- 天呐，精益创业里从来没有提及过这一点？我们天真的以为，当然是公司的客户，当然是一起承担。
- 不，完全不是如此，你产品的MVP以及质量上的缺陷，会给你的上下游带去很多的麻烦，即使产品一团糟，被客户嫌弃的具象化存在也不是坐在电脑前的产品和程序员。也就是说，做出决策的人不承担决策的直接后果。
通常来说，我们认为做MVP的过程是加速犯傻，以防结尾只能认亏的调整模式。
- 所以，我们的MVP是在要求别人犯傻，并为此承担后果。
- 而自己在后果中调出有用的反馈，改良产品，并继续让别人犯傻，并享受（假如有）迭代带来的成果
所以，你现在明白，为什么，没有人愿意将迭代版本推向市场拉取反馈了么？
- 玩的是人情
- 最后是事故
