你的 MVP 既不最小化，也不可行，更不是一个产品

每当我在和产品以及某些业务线负责人讨论MVP产品的设计时，我常常会发现自己陷入了一场令人失望的讨论。草台班子感愈发强烈。MVP 这个词本身就是一个深刻的误用；一个好的 MVP 并不可行，当然也不是产品。仔细想想，它很可能也没有你想象的那么极简。

高度竞争和角逐的商业世界里，必须高度专注于尽快找到失败的方法。理想情况下，你不会失败，这意味着你最终会拥有一个可商用的具有付费意愿的产品和一家正常运转的企业。很多“尝试失败”的方法都涉及审视你的商业机会，并思考你的企业未来可能在哪些方面失败。然后去弄清楚这部分。

如果所有客户都已经乐于使用 eBay，并且不会转而使用其他平台，那么即使你的产品更优秀，打造全球最好的 Beanie Babies 销售平台也毫无意义。如果共享滑板车公司根本不在乎滑板车被盗，那么专门为共享滑板车设计一款出色的锁也毫无意义。如果在你编写任何代码之前，就能确定是否有人会购买你的产品，那就太好了。

那么 MVP 的作用是什么呢？作为一家初创公司，你有一个假设；MVP 是你为证实或推翻你的假设所能做的最少的工作。埃里克·莱斯——没错，就是《精益创业》的作者——曾以 Dropbox 的 MVP 为例。它不是一个功能齐全的产品，也不是一个去掉很多功能的产品。它是一个视频，展示了产品可能如何运作。视频的反响是公司所需要的确认：如果他们制造了它，他们就能为尚未制造的产品找到客户群。所以他们就是这么做的：制造了产品，并获得了巨大的成功。

DropBox 是如何从一款极简可行产品起步的

设计一个好的最小可行产品 (MVP) 意味着要打破常规思维。你能写多少代码？你能不做任何设计吗？如果你最大的问题是能否以合理的获客成本吸引客户，那么你能只做广告和结账页面，然后直接给所有下单的人退款吗？如果这听起来很有趣，但你担心品牌风险，那么你能创建一个虚拟品牌来找到你的产品吗？

诀窍在于仔细思考假设——关于你的产品、市场、你正在涉足的问题领域、你希望吸引的客户以及竞争格局，哪些是必须的？你有多确定你的假设是正确的？设计一个好的最小可行产品是一门艺术，但它始于一个真正好的问题。以下是一些例子：

• 我们能把需要四小时手动完成的会计任务简化成三分钟就能运行的脚本吗？这涉及到技术层面的 MVP 问题——你可能需要修改一些代码，看看能否可靠地实现手动任务的自动化。
• 我们能找到愿意付费让这项任务自动化的人吗？在某些情况下，答案是“不”。是的，你或许能为初级会计师节省一些时间，但在某些行业，人们根本不在乎初级员工在手动任务上花费了多少时间。在这种情况下，你需要确定是否能找到20到30个愿意为此付费的客户。记住，有人说“哦，这听起来是个好主意”和他们真的 掏钱给你是两码事。
• 设计对这个产品重要吗？很多B2B软件丑得令人发指。这并不是因为没有优秀的设计师，而是因为它根本不是优先考虑的事项；产品的实际使用者可能更喜欢更好的设计或更便捷的用户体验，但决策者并不关心，用户也没有发言权。换句话说：如果你找不到商业案例，就不要把一半的开发预算花在提高易用性上。尤其是在你最终无意中开发了错误的功能集的情况下。
• 现有企业会抄袭我们并摧毁我们吗？如果你所在的领域有很多现有企业，不妨做一些研究，看看它们对其他初创企业的反应。如果它们倾向于收购其他初创企业，那很好。如果它们倾向于抄袭其他初创企业的功能和创新，然后将其彻底击败，那就不太好。稍微谷歌一下（当然，还要阅读你所在行业的TechCrunch），可以让你在未来省去很多麻烦。如果现有企业经常窃取创新成果，那就加大对专利的投入，并留出一些资金用于聘请律师。
• 这个功能对我们的客户有意义吗？也许会有一小部分客户大声疾呼要求提供同样的功能，但您肯定不是第一家大张旗鼓地推出新功能却只得到无奈回应的公司。大声疾呼的客户不能代表您的整个客户群，因此请谨慎处理待办事项列表 - 如果某个功能不能为公司的整体业务目标增加显著价值，就不要优先考虑它。围绕此设计 MVP 的一种方法是在 UI 上添加一个按钮并跟踪有多少人点击了它。例如，在用户点击时显示“即将推出！”的消息。是的，这会让用户感到厌烦，但这比花费几个开发周期添加一个几乎没人会使用的功能“便宜”得多。

简而言之，关键在于仔细思考问题是什么，然后想出优雅、低调的提问方式。与其发送代码，不如做个调查问卷？一个视频演示能找到你需要的答案吗？你能打电话给 50 位客户，问他们一些谨慎的问题，看看他们是否会建议你正在考虑的功能作为问题的潜在解决方案吗？他们可能会以两种方式让你感到惊讶：你的客户要么非常想要你建议的东西（很棒！），要么讨厌它（也很棒——这意味着你不必浪费时间和金钱开发他们不想要的东西），要么他们可能有完全不同的解决问题的方法，这种方法恰到好处，开发成本更低，还能让他们感觉自己参与到了你的流程中。

我对MVP的名称没什么好建议，只是不要掉入“把它当成一个产品，可行，或者必然是小巧、简单、易用”的陷阱。有些MVP很复杂。不过，我们的想法是，尽可能少地投入宝贵的资源来获得问题的答案。