"MVP"这个词被过度使用到令人困惑的程度。一些团队用它来表示"粗糙的原型"。其他人的意思是"删除了一些功能的完整产品"。两者都不完全正确。
一个有用的 MVP 回答一个问题：人们会为此付钱吗？ 构建中的所有内容都应该服务于这个问题。任何不回答这个问题的都是范围蔓延。
需要先做 MVP 的迹象
- 你以前从未销售过这个产品或服务
- 你对用户行为的假设尚未验证
- 你不确定哪个功能真正推动注册或购买
- 预算有限，完整构建失败将是毁灭性的
你准备好做完整产品的迹象
- 你有付费客户和留存数据
- 你知道哪些功能重要，哪些不重要
- MVP 正在制造阻碍增长的摩擦
- 你有团队来运营和维护你构建的东西
正确的顺序
构建能创造真实价值的最小化产品。从第一天就收费——即使是象征性的金额。如果人们不愿意为不完美的版本支付少量费用，他们通常也不会为精致的版本支付更多。
一旦你有了证据，就投资完整构建。此时，你不是在赌博——而是在基于证据执行。
我们的建议
从一次为期 2 周的范围规划开始。我们将规划你的 MVP，找出驱动转化的核心功能，并给出固定价格进行交付。大多数 MVP 在 4–8 周内上线。