MVP在产品开发中指最小可行产品（Minimum Viable Product）：用能够验证关键假设的最小方案，让目标用户真实尝试，再根据行为与反馈决定下一步。它不是随意删功能的低质量版本，也不等于一套页面原型。需要先验证流程能否理解时，可以用Pixso原型设计准备可点击方案，再安排真实服务或功能验证。
1. 什么是MVP模型
产品MVP强调“构建—衡量—学习”的反馈循环。先写出最不确定、又决定产品能否成立的假设，再设计成本可控的实验。精益创业方法把学习与可行动的指标作为核心，而不是要求首版达到某个固定功能数量。
- 最小（Minimum）：只保留验证本次假设所需的范围。例如测试用户是否愿意预约耳机试用，可以先提供产品介绍、预约表单和人工确认，而不必先开发积分商城。
- 可行（Viable）：用户能够完成承诺的核心任务。预约提交后必须有人处理，失败要有反馈，不能只有漂亮的按钮却无法得到服务。
- 产品（Product）：提供能被实际体验的价值，并收集行为证据。点击、成功提交、到店试用和购买是不同阶段，不能拿浏览量替代付费意愿。
Android开发中的MVP是Model–View–Presenter架构，与最小可行产品只是缩写相同。这里讨论产品验证，不讨论代码分层。下面的耳机页面可以作为展示与预约流程的设计起点，但页面好看本身并不能证明市场需求成立。
2. 为什么要使用产品MVP模型
2.1 让关键假设尽早接触目标用户
以“用户愿意先预约再到店试用耳机”为例，先明确预约流程要验证什么，再选择能够回答问题的观察指标：
- 问题是否存在：目标用户是否确实需要试听再购买？访谈中提出需求，与实际愿意花时间预约，需要分别记录。
- 用户是否匹配：参与者是否属于预期客群？不要只邀请团队同事，也不要把优惠吸引来的临时访客直接当作稳定需求。
- 行为是否发生：分别记录看到介绍、开始预约、提交成功、到店试用与购买的人数，找出流失发生在哪一步。
- 下一步做什么：若有人提交但很少到店，先检查时间安排、距离与提醒，而不是立即扩建完整商城。
2.2 缩小开发范围，不是承诺固定提速
MVP减少的是验证前必须投入的范围。例如先用人工确认预约时段，而不是开发自动排班系统；先服务一个门店和一种耳机，再考虑多门店库存。团队由此能更早获得反馈，但它不会把“单线程变成多线程”，也不能保证工期按人数等比例缩短。
2.3 根据反馈决定继续、调整还是停止
例如，本轮只想知道用户是否愿意预约试听，就先统一产品介绍和预约条件，记录一段固定时间内的预约与到店情况。若用户认可产品却不愿留下手机号，可以比较是否需要更多信任说明，或是否应提供其他联系方式；不要同时更换价格、产品和渠道后再把结果归因于表单。
开始前先约定观察窗口、成功标准和停止条件。若预约页无人提交，需要区分价值主张不清、表单太长、触达错人或根本没有需求。一次只调整主要变量，并保留前后版本与行为记录，才能知道下一轮改动是否真正解决了问题。
3. 如何避免产品MVP模型的陷阱
“最小”应围绕本次假设，而不是把所有产品能力一起缩小。下面三种情况会让实验结果失去判断价值。
- 核心任务不可完成：用户提交预约后没有确认，也没有联系方式。这时测到的是流程故障，不是用户没有需求。最小方案仍要兑现最基本的服务承诺。
- 用精美原型替代行为证据：原型适合观察理解、操作路径和信息层级；若要验证真实使用、履约成本或付费，就需要相应的实际服务与行为记录。不能把“大家说喜欢”当成商业可行性的结论。
- 测试对象或问题设置偏差：提前告诉参与者该点哪个按钮，会掩盖界面理解问题。让目标用户按自己的习惯尝试，记录卡住的位置与原话，再区分流程问题和需求问题。
用Pixso准备可讨论、可试用的预约原型
在Pixso中先搭出“产品介绍—选择时间—提交预约—确认结果”四个页面，把空时段、表单错误和取消预约一起画清楚。Pixso资源社区中的产品页可用于寻找布局思路；它们不是已经验证有效的MVP，需按本次假设修改内容与流程。
- 表达核心路径：用原型连接把预约流程串起来，让产品、设计和研发共同检查用户能否完成目标。
- 复用合适组件：使用已有按钮、输入框和时间选择组件，先保证内容完整与状态清楚，不把时间花在不影响本轮验证的装饰上。
- 补齐操作反馈：确认跳转、弹窗与返回行为，避免用户提交后不知道是否成功。动效只用于解释状态变化。
- 观察真实操作：邀请目标用户尝试原型，记录他们在哪一步停顿、误解了哪些文字，再修改对应页面。
- 交付验证范围：将页面、业务规则和待实现部分一起分享给团队。原型演示之后，仍需由真实服务或功能验证使用与付费假设。
