什么是TMD的MVP(最小可行性产品)?

Jan 25 2021

扫描二维码

No, 今天我们说的不是詹姆斯。

而是

Minimum Viable Product(MVP) – 最小可实行产品

这张图很流行，在很多地方都能看到。很多人也是看完之后会心一笑，但却很少人真的能遵循这样的MVP原则来开发自己的产品。下面我们就来解释下图片背后到底是在说什么？

第一种示例：错误的方式

第一排的图片是错误的方式开发产品

很多的项目的失败是因为直到产品100%完成之后才发布。然而，人们普遍会产生疑问-谁会花钱买个半成品？

“先生，这是我们的第一个版本的产品，一个轮子，你觉得怎么样？”

用户肯定会说“你为什么给我的是一个车轮子？我要的是一辆汽车！你让我那个车轮子当独轮车吗？”

当每次的产品接近完成的时候，用户会很生气的使用你的产品。因为这些只是车零件的一部分。

在这个例子里，用户最终很高兴得到了他的汽车。但现实情况却往往不是这样的。过程中，大部分时间里是没有经过用户的使用测试的，最终做出来的产品很可能不是用户需要的。所以，这个笑脸只是理想中的情况。

不管怎样，第一排的过程是错误的。理论上是渐进迭代式的，但是由于缺少实际的反馈，因此风险很大-而且并不灵活。

第二种示例 - 应该是这样

现在我们来用不同的方式。我们还是同样的需求 - 用户订购了一辆车。但是这次我们不仅仅是造一辆车。取而代之的是我们以满足用户潜在需求为出发点。事实证明，他的基本需求是“我需要更快地从A到达B”，而汽车只是解决这一问题的一种可能。汽车只是一个隐喻，你可以认为是任何一种定制产品的开发情况。

因此，团队应该提供他们能想到的最小的东西，从而使客户进行测试并得到反馈。有人可能将其称为MVP（最小可行性产品），但将其称为最早可测试产品更贴切。

随便你叫它什么（根据这个隐喻……有人称他们的第一个版本为产品的“滑板版本”）。

客户不太可能对此感到满意。这离他订购的汽车很远。没关系！这是关键-目前我们不希望使客户满意。我们可能会让一些早期使用者感到高兴，但目前我们的主要目标只是学习。理想情况下，会事先向客户明确说明这一点，因此用户也不会太失望。

但是，与第一种情况中的车轮不一样，滑板实际上是一种可用的产品，可以帮助客户从A转到B。虽然不是很好，但总比没有好。因此，我们告诉客户“不用担心，项目尚未完成，这只是许多迭代中的第一个。我们仍然打算制造一辆汽车，但与此同时，请尝试一下并希望给我们反馈。”大胆思考，但以实用可行性的产品迭代交付。

我们可能会学到一些真正令人惊讶的东西。假设客户说他讨厌滑板，我们问为什么，然后他说“我讨厌颜色”。我们就像“呃…。颜色？就这样？”。客户说：“是的，把它变蓝！除此之外，还可以！”。

关键问题是“我们开始思考最便宜，最快捷的方式是什么？” 我们能比滑板早交付一些东西吗？汽车票可以吗？

这会帮助解决客户的问题吗？也许（也许不是），但是我们一定会通过将其交到实际用户手中来学习一些东西。精益创业提供了一个很好的模型，该模型基于列出有关用户的实际假设，然后系统地进行验证。

你不需要在所有用户上测试产品，也不需要构建产品来测试某些产品。即使在单个用户上测试原型，也将教给你更多的知识。

但是，回到滑板示例。

在办公室里玩了一会滑板之后，客户说：“好吧，很有趣，它的确使我更快的去到咖啡机旁边。但这很不稳定。我太容易掉下来了。”

因此，下一次迭代我们将尝试解决该问题，或者至少了解更多有关它的信息。

客户现在可以在办公室附近闲逛而不会掉下来！

用户快乐吗？并非如此，他仍然有点想要那辆车。但与此同时，他实际上正在使用该产品，并向我们提供了反馈。他最大的抱怨是，由于车轮小且没有间断，很难在建筑物之间走更长的距离。因此，下一次发布时，产品变成了自行车。

现在，客户可以在建筑物之间进行活动。 Yiihaaa！

我们在这个过程中了解到了一些东西：客户喜欢新鲜空气的感觉。客户主要是在建筑物之间四处走动。

自行车可能比最初设想的汽车是更好的产品。实际上，在测试该产品时，我们可能会发现对于汽车而言，路径太窄了。我们只是节省了客户大量的时间和金钱，并在更少的时间内为他提供了更好的产品！

现在你可能在想：“我们可以通过对客户背景和需求的前期分析？”想法不错，但是在我所见过的大多数实际产品开发场景中，无论你进行了多少前期分析，当将第一个实际发行版交到真实用户手中时，你仍然会感到惊讶，而且跟你想象的甚至完全相反。

是的，进行一些前期分析，在开始开发之前尽可能多地发现问。但是，不要花太多时间在上面，也不要过于相信分析 - 开始进行原型设计和发布，这是真正的有价值的东西。

