您的 MVP 路线图有 47 个功能。您确信每一项都是必不可少的。这种信念可能会杀死你启动。
这是没人告诉你的：根据 Pendo 对数百家软件公司的使用数据进行的分析，普通产品中 80% 的功能很少或从未使用过。 Standish Group 也发现了类似的结果，指出只有 20% 的软件功能经常使用，而 50% 的功能几乎从未接触过。
您计划构建的内容比用户实际关心的内容多五倍。那不是野心。在你学到任何有用的东西之前，这是一个让你在跑道上燃烧的秘诀。
“一个用户，一个问题”方法翻转了这个脚本。而不是问“我们应该构建什么功能？”你从一个不同的问题开始：“我要为谁解决问题，我能为他们解决的最痛苦的事情是什么？”
这种方法帮助我共事过的创始人将最初的范围缩小了 60% 或更多，在几周而不是几个月内发货，并在保持盈利的情况下达到产品与市场的契合。
为什么大多数 MVP 在推出之前就失败了
CB Insights 分析了 2023 年以来倒闭的 431 家由风险投资支持的初创公司。研究结果应该让每一位创始人都停下来。虽然 70% 的人将“现金耗尽”视为死亡原因，但这只是症状，而不是疾病。真正的凶手是？产品与市场契合度不佳（43%）、时机不佳（29%）以及不可持续的单位经济效益（19%）。
请注意一些有趣的事情：这些公司在失败之前总共筹集了 175 亿美元。该数据集中初创公司筹集的资金中位数为 1100 万美元。钱不是问题。焦点是。
倒闭的公司并不是因为建设太少而失败。他们之所以失败，是因为他们长期构建了错误的东西。
大多数创始人将 MVP 视为其完整愿景的缩影。他们查看 50 个功能的路线图，并尝试将 25 个功能压缩到“最小”产品中。这还不是最低限度。这还是太多了。
根据行业数据，平均 MVP 的构建平均需要三到四个月的时间。 Y Combinator 和 Techstars 发现，成功的初创公司通常会在构思后两到三个月内推出他们的第一个 MVP。您添加的每一项额外功能都会让您远离该窗口。
残酷的事实是：三分之二的产品与市场契合失败发生在从未找到市场的早期公司。他们在寻找真正想要他们正在建造的东西的人的同时，已经耗尽了时间和金钱。
框架：一个用户，一个问题
“一个用户，一个问题”方法让您在编写一行代码之前回答两个问题，从而实现彻底的简单性。
问题一：谁是唯一的人？
不是“关心可持续发展的千禧一代”。不是“小企业所有者”。一个你可以真正与之交谈的特定的、真实的人。
这可能是莎拉 (Sarah)，她是丹佛的一名独立会计师，每周花 12 个小时收集客户文件。或者，马库斯 (Marcus) 是奥斯汀的一名餐车车主，他每月损失 400 美元，因为他无法预测原料需求。越具体越好。
当您使用时定制 MVP 开发服务，这个用户特异性成为你的北极星。每个功能决策都通过简单的测试进行过滤：这是否解决了 Sarah 的文档追踪问题？如果不是，则它不属于 v1。
问题2：什么是ONE问题？
不是三个问题。不是一组相关的痛点。一件让用户的生活明显变得更糟的事情，他们现在正在积极尝试解决。
最好的问题具有三个特征：
- 频率：问题发生的频率足以产生影响。某人每年经历一次的痛点并不足以紧急到需要解决。
- 强度：当它发生时，它真的很痛。他们失去了时间、金钱、名誉或睡眠。
- 目前的努力：他们我们已经尝试通过电子表格、手动流程或管道胶带解决方法来解决这个问题。
如果你能做到这三点，那么你就找到了值得构建的东西。
如何实际削减 60% 的路线图
一旦确定了“一个用户”和“一个问题”，就该审核您的功能列表了。这是大多数创始人感到拘谨的地方。感觉一切都很重要。似乎没有什么是可以切割的。
这是有效的过程：
第 1 步：写下您计划的每项功能。
把他们都赶出去。集成、仪表板、通知系统、管理面板和报告工具。一切。
第 2 步：对于每项功能，询问：“这是否可以直接解决我的一个用户的一个问题？”
不是“有一天这会有用吗？”不是“这在演示中看起来会令人印象深刻吗？”它是否直接解决了您确定的核心痛点？是还是不是。
第三步：分类��三个桶中。
- 核心（直接解决一个问题）
- 支持（使核心更好地工作）
- 锦上添花（其他一切）
说实话。大多数创始人发现他们计划的功能中有 70-80% 属于第三类。
第 4 步：仅发布 v1 中的核心功能。
您的第一个版本不应包含“必备品”中的任何内容以及来自“支持”的最少项目。如果您无法用一句话解释一项功能如何解决“一个用户的一个问题”，那么它就不会发布。
这就是实际情况。一位为私人教练开发日程安排应用程序的创始人向我提供了这个初始功能列表：
- 与 Google、Apple 和 Outlook 同步日历
- 客户管理仪表板
- 通过短信和电子邮件自动提醒
- 付款处理
- 客户进度跟踪
- 锻炼计划生成器
- 营养记录
- 应用内消息
- 视频通话集成
- 分析仪表板
应用“一个用户，一个问题”过滤器（一个用户：名为 Jake 的独立私人教练，因为忘记预约而失去客户；一个问题：由于日程安排混乱而错过了课程），v1 变为：
- 带有会话预订的简单日历
- 提前24小时自动短信提醒
就是这样。两个特点。 MVP 在六周内交付。杰克与他的实际客户进行了测试。错过的会议减少了 40%。直到那时，创始人才开始在真实使用数据而不是猜测的指导下添加功能。
心理陷阱：创始人为何过度建设
了解我们过度范围的原因有助于防止这种情况发生。三种心理力量对创始人不利：
竞争错觉。您看到竞争对手拥有功能丰富的产品，并认为您需要与他们匹配。但这些功能是多年来建立的，由你还没有的收入资助。在 MVP 阶段争夺功能就像一个高中生试图超越一个职业运动员。不同的体重级别，不同的比赛。
投资者间距失真。您已经向投资者讲述了您的宏伟愿景。现在感觉你需要建造一切来验证他们对你的信任。但优秀的投资者知道愿景和 v1 之间的区别。他们押注于你的学习和适应能力，而不是你在第一天发布完整产品的能力。
对渺小的恐惧。拥有两项功能的 MVP 感觉很尴尬。这似乎太简单了，不值得认真对待。但 Dropbox 在构建任何东西之前都通过视频验证了其整个概念。 Buffer 推出时带有登陆页面和定价表。 Zappos 最初是手动从商店购买鞋子并将其运送给顾客。较小的第一个版本是一个功能，而不是一个错误。
验证循环：发货后会发生什么
缩小范围并不是终点。这是真正有效的学习周期的开始。
有了专注的 MVP，您可以在八到十二周而不是六个月内启动。这种速度优势更加复杂。您开始收集真实的用户数据，而竞争对手仍在争论应在其规范文档中包含哪些功能。
验证循环如下所示：
- 将您的核心功能交付给与您的单一用户配置文件匹配的一小群用户。
- 观察他们实际做了什么。不是他们说的那样。他们实际上做了什么。
- 衡量问题指标。如果您要解决“错过的约会”问���，请跟踪错过的约会率。如果您要解决“手动数据输入浪费时间”的问题，请衡量节省的时间。
- 基于行为进行迭代。仅当用户证明他们已经最大限度地发挥了您已构建的功能的价值时才添加功能。
这种方法可以防止初创公司建设中最昂贵的错误：投入数月时间开发无人使用的功能。
实数：缩小范围实际上节省了什么
让我们具体了解一下数学。
具有 15-20 个功能的典型 MVP 需要四到六个月的时间，成本为 50,000-150,000 美元，具体取决于团队组成和地点。具有三到五个核心功能的专注 MVP 需要六到十二周的时间，成本为 15,000 到 40,000 美元。
这不仅仅是节省成本。这样可以节省时间，为您提供三到四个月的额外迭代时间，营销，并找到产品与市场的契合度。
考虑机会成本。如果你花了六个月的时间来构建，然后才知道是否有人想要你的产品，而答案是否定的，那么你就损失了半年的时间和大部分初始资本。如果你花了八周的时间进行构建并吸取了同样的教训，那么你仍然有时间和金钱来进行调整。
幸存下来的初创公司是那些能够在现金耗尽之前运行多个学习周期的初创公司。缩小范围并不是减少建设。这是为了更快地学习。
您削减太多的迹象（以及如何解决）
严格的专注和运送无用的东西是有区别的。以下是如何判断您是否走得太远的方法：
您的 MVP 并不能提供完整的体验。用户应该能够在不离开你的产品的情况下从“我有这个问题”到“这个问题已解决”。如果你的日程安排应用程序允许人们预约但没有收到确认，那么你就已经切得太深了。目标是一个完整的循环，无论多么小。用户应该感觉自己完成了一些真实的事情。
用户无法理解您所提供的内容。如果您的“一个问题”解决方案需要 10 分钟的解释，那么您要么删除了实际必要的支持上下文，要么您的“一个问题”不够集中。最好的 MVP 是不言自明的。新用户应该在 30 秒内了解他们将获得什么。
你什么也没学到。小规模运输的目的是收集数据。如果您的 MVP 非常有限，以至于用户在向您提供有用信号之前就反弹了，那么您需要添加足够的内容以保持他们的参与度。请记住：没人使用的 MVP 不会教给你任何东西。您需要足够的功能来生成有意义的行为。
你的“解决方案”会产生新的问题。有时，削减功能会以令人沮丧的方式将工作转移给用户。如果您简化的结账流程要���客户手动计算运输成本，那么您就用复杂性换取了他们的头痛。这不是极简主义；而是极简主义。这是懒惰。
所有三种情况的修复方法都是相同的：添加回完成体验所需的最少功能，然后停止。不要用这些问题作为恢复整个愿望清单的借口。
在结束之前，如果您需要快速在线搜索某人，这个快速寻人 指南解释了安全查找公共信息的最可靠方法。
入门：您的 24 小时行动计划
如果您已经读到这里，您可能会发现功能列表太长了。以下是接下来 24 小时内要做的事情：
- 识别您的一位用户。写下一个具体的名字（真实的或虚构的）、他们的工作、他们每天遇到的挫折以及他们的成功是什么样的。
- 定义你的一个问题。完成这句话：“每周，[一个用户]都会因为[特定问题]而失去[时间/金钱/机会]。”如果你无法量化损失，那么你还没有发现一个足够痛苦的问题。
- 审核您的功能。使用上面的过滤问题将每个计划的功能标记为“核心”、“支持”或“最好有”。
- 设定一个截止日期。选择八到十二周后的发布日期。从那里开始向后工作，以确定实际可以实现的目标。
- 与与您的一位用户匹配的五个人交谈。在构建任何其他内容之前，请确认您的“一个问题”是真实存在的，并且您的核心功能可以解决它。
最好的 MVP 并不是大产品的小版本。它们是针对特定问题的完整解决方案。当你确定了这个焦点时，其他一切都会变得更加清晰：下一步要构建什么，如何营销它，要雇用谁，什么指标很重要。
削减 60% 的路线图听起来很痛苦。但是眼睁睁地看着你的初创公司因为你开发的功能无人使用而消亡？这才是你想要避免的真正痛苦。
从小处开始。保持专注。交付比市场上任何其他产品都能更好地为一个人解决某个问题的产品。
这就是你生存足够长的时间来建造其他一切的方式。