为什么你看了那么多产品文章却依旧做不好产品

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