无论如何，回到故事。也许客户想要更多。有时他需要去另一个城市，而自行车骑行太慢且出汗。因此，在下一次迭代中，我们添加了一个引擎。

该模型特别适用于软件产品，因为软件很“软”。可以随时随地“变形”产品，而不是每次都必须重建硬件。但是，即使在硬件项目中，提供原型来观察和学习客户如何使用你的产品也有巨大的好处。只是迭代趋向于更长一些（几个月而不是几周）。甚至像丰田和特斯拉这样的实际汽车公司在开发新汽车模型之前也进行了大量原型设计（草图，3D模型，全尺寸粘土模型等）。

那么现在怎么办？同样，也许顾客对摩托车感到满意。我们可以比计划提前结束项目。大多数产品到处都是没人使用的复杂性和功能。迭代方法实际上是一种更少交付，并用最简单的、便宜的方法解决用户问题。从而不断的趋向于完美。

再一次，客户可以选择是否继续修改需求而继续。实际上，我们最终可能会得到与最初设想的完全相同的汽车。但是，在此过程中，我们会获得重要的见识，而最终得到一些稍有不同的东西。像这样：

顾客喜出望外！为什么？因为我们过程中了解到他喜欢新鲜空气，所以最终得到了一辆敞篷车。毕竟他确实得到了一辆车，但是比原先计划的要好！

因此，让我们思考一下。

”你的滑板是什么？“
最上面的情景（轮胎的交付方式）很糟糕，因为我们一直在交付客户根本无法使用的东西。除非你知道自己在做什么-你的产品几乎没有什么复杂性和风险，也许你已经完成了数百次此类工作-然后从头再来，在一切准备就绪之后交付。

但是，我见过的大多数产品开发工作都过于复杂且冒险，”完美的产品”方法经常导致巨大的昂贵失败。所以关键的问题是你的“滑板”是什么？

在产品开发中，应该做的第一件事（在描述了您要为谁解决的问题之后）是确定你的滑板对应的产出对象。可以将滑板视为比喻为最小的东西，你可以将其交给实际用户并获得真实的反馈。

这将为你提供急需的反馈循环，并为你和客户提供对项目的控制权-你可以过程中不断学习和进行更改，而不仅仅是遵循计划并希望最终会有一个好结果。

让我们来看一些真实的例子。

例子1：Spotify音乐播放器

Spotify现在是一款非常漂亮的产品。但开始不是这样的。

作为2006年的一家初创公司，Spotify的建立基于一些关键假设：人们喜欢流媒体音乐，唱片公司和艺术家希望人们合法地使用音乐，并且从技术上来说，快速稳定的流媒体是可行的。记住，这是在2006年，当时播放器（如Real Player）是一种非常糟糕的体验，而盗版音乐随处可见。挑战的技术部分是：“当按下‘播放’按钮时，是否有可能使客户立即播放音乐？是否有可能摆脱令人讨厌的‘缓冲’进度条？”

从小处开始并不意味着你不能从大处着想。这是他们构想的早期草图之一：

Spotify没有花非常多时间在打造一个完整的产品，从假设是否成立出发，坐下来来并Hack了一个技术原型，放入笔记本电脑上的任何翻录音乐，然后开始进行疯狂的实验以寻找方法来使播放快速稳定。交付指标是“从按下播放到听到音乐需要多少毫秒？”。效果是它应该立即播放，并继续流畅播放而不会出现卡顿现象！

“我们无聊地花了很多时间来关注延迟，因为没人关心，因为我们一心想让你感觉硬盘上拥有世界上所有音乐。对小细节的痴迷有时会使一切变得不同。我认为这是对最小可行产品概念的最大误解。这就是MVP中的V。” -Daniel Ek，Spotify联合创始人兼首席执行官

一旦他们有了能看的过去的东西，他们就开始对自己，家人和朋友进行测试。

最初的版本无法发布给更多的听众，它完全没有打磨，除了能够找到和播放一些硬编码的歌曲外，基本上没有其他功能，也没有法律协议或商业模式。那是他们的“滑板”。

但是他们无耻地将滑板交到了真正的用户（朋友和家人）手中，他们很快就得到了所需的答案。是的，这在技术上是可能的。是的，人们绝对喜欢这个产品（或更喜欢这个产品将来的样子）！假设得到验证！这个运行中的原型帮助说服了音乐唱片公司和投资者。

例子2：LinkedIn

LinkedIn于2003年5月5日成立，创建于联合创始人Reid Hoffman的客厅。在一个月内，有4,500位用户注册。现在，它已经被微软收购，在全球拥有5亿名用户。而这是他们的第一个版本。

例子3：Facebook

Facebook在全球拥有19.4亿用户，这是地球上最受欢迎的社交网络，另外还有两个主要平台Instagram和WhatsApp。创始人马克·扎克伯格（Mark Zuckerberg）于2004年在哈佛大学的宿舍里和几个朋友一起创立了Facebook。早期的版本看起来并不像每天使用的Facebook一样多，但足以吸引纽约广告公司和硅谷投资者的注意力。