如何用最小的代价做产品
problem
“面对不确定的产品功能该如何分解？”
slove：
任何的想法都要放到真实世界去验证。
mvp 原则： 最小可行产品
What？====》刚刚好
其中的关键在于理解“最小”和“可行”
最小的代价
能不做就不做，能简化就简化
一个误区： 我们要做的是验证一个想法的可行性，甚至不是为了开发软件，开发软件知识一种验证手段。
很多程序员都有一个认识上的误区，容易把解决方案当成问题。我们开发软件是为了解决问题，如果不写软件就把问题解决了，岂不是更好。
不知道你注意到了没有，迄今为止，这个团队验证了一大堆的想法，而代码却是一行都没有写，所有花费的工作量都是有针对性的验证。<前期先验证>
验证想法阶段，就不用写代码了。
开发软件是一件成本很高的事情。如果只是验证想法，无论是创业方向，还是产品设计，我们可以找到各种各样的手段，不用写代码。
可行的路径
可行是要找到一条路径，给用户一个完整的体验。（重点）
做程序员出身的人，对软件系统的认识总是一个模块一个模块的，相对比较弱的方面是缺少一个完整的图景。
但从产品可行的角度，我们需要转换一下思路，不是一个模块做得有多完整，
而一条用户路径是否通畅。（重点）
和大家分享这个例子，主要是想破除大家对于一个“完整”系统概念的认识。
当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。站在开发团队的角度，我们怎样把 MVP 理念运用在自己的工作中呢？
当产品经理有一大堆要实现的功能时，我们就可以根据 MVP 理念，从这些产品功能中找出一条最小的可行路径，重新安排一个合理的开发计划。
总结时刻产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。
最小可行产品就是“刚刚好”满足客户需求的产品。想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。
最后的解决方案
最小的代价就是能不做的事就不做，能简化的事情就简化。程序员通常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案。
可行的路径，是一条完整的用户体验路径，至少在用户眼中是这样的。
我们常常会想给客户一个完整的系统，但在时间有限的情况下，我们必须学会分解。
如果今天的内容你只能记住一件事，那请记住：做好产品开发，最可行的方式是采用 MVP。
可操作手册：
网友评论