MVP (Minimum Viable Product)，即“最小可行产品”。它不是一个简陋的产品，而是一个过程。
“MVP 是那个能让你以最小的努力，从客户那里收集到最大量经证实的认知（Validated Learning）的产品版本。”
—— 埃里克·莱斯 (Eric Ries), 《精益创业》在资金耗尽前，验证商业模式是否成立。
在投入大规模开发资源前，测试用户对新特性的兴趣。
用低代码或手动方式先行，验证流程优化效果。
原理：表面看起来是自动化的产品，实际上由人工在幕后操作。
适用场景：验证用户是否需要某个功能，无需投入技术开发。
案例：Zappos早期手动采购鞋子
原理：创建一个产品着陆页，收集用户邮箱或预订意向。
适用场景：验证市场需求和价格敏感度。
案例：Buffer早期只有简介页和等待列表
原理：用视频展示产品概念和使用场景，收集反馈。
适用场景：复杂产品的概念验证。
案例：Dropbox的产品演示视频
原理：只实现一个核心功能，做到极致。
适用场景：已确定核心价值主张。
案例：Twitter早期只有发推功能
原理：使用现有工具和服务拼接出产品原型。
适用场景：快速验证整体流程可行性。
案例：用Airtable+Zapier+微信搭建服务
原理：亲自为每个客户提供个性化服务。
适用场景：深度理解用户需求和痛点。
案例：Food on the Table的初期模式
明确你最想验证的“风险最大”的假设。例如：“人们愿意付费让别人帮他们选餐厅吗？”
谁是你的早期采用者（Early Adopters）？他们现在是如何解决这个问题的？痛点有多痛？
只保留验证假设必须的功能。如果假设是“推荐准确性”，那么“用户登录系统”可能都不是必须的。
使用无代码工具、着陆页、甚至人工后台（Wizard of Oz）。不要写完美的代码，要追求速度。
设定指标（如点击率、预订量、NPS）。收集定性（访谈）和定量（数据）反馈。
数据符合预期吗？符合 -> 坚持并优化；不符合 -> 调整方向（Pivot）或放弃。
One Metric That Matters——每个阶段只关注一个最重要的指标
避免「虚荣指标」（Vanity Metrics），如只看注册量不看活跃度
用户因为“选择困难症”，愿意付费获取个性化的餐厅推荐。
一个简单的微信群或网页表单。用户提交需求，后台由人工（创始人自己）搜索并发送推荐结果。
是否有用户愿意下单？推荐满意度如何？
无需开发复杂的推荐算法，验证了需求存在后，再投入技术开发。
人们需要一个能提醒喝水并显示水温的智能水杯，且愿意为此支付 300 元。
一个3D打印的外壳模型 + 一段精心制作的概念视频，发布在众筹网站上。
预订量（Pre-orders）。
如果没人预订，就不用开模生产，节省了巨额的供应链成本。