MVP 没有任何问题
本文信息来源：focusedchaos
MVP 的定义几乎被扭曲得面目全非。但我仍然认为这个概念非常有效。 (#43)
MVP = 最小可行产品
这个术语已经存在了十多年。随着时间的推移，它的定义不断变化，甚至让我们迷失了方向。
现在有太多的变体或替代说法，根本无法弄清楚到底发生了什么。我得承认，我忽略了大多数这些选项，因为在我看来，MVP 这个术语非常合理。
每个人都讨厌 MVP。😢
《Running Lean》（及其他著作）作者 Ash Maurya 最近表示 ，“我正在放弃 MVP。”（顺便说一句，Ash 的书和内容非常棒，你应该去看看 。）
我看到许多博客文章和推特讨论建议人们完全放弃这个概念。
为了您的阅读乐趣，这里有一些人说 MVP 应该被淘汰。他们提出了一些有力的观点，但我发现自己被替代方案的复杂性所淹没。
- 我已经放弃了“MVP” – 作者 Richard Mironov
- 产品存在语言问题。我们需要解决它。 – 作者：Saeed Khan
- 也许我们不该发布 MVP，而该发布 SMURFS – 作者：Matthew Barcomb
SMURFS？认真的吗？🤭
这是我回复的一条推文，表达了对 MVP 消亡的惋惜，但其他人纷纷加入，建议应该废除这个概念：
简单定义 MVP： 产品的最简版本，能够让你 – 验证你的重大假设 – 并获得有意义的用户反馈 我说得对吗？
MVP 已经过时了。
它们到底做了什么？
没有错，但人们误解并滥用了这个术语和概念，以至于他们（a）提出了替代方案；和/或（b）完全放弃了这个术语/概念。
我要说了：我爱 MVP。😍
随着时间推移，出现了多种定义，这确实令人困惑。词语很重要，我们如何定义事物，也很重要。我理解这一点。但我看过许多提出的替代方案，它们往往同样令人困惑，甚至更甚。
所以我分享一下我对 MVP 的定义，以及我认为正确构建 MVP 所需的条件。希望对你有帮助！
什么是 MVP？
MVP 是证明你已经解决了用户或客户问题所需的最小产品版本。
现在让我们来看一下如何实现这一目标……
1. 一切都以验证问题为基础
如果你对问题没有深入了解，很难做出好的 MVP。
你需要通过用户调研来验证问题，深入了解用户的需求。你所做的用户调研很可能包括访谈、观察用户，以及构建刺激物和原型来测试具体假设。
我之前写过这些内容，你可以按照以下步骤进行：
- 步骤 1： 你怎么知道自己解决的是一个重要的问题？
- 步骤 2： 如何在不成为狂热者的情况下将科学方法应用于初创企业
- 步骤 3： 先测试，后构建：用刺激和原型验证你的想法指南
关键是要认识到你还没有在构建 MVP。 刺激和原型不是 MVP，它们是你用来测试高风险假设的快速、一次性工具。例如，许多初创企业会制作登陆页面来测试价值主张和早期转化率。这完全合理。但登陆页面不是 MVP，因为它无法解决用户的问题。
某个时候，出现了“RAT”这个术语，意为“最高风险假设测试”。
RAT 最初由 Rik Ingram 提出 ，作为 MVP 的替代方案。Ingram 认为，“与其构建 MVP，不如识别你最具风险的假设并进行测试。用 RAT 替代 MVP 可以为你省去很多麻烦。”
我非常相信首先验证你最具风险的假设，并且在不构建 MVP 的情况下进行。这就是为什么你要采访和观察用户，然后使用刺激材料和原型进行测试（这些最终都会在完成学习目的后“被丢弃”）。
假设追踪工具：
这是一个免费假设追踪工具 （Google 表格），你可以用它来帮助评估、优先排序和追踪假设（以及你为验证这些假设所进行的实验）。
一旦你构建了 MVP，你仍在测试你最具风险的假设——这一点不会改变，这也是为什么 RAT 不能取代 MVP 的原因。
对于大多数人来说，最具风险的假设是问题的严重程度。 这个问题对某个特定群体来说是否足够痛苦？ 理想情况下，你应在构建 MVP 之前（以高度的信心）验证这一点。
在设计思维的术语中，这被称为“可取性”。在 JTBD 理论中，你会说，“我需要证明存在一个尚未被妥善解决的待完成任务。”
你的最具风险的假设也可能是关于可行性或可持续性（同样使用设计思维的术语），在这种情况下，你必须在构建 MVP 之前验证这些方面。
- 吸引力： 有人真正关心吗？ 你需要寻找未被满足的需求、待完成的任务以及人们正在经历的痛点。
- 可行性： 能否建成？ 这可能意味着存在技术挑战，或者可能涉及法律、监管或合规相关的问题。
- 可行性： 我们能赚钱吗？ 这里的 “可行” 并不是指 MVP 中的“可行性”（我理解这容易混淆）。在此语境下，可行性指的是商业模式、市场规模以及该想法/业务的整体财务潜力。
如果你有足够的信心验证了一个可识别的用户/客户群体的问题，你就可以继续前进。
在《精益分析》中，这意味着从同理阶段进入粘性阶段。 你已经发现了一个真实且未被充分满足的需求，且该需求存在于一个可触达的市场，现在是时候构建解决方案，看看它是否有效。
2. 定义你将如何证明问题已被解决
你需要满足什么条件，才能确定你已经解决了验证过的问题？
在开始构建任何东西之前，先弄清楚这一点。
许多创始人因为急于开发而跳过这一步。但如果不知道“成功”的定义，你就有可能构建错误的东西（包括构建过多），而且无法判断。
“赢”在这个阶段=使用率（或粘性）。
你能打造一个有粘性的产品吗？ 如果能，那么合理地假设它正在创造价值。
“粘性”的定义由你决定。我通常从日活跃用户（DAU）、周活跃用户（WAU）或月活跃用户（MAU）开始思考。 你的解决方案是期望人们每天、每周还是每月使用的？
- Instagram 和 Slack 是日常使用应用的好例子。
- 杂货店应用是一个很好的每周使用场景（很多人每周买一次杂货，而不是每天或每月）。
- Xero、Quickbooks 或记账应用是很好的每月使用案例。你可能更频繁地使用它们，但月末的使用量更大。
有些应用程序既有每日使用场景，也有每月使用场景。如果你遇到这种情况，你需要提前了解这一点。Expensify 是员工每天或每周用来报销费用的工具，但簿记员或会计师可能只会每月进行一次对账。
一旦你确定了使用频率，就要弄清楚用户在你的产品中会做什么。 他们将如何使用你的产品来解决他们的问题？
注意：你可以在构建任何东西之前先进行一些测试。你可以制作一个可点击的原型来模拟使用过程，并带领潜在用户/客户体验整个过程。你还可以与用户/客户一起举办共创工作坊，以获取他们感兴趣的功能信息。人们不擅长为自己的问题设计解决方案，但他们仍能为你提供见解，让你一窥他们的世界。
我喜欢问，“我的产品核心是什么？创造价值的最基本的参与单元是什么？”
阅读更多关于如何定义产品的核心或本质 。
尼尔·埃亚尔的“上瘾”模型是思考这一问题的绝佳方式：
以下是一些你可以提出的问题，用以定义产品的核心功能，解决用户的问题并创造价值：
- 你希望用户在产品中做什么，以驱动对他们自己或他人来说虽小但有价值的参与循环？用户能多快完成你希望他们做的事情？你确定这些参与循环是有价值的吗？（阅读这篇本·威廉姆斯关于参与度的文章 。）
- 用户从您的产品中获得价值有多容易？他们多快能获得这种价值？您能否让这个过程更简单和/或更快？
- 为什么有人会首先使用你的产品？价值主张是否足够清晰，能够激励人们尝试？
- 用户在使用你的产品之前在做什么？ 如果你了解这一点，可能会找到合适的触发点来吸引他们，更快地引导他们进入产品的核心。
- 用户在使用你的产品之后在做什么？ 这有助于你理解如何引导用户在你的产品和他们旅程的下一步之间转换。未来你可能会扩展到这些使用场景。
- 商业模式（或预期的商业模式）是否推动了用户更多地参与产品核心？ 如果人们按照预期使用你的产品，并从产品核心中受益，这是否足以让你实现盈利？ 使用应当为用户和你带来价值。如果你知道你的商业模式是什么，就能判断用户/客户的使用情况是否能推动该商业模式。例如，抖音的商业模式是广告，依赖于尽可能多地吸引注意力。抖音所做的一切都是为了留住用户的目光。
在构建之前，你需要定义：
- 产品将如何被使用（即人们会做什么）。核心是什么？
- 产品将被使用的频率（即使用频率）。除了日活跃用户（DAU）、月活跃用户（MAU）、周活跃用户（WAU）之外，你还需要了解特定功能的使用频率及其顺序。你需要理解客户在产品中的旅程以及你试图创建的“行为循环”。
把这些内容写下来。你可以使用产品需求文档（PRD）来帮助理清各个组成部分。这里有三个示例：
- 我的产品需求文档模板
- Lenny Rachitsky 的产品需求文档模板
- Kevin Yien 的产品需求文档模板 （更复杂，但非常适合深入研究）
我们现在有了用户/客户问题， 为产品最小版本定义了范围，并且划定了“底线”，说明我们将如何验证它 。从技术上讲，我们已经定义了 MVP 的所有部分。
这里是定义：MVP 是证明你已经解决了用户或客户问题所需的最小产品版本。
接下来：让我们开始打造这个东西，看看会发生什么！
3. 构建与发布 MVP
为了证明你以有意义的方式解决了问题，你需要通过粘性阶段：
让我们来拆解一下：
- “用户会采用” — 我们已经定义了产品的预期使用情况，因此可以进行衡量。
- “持续使用” — 使用必须保持一致，否则问题未得到解决。用户会流失，但如果流失率过高，就说明有问题。如何定义“持续使用”比较棘手。但通常需要几个月的数据，才能确认你达到了所需的参与度。
- “付费” — 用户掏出信用卡是一个很好的信号。但这并不是人们“付费”的唯一方式，他们也通过注意力和数据进行付费。
这三者共同代表了“最小可行产品”中的“可行性”。
很多人对 MVP 这个词的困惑在于“V”代表的可行性。我理解。可行性到底是什么意思？
Andrew Chen 建议我们使用“最小可取产品”（Minimum Desirable Product），因为“可行性”往往过于关注商业层面。也许如此，但正如我所说，可行性意味着人们会使用它（且不会放弃），并且存在价值交换（即你提供产品，他们愿意以金钱、关注或数据作为回报）。
通过粘性阶段类似于问题-解决方案匹配。
问题-解决方案匹配是另一个被多种方式定义、让人困惑的术语，但这是我的看法：
你已经验证了一个问题并构建了解决方案。你知道这个解决方案能够解决问题，因为有一批客户在使用该产品，告诉你他们获得了价值，愿意为此付费，且流失率很低。你还没有从早期采用者转向后期采用者，下一步是确定是否能够扩大客户获取规模。
要知道你的 MVP 是否正确，你必须证明其价值。 你可以通过定量测量使用情况（基于你的定义）和定性地与用户/客户交流来做到这一点。
MVP 必须是一个真正的产品。它不能只是一个为了学习而设计的实验，不能没有提供价值。这并不意味着 MVP 不是为了学习而设计的实验（它确实是），但它必须是人们可以使用的东西。而且它不能糟糕到几乎不可能带来价值。
这个术语是 MVP，而不是 MSP（代表“最低劣产品”——谢天谢地，还没人建议我们改用这个！）
如果你认为可以通过发布糟糕的产品来快速学习，那就再想想吧。没人会使用你糟糕的产品。没有使用，就没有学习。（除非你学到了自己做的东西很糟糕。）
Jason Cohen 建议放弃 MVP，改用 SLC（简单、可爱、完整）。 我喜欢 SLC，这与我对 MVP 的看法非常接近，尽管“可爱”这个词有些牵强。我使用很多喜欢和享受的产品，但并不爱它们。我用 WhatsApp，但我爱它吗？耸耸肩。它对我来说已经足够好了。我用 Facebook 市场卖东西，但我并不爱它。简单也很难定义。有些东西需要一定程度的复杂性，可能不符合 SLC 的定义，但可以符合 MVP 的定义（证明价值所需构建的最小产品可能“很多”）。
我理解大家对“MVP”这个词的困惑。有些人会认为它可以是一个登录页面、广告测试或其他不是真正为用户创造价值的产品。 这种对 MVP 的定义是错误的。 但这种误解已经广泛存在，导致了极大的混淆。
我对 MVP 的定义对我来说是有效的。所以我会继续使用它。它不一定适合所有人，这没关系（虽然我知道这并不能解决所有的困惑！）
我整理了一个关于如何思考、定义和构建 MVP 的视觉总结/框架。希望你觉得有帮助！
