MVP 规划

概述

MVP 并非将你所能想到的所有功能全部砍掉后剩下的产品。它是你能构建的最小可行版本，其唯一目标是验证你的核心商业假设，并为真实用户提供切实价值。若构建过多，你会把时间浪费在无人需要的功能上；若构建过少，你发布的产品将无法真正解决问题。本指南精准定义了这条边界，并为你提供一套可重复执行的流程，助你找到它。

步骤 1：重述你的核心假设

在界定任何范围之前，请先写下你的 MVP 必须验证的**单一假设**。你所包含的每一项内容，都必须服务于该假设；所有不服务于该假设的内容，一律剔除。

格式如下：

IF 我们构建 [面向 Y 类客户的、具备 X 功能的具体产品]，
THEN [我们预期的具体结果 — 例如：Z% 用户会付费，W% 用户会每周返回使用]。

示例：
“IF 我们为自由职业开发者构建一款自动化客户进度报告工具，THEN 至少 30% 的测试用户将在首月内每周使用该工具，且至少 10% 将转化为付费计划。”

该假设包含两部分：行为信号（使用频率）和收入信号（付费意愿）。二者均需可量化。若无法衡量，就无法从中学习。

步骤 2：明确定义你当前情境下的“可行”标准

“可行”并非普适概念，它取决于你的具体假设。请将假设映射到验证它所需的最低用户体验水平。

请回答以下问题：

1. 客户要判断“这有价值”或“这没价值”，所需体验的绝对最小范围是什么？
2. 哪一项核心交互能直接交付你的价值主张？
3. 哪些功能可以手动实现、界面粗糙或完全缺失，却仍不妨碍假设验证？（这些功能应被剔除或模拟。）
4. 哪些功能一旦缺失，会导致产品显得残缺或毫无用处？（这些是不可妥协的刚性需求。）

为每一项功能标注如下：

• 🔴 必备功能：缺少此项，产品即失去意义；无法验证核心假设。
• 🟡 锦上添花功能：可提升体验，但即使缺失，仍可验证假设。
• 🟢 剔除功能：与假设验证完全无关；仅在假设得到验证后才考虑构建。

步骤 3：功能极致精简

拿出你完整的功能愿望清单，对每一项都严格应用以下筛选机制。务必严苛——独立创业者可用的开发时间极为有限，每一个非必要功能，都是从核心价值中窃取的时间。

四大精简原则：

精简原则 1：假设验证原则

该功能是否**直接服务于**你核心假设的验证？

• 是 → 暂留（后续仍需接受其他原则检验）
• 否 → 剔除。无例外。

精简原则 2：“模拟替代”原则

该功能能否通过人工方式或模拟手段，为前 N 位客户提供服务，且用户不会察觉或并不在意？

可模拟的功能示例：

• 面向首批 10 位客户的所谓“仪表盘”，实际只是一个共享的 Google Sheet
• 标榜“实时”的更新，实际延迟 1 小时发送
• 号称“AI 驱动”的推荐，实则由你亲自为测试用户人工筛选
• 所谓“API 集成”，实则是一个每几小时运行一次的定时脚本

只要能在测试规模下令人信服地模拟，就请模拟。仅当确认用户确实需要该功能后，再构建真实版本。

精简原则 3：分阶段上线原则

该功能是否**必须在首发时存在**，还是可以推迟至 v1.1 版本（即发布后 2 周内）上线？

若该功能可延后 2 周上线，且产品在此期间依然可用、可测 → 则将其从 MVP 范围中剔除，移入“第二周”待办列表。

精简原则 4：愉悦感剔除原则

该功能是否属于一种“愉悦感”——即虽好但非用户预期之物？

愉悦感对用户留存有益，但对 MVP 极其有害。全部剔除。你的 MVP 应当功能完备、逻辑清晰，而非令人愉悦。“愉悦感”是 v2 阶段的奢侈追求。

完成全部四项精简后，你的功能清单应已大幅缩减。 若仍感觉内容繁多，请继续精简。最常见的 MVP 错误，就是构建得太多。

步骤 4：定义 MVP 范围文档

撰写一份单页文档，以锁定 MVP 范围。此举可防止范围蔓延，并为你提供一条清晰的“完成”判定线。

MVP 范围文档
==================

假设：[来自步骤 1]

交付的核心价值：[一句话 —— 用户获得什么]

必备功能（🔴）：
  1. [功能] — 因为 [为何该功能对验证假设至关重要]
  2. [功能] — 因为 [为何]
  3. [功能] — 因为 [为何]

