导读
常言：尽信书，不如无书，若是全如书中所说，那是不是太简单了？知识是不完整的，尤其是文章里的知识，受限与篇幅，就更是残缺不堪的了。
知识是不完整的
有一种标题格式的文章，你一定见过，比如：如何打造千万用户的产品，或者：掌握x个技巧，让用户上瘾等等，这些文章都是有价值的，其中的部分观点对我也有极大的参考和学习价值，然而他们却是不完整的。
任何一个成功，都是在必然和偶然的双重因素下形成的，这是一个复杂的过程，是不可能在一篇数千乃至万余字的文章里进行完整描绘的，其中还关系到时代背景，团队背景，行业背景，还有中间出现的若干次选择，做一次正确的选择并不困难，困难的是每一次都做出正确的选择。
我想，看到这里，你应该能接受这个观点了：知识是不完整的，我们看见一篇论述打造明星产品的文章没有收获，并不是因为这些知识是错误的，而是因为他是不完整的，在不同环境下，乃至于产品的不同阶段里， 有许多的因素会影响着我们的做法，或许你在一条不适合用该方法的道路里前行，又或许，你所前行的道路尚未触及该方法的应用位置。
其实，我倒是觉得这样挺好，因为对文章内容的排斥，选择拒绝学习文章里的知识，总好过盲目的应用，盲目的生搬硬套，不是吗？ 这就像刚入门的我们，向他人背诵一些典型的商业案例，尤其是向我们的面试官或者leader，其实这样挺让人尴尬的，毕竟导致某产品成功的原因实在有太多，而外界所盛传的未必就是完整的。
同样的，在学习一途，盲目的吸收着文章里的知识，只会让我们走入一个又一个的死胡同，比如MVP，确实按照MVP的原则去做了，为什么效率还是很低? 为什么我努力的照顾到了用户体验，但用户就是不使用这款产品？。
产品经理的知识面积很宽，我想这样的问题会有很多吧，明明已经按照前人总结的经验尝试了，但不仅没有效果，甚至比以前还不如了。
失效的MVP
MVP也叫做最小可行性产品，网络中可以查到许多写MVP的文章，写的都很棒，都有自己的观点和判断，常见的一种观点是快速尝试，收集用户反馈，这是正确的， 为了减少我们的成本风险，我们先把核心部分做出来，投入市场确认一下，再将他完善出来。
但在某些环境下，MVP就失效了，某方案的定位与产品定位相违背时。
这是一款迭代至2.0版本的产品，主要是为老师提供一个办公工具，可以方便的进行学生成绩管理，作业管理等事情，此时有位产品经理提出了一个方案，”我们用MVP的方法，来尝试一下教师和教师之间形成社区的可能性吧，成本很小的。”
是的，MVP的核心价值便在于低成本，快速试错，其结果，自然是受到了用户的排斥，新上线的社区板块，几乎没有人使用，每天只有不到10条的内容更新，甚至有部分用户转移到了竞品上。
低成本，并不等于没有成本，而成本也不仅仅是开发时间，还包括了用户对产品的感知，作为用户而言，我们有权利选择一款更适合自己的产品，即便只是微小的差距，当产品去试错的时候，竞品则在逐渐完善己身，一旦试错真的错了，就等于落后与竞争对手了。
MVP本身并没有错，当我们想试错时，用MVP的方法进行尝试，这个思路是无比正确的，错误的地方在于他不完整，而我们则拿着不完整的知识应用到了重要的事情上。
上述案例里，至少有几个前提条件是缺失的，
1、只是2.0版本，是否就要做跨度较大的尝试
2、社区的尝试，与产品的定位似乎有点遥远了，至少在2.0阶段。
3、似乎没有考虑到如何让用户接受社区，没有相应的缓冲过程，
4、似乎把MVP只理解成了功能的规划，小是最小了，但真的完整吗？
MVP，最小可行产品，有几个隐藏条件：
其一，是与产品大目标方向相同，或者与阶段目标方向相同，是逐渐完善的过程，而不是盲目的，想到什么做什么的。
其二，方案是要最小的， 舍弃扩展功能，保留核心功能，但同样需要这个核心功能是完整的。
第二点，“完整”该怎么理解呢？
对于一个新功能而言，尤其是跨度很大的功能，至少得让用户知道自己为什么要这么做，要给予用户一个行为动机，而不是说把这个社区板块放哪，由用户选择是否使用吧，这也是很多产品容易犯的错误，我们认为把功能做完了，放在那，用户若是不用，那就是没有需求，其实只是因为这个功能并不完整。
上述案例中，MVP的思路并不是发布动态，动态列表，动态详情，消息通知四个功能构成，至少还需要增加一个动态推荐，主动的将用户可能感兴趣的内容推荐给用户，以此通过内容来引导用户使用才行。
导致这一问题的原因，恰恰在于我们对知识的盲目信任，时常让人感叹：尽信书，不如无书，MVP是一种很高深很有效的技能，若只是文章知识的堆砌，那也不会被许多人所推崇了吧。
相对于填鸭式的学习，倒不如辩证的去吸收，学习知识背后的原理，不受知识所限制，灵活的去应用，毕竟知识是死的，更遗憾的是，他的“尸体”还是残缺的。
失效的“用户至上”
这也是一个容易被攻击的话题了，用户至上，有时是错的，他并不是万能的。
将这四个字奉为无上大道的创业团队，没有一万也有八千了，但很遗憾的大部分的影响成败的决策，往往和这句话没有什么关系。
共享的单车，已经进入到尾声了，然而直到现在，也没有看见允许载人的共享单车，自然不敢说我已经见过所有的共享单车了，但确实在成都，在深圳，我没有看见一辆允许载入的恭喜单车。
若是为了用户至上，为什么不让单车可以载入呢，毕竟购物篮都装上了， 但载人的座椅始终不见，这让一些小情侣怎么办呢？
不管是旅游的情侣，还是上学的，或者上班的，有一辆这样的单车，其实是一种很高兴的事情，
若是用户至上，似乎有必要来照顾一下这些年轻群体了。
真实的情况是什么呢？ 比情侣出行更多的是单人出行，这表示载入单车大部分使用时间里和单人单车没有区别，是一种成本上的浪费了，而且 载人单车会让两个订单变成一个订单，这样一来订单量就降低了，收益也降低了。
成本增加，订单和收益反而下降了，这样的“用户至上”，你还要坚持吗？在商业原则里，这是一个很粗浅的问题了。
同MVP相同，“用户至上”是有前提条件的：
1、不是什么用户都要至上的，实际上，只有目标用户是至上的。
2、用户至上，有时是要为商业让步的，最终影响成败的毕竟仍然是商业。
3、做企业不是做公益，做产品也不是做义工，尽管同样是用户至上，多数总会比少数更上一点。
或者我们把这四个字进行一些扩展，多数目标用户无限接近至上，会好一点，有需求的人要足够多，而且要是产品的目标用户，才能无限接近至上，但却不会真的至上了，毕竟还有商业资本这关呢。
多数团队都有这样的故事，用户体验成了我们争执的主要话题，尽管只是一小部分人感到体验不好，也会被我们以“用户至上”的原则展开激烈的探讨，而且，这往往会形成执行产品与产品leader的直接矛盾。
毕竟，有了一定的经验了，会更懂得舍弃少量用户，拥抱大量用户，但显然，经验尚浅的我们，并不能完整的解读“用户至上”，还在将所有的用户一视同仁。
在微信买东西是种什么样的体验呢？微信很早就植入了京东购物，我们需要在发现页进入，然后在打开的H5页面进行购物操作，并且是生成的一个虚拟账号，用户昵称默认是一长串的默认编码。
这样的体验着实谈不上好，只能算是比较普通的做法了，选择商品时的返回，挺让人奔溃的。
遵循用户至上的原则，我们是不是应该要求微信团队将购物板块做成native呢，并且最好能和微信账号进行捆绑，最好是能将购物作为第五个一级页面，要知道微信一直保留了一个一级页面的扩展空间呢。
从技术角度来讲，是完全可以实现的，表皮用微信的，内部的数据则由京东来提供相应的接口。
为什么不这么做呢？
似乎购物的用户并不是微信的目标用户,尽管他们是同一个人，
似乎两个企业之间进行如此深度的合作，风险挺高的，毕竟就像在自己的代码里融入了对方的一些代码，稳定性和安全性都是一种顾虑。
此时，“用户至上”似乎成了笑谈。
若是真的一切都以用户至上的原则来做，那就不会有竞品了，大家气氛融洽的将所有数据公开就是最棒的了，也不要折腾版权了，直接购买全部的版权吧，像是我们现在听歌看电影要下载很多的软件，因为版权问题，这部电影只在这个软件里有，另一部电影则在另外一款产品里。
辩证的去学习吧
任何的知识都与应用的前提，不管是MVP，还是用户至上，又或者传说中的秒变小白，或者是其他的知识，都是有前提条件的，我所知道的大部分的知识本质上都是服务于“利己思想”而非真正的“用户至上”。
你需要明白，文章中或者书籍中的知识都是不完整的，我们几乎无法将一个知识完整的记录并书写，因为实在存在太多的可能性了，我们只能通过辩证的方法去学习。
所谓的辩证，不是去分辨知识的对与错，而是深度的意识到没有绝对的正确和绝对的错误，吸收对己有利的部分，舍弃一些有害的部分，在知识的应用过程中，也需要根据自己的情况，所处的环境，灵活的去应用。
尽信书，不如无书。
这很难，但我想，这个观点或许对你有所帮助。
知识从来不是用来解决问题的，实际上任何知识都没有办法解决问题，知识，只能让我们更高效的解决问题，而解决问题的本质仍然是我们自身。
不是学了MVP就能低成本进行尝试了，而是在我们需要尝试时，应用MVP的方法，可以更有效的进行低成本尝试，也不是说学了“用户至上”就能设计优秀的产品了，而是在我们设计优秀产品的时候，“用户至上”能提高我们的设计效率。
若是将 对知识的认识定位在提高自己解决问题的效率上，我们就会发现开启了一扇新的大门，将会发现，知识是可替代的，MVP可以替换成第一性原理，而用户至上则可以替换成商业价值，我们也将具备“灵活”设计产品的能力。
