如何避免 MVP 的陷阱

创造一个成功的MVP不仅仅是为了构建一个能够大开眼界的产品，更重要的是如何把一件小事情做好。

几年前，一个新的音乐订阅产品以改变音乐流行方式为目标亮相了。事实上，音乐类产品历经了几十年的起起伏伏，免费下载音乐的这类产品兴起（如Napster，Pandora和Spotify）加剧了这种形势：音乐家的努力付出没有得到同等的报酬，粉丝只想听喜欢的音乐，而不是要掏空钱包，每三分钟就听一次广告。

2014年10月，在众人的期待中，Tidal这个平台在美国，英国和加拿大发布了。这个平台得到了行业的大佬支持（如Jay Z， Beyonce，Rihanna，Madonna和Kanye West），主打粉丝们渴望的无广告，高品质，独家的音乐，准备掀起行业的一场革命。

但这场万众瞩目的变革迟迟未来。

两年多后，Tidal还在为存活问题而挣扎，更不用说去改变整个行业现状，甚至是那些最执着的音乐爱好者，乐评人和艺术家本身都打算放弃它了。其订阅量仍远远低于Apple Music和Spotify，短短8个月第三个CEO就上任了，Tidal需要做出一些重大调整，不然其前景堪忧。

到底发生了什么？为什么Tidal没有在大家的期盼中成功？什么因素阻碍了它的发展？

虽然导致其失败的原因有很多，但问题的核心还是在于它错误的MVP。

MVP（最小可行性产品）这个理念最先是由Frank Robinson提出的，20世纪90年代，Steve Blank 在其“客户发展方法”( Customer Development methodology )中进一步推广了这个理念，到21世纪初，它在Eric Ries的精益创业运动中被大家所熟知。Ries将MVP定义为产品发现过程中的一个阶段：“让团队以最少的投入去收集最多的客户信息的产品。”

这个概念吸引了设计师和开发人员，特别是随着科技行业的蓬勃发展，产品开发的门槛降低。它为产品设计人员提供了一套框架，可让新产品快速上市。开发人员和营销人员也能够快速推出一个精简产品，用真实客户进行测试，并测量其在市场上的成功，而不需要先构建一个完整的解决方案。

随着行业逐渐接受MVP的概念，他们开始尝到甜头：节省时间，节约成本，迅速获得反馈。但随着时间的推移，一个新问题出现了：我们其实误解了MVP的定义和意图。

现在，MVP变成许多设计师，开发人员和产品经理懒惰的借口。他们以“保持精益”和“快速产出”的名义偷工减料，移除功能，牺牲用户体验。

也许是因为MVP一开始就被错误地定义，我们一直误认为“MVP”指的是产品只需要最少功能去解决市场的主要问题。

MVP必须具备几个关键特征：

你的产品必须以一种独特的方式为一个真实的用户解决至少一个真正的问题。否则，用户没有任何理由对你的产品做出反应，投入情感，使用产品或提供反馈。

毕竟MVP只是一个实验。作为产品设计师或开发人员，你可以进行可用性测试，看看你提出的假设是否准确。如果上述四个特征缺失其中任何一个，测试结果将会出现偏差，从而导致决策偏差和潜在的产品问题。

限制MVP时间表也是至关重要的。设计师和开发人员有喜欢“修修补补”的职业习惯，产品可以进行无数次迭代，但客户反馈就像货币，你一天不把产品投放到市场上去收集信息，你在产品发现和开发方面亏得越多。

常见的误解是MVP指精简产品，从而快速地、低成本地推出产品。这个功能还要不要呢？不要算了。UX设计？没有时间去考虑，管用就行。代码？先快速写出来，之后再去修bug。

这种方式不但不会让产品获得成功，这正是产品失败的原因。最有效的MVP在代码，设计，UX和内容方面仍然保持高质量标准。他们只是限制了范围。

要确定你的MVP时，请考虑这些问题和做法。

定义目标市场是产品发现的第一步。这个市场是由你最想要的，并有能力帮助他们解决问题的用户组成。在限定你的目标市场时，问问自己和团队以下问题：

无论你是对现有产品进行迭代，还是创建全新的解决方案，它必须满足用户的某一类需求。JTBD可能是用户想“雇用”你的产品或解决方案去完成一项任务或激励他们购买你的产品的目标（情感，社会，个人等）。

确定你产品的JTBD涉及到以下几个方面：

要获得成功的MVP，你得认真研究目标用户“雇用”你的产品达到的一个目的，描述中有确定的目标，一套核心理念和想法也有助于集中团队的力量设计出更有意义的体验。陈述问题时要考虑一下几点：

将所有这些要素（目标市场，JTBD，目标等）总结为一个简洁易懂的短语，制定一个问题陈述，这个问题陈述将是你的团队在开发和产品管理过程中的指南。

有了一个问题陈述后，你的团队可能会有几十个，甚至数百个对MVP潜在功能的想法。要确定这些功能的优先级顺序，并确定哪些功能保留，哪些功能舍弃，可以使用“用户故事”的做法。

在整个产品发现，设计和开发过程中，新功能和想法必将出现。你可以使用问题陈述和用户故事做法来评估这些功能请求的优先级，但当其他所有功能都被否时，这时可以提出一个关键问题：

“没有这个功能我们也可以发布吗？”

请记住，这个问题应该从用户的角度回答，而不是开发者或设计者的角度。对用户而言最低价值功能是什么？如果我们发布时没有这个功能，我们还能解决他们的主要问题吗？

如果答案是“是的”，那么就可以这个功能移除。如果答案是否定的话，那就得评估添加这个功能将需要什么。会不会超过预算？是否符合当前时间表？这是艰难的决定，成败在此一举。

像任何项目一样，MVP很少按计划进行。工作需要比预期花的时间更长…预算减少或投入到在其他方面…高管不批准整个项目。

总是有新原因导致产品推迟发布，所以关键在于如何创造性的找到方法来解决问题。以下这些方法是一些公司成功解决这些常见问题使用的。

许多app和产品依靠自动化来简化现有流程，并节省用户时间。然而，这种自动化需要时间和资源来构建。

有时MVP中可以包含不扩展的功能。这些功能可能看起来违背直观原则，但可以在后台手动继续完成一个过程（同时用户认为是自动化的），这种做法仍然增加了价值，而不会增加额外的开发时间和费用。

例如，许多产品引入一大堆数据，分析数据，并向用户发送报告，使信息更容易查看和理解。理想情况下，这个过程是自动化。但它必须一开始就是自动化的吗？不是的。

事实上你的产品可以让用户导入或添加他们的数据，然后屏幕上显示“您的报告将在12个小时内发送到您的收件箱”。用户会觉得整个过程是自动化的，而你的团队可以在后端手动完成此过程。

（编辑：ASP站长网）