模拟/人工实现功能（🟡 — 推迟至真实实现）：
  1. [功能] — 模拟方式为 [如何模拟] — 真实构建时间：[何时]
  2. [功能] — 模拟方式为 [如何模拟] — 真实构建时间：[何时]

MVP 中剔除的功能（🟢 — 发布后再评估）：
  1. [功能]
  2. [功能]
  ...

发布准入条件（全部满足后方可称为“已发布”）：
  - [ ] [条件 1]
  - [ ] [条件 2]
  - [ ] [条件 3]

成功标准（发布后 30 天内衡量）：
  - [指标 1]：目标值 = [数值]
  - [指标 2]：目标值 = [数值]

步骤 5：自建 vs. 采购决策

针对 MVP 所需的每一项技术组件，请明确决策：自行构建、采购/使用现成工具，或采用无代码/低代码方案。

决策框架：

独立创业者守则： 自定义组件越少，MVP 上线越快。除你独有的那一项外，其余一切均应坚决采用现成工具。

步骤 6：开发工作量估算与排期

对每一项必备功能，进行如下估算：

• 开发耗时（小时数 — 务必诚实预估，再额外增加 50% 缓冲）
• 依赖关系（功能 B 是否需以功能 A 完成为前提？）
• 复杂度风险（是否存在你尚不确定的部分？请优先构建该部分以降低整体风险）

开发顺序规则：

1. 首先构建**技术风险最高**的部分。若其最终被证实不可行，或耗时超出预期三倍，你希望尽早知晓 —— 而非在围绕它构建完全部功能之后才发现问题。
2. 其次构建**核心价值闭环**。这是交付你价值主张的单一关键交互，其余所有功能均需围绕并服务于它。
3. 最后构建支撑性功能。认证、新手引导文案、界面打磨等，均应在核心功能验证有效后再进行。

时间规划：

• 设定一个硬性发布日期（制造外部压力 — 告知他人、建立等待列表）。
• 从发布日期倒推至今日。开发总耗时是否能够容纳？
• 若无法容纳，请进一步精简功能（回到步骤 3），或延后发布日期。切勿为迎合任意截止日而牺牲核心价值闭环。

步骤 7：发布准入检查清单

在所有条目均打钩前，请勿发布：

• 核心价值闭环端到端可用（真实用户可顺利完成注册并亲身体验核心价值）
• 无导致数据丢失的缺陷（可牺牲界面精致度，但绝不能丢失用户数据）
• 支付功能可用（若首发即商业化 — 即使仅为“稍后付费”的承诺）
• 可在 5 分钟内，无需协助，让一位陌生人完成上手（需用 3 位真实陌生人测试）
• 具备收集用户反馈的途径（应用内问卷、邮件或 Slack 频道）
• 具备监控基础健康状况的能力（正常运行时间、错误率、基础分析数据）
• 已制定发布后前 48 小时的应对计划（通知对象、监控方式、反馈响应机制）

步骤 8：发布后的学习闭环

MVP 并非终点，而是持续学习闭环的起点。

发布后第一周：

• 与每一位早期用户进行一对一沟通（非问卷调查，而是真实对话）。哪些地方令他们困惑？哪些地方让他们惊喜？他们期待却未见到的功能是什么？
• 如有可能，请观察他们使用产品的过程（屏幕共享、会话录屏）。他们在何处犹豫不决？又在何处流失？

发布后第 2–4 周：

• 测量你在范围文档中定义的成功指标。进展是否符合预期？
• 识别出你所构建的产品与用户真实需求之间最显著的差距。
• 做出决策：迭代当前 MVP，还是调整核心假设？

决策依据：

• 若使用指标强劲但收入指标疲软 → 问题在于定价或转化路径。聚焦优化该环节。
• 若使用指标疲软 → 核心价值未触达用户。可能需要调整假设（Pivot）。
• 若两项指标均强劲 → 已出现产品市场匹配（PMF）信号。可进入规模化阶段（拓展用户、加大营销、增加功能）。

需避免的 MVP 常见错误

• 因功能“做起来有趣”而构建，而非因其服务于假设验证。
• 首发面向朋友。朋友往往过于礼貌，无法提供真实有效的反馈。请首发面向陌生人。
• 在尚未确认核心价值前，过度打磨 UI。一个能解决真实问题但界面粗糙的产品，远胜于一个精美绝伦却无人需要的产品。
• 将 MVP 视为最终产品。事实并非如此。它是一台学习机器。你预计将在 v2 中重构其中 60–80% 的内容。
• 迟迟不发布。最好的 MVP 是已发布的 MVP。未发布的 MVP 教会不了你任何东西。