产品模式|最小化可行产品的精益要义
Minimum Viable Product——新型产品设计理念
前辈作家埃里克·莱斯的《精益创业》书中提倡一种叫“最小化可行方案”（Minimum Viable Product，简称MVP）的产品搭建的概念，该理念超出了产品/软件的从业者预期，甚至显得有些格格不入。
产品模式|最小化可行产品（MVP）
创新理念如一股清风沐浴整个科技行业，创新伴随着破坏，哪怕到如今MVP的产品还是为不少人无法接受或者说更愿意习惯已有的传统产品理论。时下软件/互联网产品倾向于一次性设计完整产品，试图定义产品的终极形态，说不定你就身在其中。
MVP精益要义
最小化可行产品（MVP）主张：定义一个满足用户核心需求的产品——能够帮助用户解决问题的最小功能集合，符合价值性、可用性、可行性。产品原型一旦被设计并经受住市场的价值考验，也就顺理成章成了“基本产品”——元产品。
不抛弃、不放弃！
最小化可行产品（MVP）被置于一个完整的实践过程才有意义，这一过程大致可以概述为以下三个过程：
1、搭建最小化可行产品：以最简单的方法实现产品原型的可视化，保持克制，只保留基本/核心的特性，通过目标用户搜集反馈信息，快速迭代优化。
2、重视每一个用户声音：通过内部/外部反馈机制收集用户反馈，尤其是对产品的整体感受、功能评价、流程合理性等核心要素的意见。用户建议是持续产品迭代优化的重要决策依据。
3、小步快跑，快速迭代：及时响应用户提出的反馈，将其以功能的形式体现的产品上面，是一种能力。有错必改，还能改的及时，更早触达用户将为产品赢得更多可能。
最小化可行产品的初衷是——产品价值判断的验证，而不是什么颜值的比拼，或许满足用户的需求，帮助用户解决问题比一时的视觉体验/技术炫技要务实的多。当然，谁又不想拥有傲娇的面孔？而我更喜欢TA的内在...
MVP产品实践
产品经理遭遇的尴尬一幕莫过于：这个产品/功能不是我们想要的！更狗血剧情是产品经理自己试用了一番后也不来电。究竟在一个怎样的场景下才能造成如此结局呢？
技术研发通常都是依据产品经理定义的详细文档来评估开发所需要的时间和人力成本，技术人员也确实给出了评估的时间，可这并不是产品眼里的理想时间。那该咋办呢？瞎扯呗...于是，各种奇葩说辞一起上场，时间估算不合理、砍功能、加人、压缩测试时间等等，直接就成了段子大会了！扯这么长时间，也临时拿出了一套方案。那么这套方案的结果，正如我上面所说的——用户不喜欢甚至产品技术自己人都觉得不咋地。
那么究竟如何尽量规避这些问题呢？尝试新的产品设计模式，或者反思以往产品设计模式的不足，做出新的改变，或许就有可能有所改善。
1、产品最初设计原型应该尽量做到高保真、最小化、满足基本需求，满足商业价值的同时拥有较好的用户体验。只有基本产品才能将产品的商业价值最大化的表现出来，开发成本最小化。低价试错不怕输！
2、产品原型设计阶段技术研发适当的介入，对产品后续实现的过程会起到说不出的作用。技术人员可以对产品解决方案的可行性及成本进行分析、评估。问题关键还不仅在于此，能够保持产品后续环节人员的需求清晰，那么离这个产品最终问世，可以说是只有一步之遥。
3、用户测试产品原型，产品经理往往对自己设计的产品满怀信心、非常得意，却不知用户的胃口还是很叼的。只有经受地起用户的测试和验证，才能算是真正的产品原型。而原本定义为基本产品的原型也是不可能做任何模块的删减，这一点真没得商量。
是不是说经过产品验证、或者说产品被定义为所谓的基本产品，那么技术的开发时间评估就一定准确无误呢？这个可以明确回答，不可能。软件项目的过程很性感，让人有些琢磨不定，精确地评估显得有些强人所难，但必要的时间周期还是要给出的。合理把控产品开发周期的节奏，功能肯定是不能再砍了，周期内适度的调整时可控的，是可接受的。
定义基本产品还有一个很大的优势，可以严格控制一些人为因素。在传统软件项目中，最令技术人员心惊胆战的就是——修改需求，而这种新型的产品设计模式主张的是不可修改基本产品，既定需求也不能改，有效加快技术开发进程；当然，也对产品设计的过程中提出了要求考虑全面和长远。
MVP思考小结
定义实践基本产品也是SCRUM的一个主张，那么是不是说这就是放之四海而皆准呢？那也未必！如果你够NB、不缺钱、不缺朋友，你可以尝试定义一个完整的产品。或许这真的是一个不错的选择！
最小化可行产品，每一款互联网产品的起点；
无关乎，平庸、非凡；
值得提倡、价值实践！
无关乎，微型创业、成熟企集；
价值实践的最好选择！
我是王伟
很开心和大家分享，而我想把开心一直继续！希望对大家有点帮助！
