最小可用产品 MVP 到底要多小

我第一次做 MVP 的时候，犯了一个经典错误。

花一个月做了一个最小可用产品，功能精简到不能再精简——用户注册、创建项目、编辑、保存、分享。

我心想，够小了吧。

上线了一个月，来了几十个人。注册了，看了看，就走了。

后来我跟一个用户聊，他说："你的产品我知道是做什么的，但我不知道它对我有什么用。"

我做的功能是够少了，但我做的东西没有形成"一个完整的使用场景"。用户来了，体验了一半，发现体验不完整，就离开了。

什么是最小可用产品

字面意思是"最小的可用产品"。

但很多人把重点放在"最小"上，忽略了"可用"。

MVP 的核心不是功能少，是能跑通一个完整的价值链路。

举两个例子：

• 一个订餐平台的 MVP：不能只看菜单，至少能让用户下单 → 付款 → 收到确认
• 一个落地页工具的 MVP：不能只做编辑器，至少能让用户描述需求 → 生成页面 → 获得链接分享出去

功能可以少，但价值链路必须完整。用户用完之后知道"这个东西解决了我的问题"。

怎么判断 MVP 够不够

一个简单的测试：

你能不能找一个陌生人，让他用你的 MVP，在 5 分钟内理解产品价值，并且愿意尝试第二次？

如果你的 MVP 上线后，用户看了就走了——说明价值链路没跑通。

如果他用了之后回来问"能不能加 XX 功能"——说明你做对了，他在告诉你下一步。

常见的 MVP 误区

误区一：功能太少，没有价值

"我做了用户注册和文件上传，但用户不知道上线后能干嘛。"

你对用户说"这是一个智能写作工具"，但他打开后只有一个空白的编辑框——他不知道怎么用。

解决方案：MVP 要有默认的 demo 数据或者引导流程，让用户一来就知道"哦这东西是干这个的"。

误区二：花太多时间打磨细节

一个按钮的阴影调了半天。用户根本注意不到。

MVP 阶段，你只需要确保功能走得通。UI 丑一点没关系、流程糙一点没关系。早点上线拿到反馈，比完美更重要。

误区三：功能多了，变成小怪物

本来想做"一个简单的任务管理工具"，做着做着加了日历、加了文件共享、加了团队协作。

最后做出来的是一个四不像。每个功能都不够好，用户不如去用 Notion。

MVP 阶段最需要的是克制。每一项新功能，问自己：没有这个功能，用户能不能跑通核心链路？

MVP 的时间

一个 MVP 应该多久做完？

对于工具类产品：2-4 周。

如果你做了两个月还没上线，说明 MVP 太大了。砍掉一半功能，先上线。

记住：用户给你反馈的时间，比你"想清楚"的时间重要一百倍。

如果你不确定 MVP 该做哪些功能，先不要写代码。用 Lando 做一个落地页描述你的产品，找人问问：这个描述能看懂吗？会想试试吗？电话或当面聊 5 分钟，省掉你 2 周的开发时间。