你的APP的用户不是靠产品的功能赢得的，而是产品的体验
假设在这种情形下，你需要定义一下你的产品的最新版本，记得不要只是列产品的功能清单，而是要将产品的商业目标和用户的需求结合在一起，然后努力去营造一种体验，使你的目标用户想要去用你的产品。同时，你需要做好准备去聆听真实使用者的声音，不断的调整和改进你的产品，来不断的俘获新用户，巩固老用户，增大你的用户群。
如果你正在努力为了确保产品有足够的竞争力或者能覆盖更多边缘的使用场景而在给它加各种功能的时候，你正在推迟你开始学习怎样让用户参与互动，怎样让用户开始行动，以及会有怎样的商业结果的点。
你发布的第一版产品是一个学习怎么创建一个用户买账的体验的重要机会。这可比你基于模糊的人口统计学甚至是丰富的用户画像而感知到的用户真实珍贵的多。这也是为什么把你手中的最简可行产品(MVP)尽快投放到潜在市场是那么的重要的原因。
很多产品进入市场的时候是以一些不一样的东西开始的。
Foursquare就是一个很好的例子，他们花了两年的时间把目标集中在市场衍生物上。他们发现游戏化模型会快速被用户接受，但是它没有建造足够好的，有强力引力的体验以至于可以保住核心用户并让他们成为潜在支付者或者提供长线价值。所以他们把重心转向了本地搜索。
Foursquare的例子很好的阐明了快速试错的重要性。他们花在专注于不可持续的体验上的那两年，也间接对大多数的同类型的烧着投资人数百万美元却还没有任何盈利希望的产品判了死刑。
一个更好的阐明最简可行产品(MVP)策略的例子是Hyperlapse，一个从Instagram/Faceboook出来的产品。
当你打开APP，你会被邀请开始拍一个Video，拍摄结束时，你可以给你的video设置一个从2倍到12倍不等的速度。设置结束后这个被加速的video将会被保存到你的媒体库，然后你可以将此视频分享到Instagram 或者Facebook。
这就是那个APP。
没有注册登录的环节，也没有应用内文件管理，你也看不到你保存在APP里之前的视频。
你只能一次性搞定这个视频，不能回头修改你设置的速度，你只是设置一个速度，然后分享，就这样。
“我们不能发布一个没有那些功能的产品”
大多数公司会说，“我们不能发布一个没有这些功能的产品”
好，让我们来简要总结一下像Hyperlapse这样的产品在发布的时候需要增加两个额外的功能——文件管理和视频编辑，后会是什么情形。
为了达到这个目的，你需要考虑用户怎么去接触到这些功能（导航和屏幕控制）；设计这些页面；将这些功能运用到使用场景需要什么；开发这些功能，包括文件系统的访问以及支持视频编辑的复杂的API。然后你还需要测试和发布产品。
这绝对是四倍于前的接口工作，六倍于前的开发工作。
这还是在没有考虑发展问题和之前那些复杂的工作会导致的特殊情况的前提下。在每种情况下，妥善解决这些新功能带来的问题都需要时间，这就意味着产品进入市场的时间会晚二、三、四个月，甚至更长的时间。如果没有人深究，然后呢，如果你不能赚钱，然后呢？
如果你的MVP（最简可行产品）因为身负一些无关紧要的功能而进入市场太慢你会冒很多风险，有可能是错过宝贵意见，最糟的是，你的MVP是基于一个错误的假设。
设计一个问答工具
一个新产品，你带着对你的目标用户和使用你产品的用户的实际行为的一系列假设站在十字路口，一直奋力抓住新的市场机会，处理不断变化的目标需求，和其他一大堆未知的情况。
这些你给你的MVP（最简可行产品）增加的功能和一堆未知的东西会给你的MVP（最简可行产品）带来额外的变数。这些变数反过来又会让你那些新增的功能和未知的东西更难验证，你也很难收集到有用的数据去帮助你改善你的产品。
你的MVP就是一个将问题转化为答案的工具。
MVP的目的就在于减少产品开发中功能点的数量，和减少那些未知的东西的大小。换句话说，你的MVP就是一个将问题转化为答案的工具。
你的产品的核心体验
你设计建造的功能越多，在投入市场前就会花费越长的时间，更糟糕的是，你在没有市场反馈的时候做了越多，越不可能吸引到目标用户且得到他们的关注。
造成这种结果的原因在于你不可避免的把你的APP的功能建立在越来越多的未经证实的假设之上。这就像你在没有任何图片的参考下拼一个巨大的拼图一样。
所以，你应该聚焦于提供给你的目标用户最核心的体验。简化你的产品，定义一个可能抓住目标用户的必不可少的核心的功能，并把它做好然后交到用户的手上，听听他们的反应。
如果你没有抓住核心体验，而是把你的产品做得宽而浅，那你会发现你的用户变得迷茫、困惑、厌烦甚至走掉了。最最重要的是，你将不会再找到热情高涨、干劲十足，想跟着你成事的员工了，你将不再有吸引力。
太多但是
典型的产品设计的过程是由一些内在的力量驱使，做出一个MVP，这个MVP没有并没有特别的产出速度、聚焦、效率和洞察力。
在进入市场之前，你总是能找到理由做更多地事情，但这些事没有一件能为你做出伟大的产品给出有见地的指引。所以，让我们来看看这些反对的意见吧，看看他们是怎么走向失败的。
让我们回顾一下创造一个有价值的MVP的过程中的三个主要的点吧，如果你从一个产品经理那听到这些，那关于一个臃肿的，无重心的产品的坏处真是有太多可说的了。
如果你就是一个产品经理，我们强烈建议您把您MVP的用户体验当作最重要的事情去不断优化，如果不这么做将意味着有比研发预算超期更麻烦和复杂的事情在等着你。
第一个但是：“我需要让我的MVP变得更有价值一些”
作为一个企业经营者，或者签支票的人来说，他们更容易试图去做一个有着很多不必要功能的MVP，从预算上来说如果你觉得更多的功能意味着更大的价值，那貌似功能点越多越好。但其实更多的功能点只意味着更多的工作量，同时也总是削弱产品的体验价值。
这道理就像是用一辆车的轮子数量来定义这辆车的价值一样，六个轮子的车一定比四个轮子的车好，因为你拥有了更多地轮子。
这个论点不合理，一味的增加产品功能的数量也一样，因为功能不等于体验。事实上，更多的功能导致了更多的费解和迷惑。这些额外的功能带来的副作用使产品变得难用，同时增加开发成本，维护和支持成本。
从另一个角度来说，一个MVP的功能点的数量甚至和它能做的事情（如下）都没有直接的联系：
1验证你的假设
2获取用户和市场偏好的数据
3给你的用户提供最核心的产品体验
冒险再重复一次，给MVP增加更多功能就是在推迟你可以做这些事情（以上三点）的时间。
如果有什么东西你想优化的，那一定是要尽快找到使用你产品的热情的用户，而不是给产品增加功能点。
第二个但是：“我们要覆盖所有的使用情境，否则就会失去用户”
快让我们忘了这个吧：你不可能涵盖所有的用例。
功能丰富的产品们，都发展成长了多年，有数千的开发者，也还不能涵盖多有的用例。所以说这是个多么蠢的事情，好一点是你为核心用户创造更好体验的精力被分散，更糟的是导致你无视了你的核心用户。
看看微软的Office。Office是微软继Windows之后的第二大营收支柱。不过它最近被Google的在线文档和很多其他的书写工具搞得很郁闷。Office不像这些竞争者们，又快，有好用，还可以很便捷的快平台使用。这些竞争者们把目标集中在最核心的书写需求的目标上，而没有去做大量的只能吸引高级用户的功能。
我们假设世界上大部分的用户只用了产品5%的功能，这就意味着任何公司只要把这5%的功能做到更好，相比于微软就有了绝对优势。
做一个涵盖边缘用户情境的和高级用户需要的功能的MVP将会花费4倍于前的设计时间，6倍于前的开发时间。添加了这些功能也让用户界面变得更复杂迷惑，用户需要在各种无关紧要的信息中筛选，才能找到他要的。
所以，这不仅仅是增加了开发的成本，也增加了用户的认知成本，用户必须在每次要做什么之前先找到怎么做。
归根结底：对于大部分用户来说，用微软的Word来做日常的写作需要的时候，会涉及到太多噪音，太多选择，太多干扰，和太多困难。最好的结果是，用户无视了那些他们从来不用的界面信息，更坏结果就是，他们在点遍了所有菜单之后还是不知道他们需要哪个。
当然，Word是一个成熟的产品而不是MVP，它给那些产品目标本来就是最大化功能列表的产品提供了一个绝佳的案例。
最后再重复一遍：你不可能涵盖所有的使用情境。现在回头聚焦于体验。
第三个但是：“我们在发版之前必须把APP做完”
完成的观念是创造一个成功的MVP道路上的一个常见的障碍。
仔细想想这种观念通常来自于销售或市场的利益相关者，他们担心一个真正的MVP（一个快速进入市场收集有效数据的优化产品）不完善。
这种担忧是来自于对到底什么创造了吸引人的产品体验，和减轻了产品被人接受的阻力的错误认知。
更多地功能，或者更完善的功能列表并不能导致更多地吸引力，更愉悦的使用体验。只有真正做到了关注核心体验的产品才可以。这意味着你所有的资源都应该聚焦于最核心的、令人印象深刻的、精心打磨的用户体验，为它制定计划、设计和开发。这本身就是一个巨大的工程。
你所有的为了所谓的完成这个产品付出的额外努力都只会导致拖延，和更多的你自己的假设加入进来，让你的目标和你的产品脱节。真正来说，你的产品永远也不可能完成。每当从用户那学到东西，商业规则的改变或者市场的变化，你的产品都需要适应这些并做出改变。你越早开始学习并适应，成功的几率就越大。
你的MVP可能需要削减更多功能
我说出这话其实挺不容易的：你的MVP需要的功能可能比你最开始计划的要更少。
削减产品的功能总是可以从两个维度来提升产品：
1进入市场的时间
2预算
每个功能点的增加都需要花费指数倍的工作来满足，因为它需要每一个利益相关者的投入，包括：
内容
设计
程序
测试
运维
法律
每次你想给你的产品增加点神马的时候你就想想这些吧。
把你的关注点聚焦在体验上
进入市场的时间和预算还不是削减你MVP的最佳理由，他们只是附加好处。
每一个相关人员的努力，都应该从产品的核心体验出发，从产品的最初到最后发版，以及之后的每次迭代，把可用的资源都放在提高产品体验上吧。
不管你是准备增加功能还是调整界面，你都应该经常问自己，你的用户面对你的产品会如何反应，他们能从中得到什么，和如何利用你的产品。
如果有任何损害核心体验的功能，请立即停止改动和发版。当你做较少的功能然后去观察用户何如反应，他们有什么样的举动，然后跟你最开始的假设进行对比，这样你会洞悉的更多。这种洞察力将在你为产品适应市场而奋斗的时候给你最大的红利。
