定义 MVP
MVP 是什么?
MVP = 最小可行产品 (Minimum Viable Product)
我的理解: MVP 一定与要解决的核心问题挂钩
不是"功能最少的版本",而是"能解决核心问题的最简版本"。
真实案例: 微信公众号 RSS
MVP 演进过程
阶段 1: API 版(最小 MVP)
核心问题: 获取微信公众号文章
MVP 功能:
- 输入: 微信文章 URL
- 输出: 文章内容(JSON)
- 就这一个功能
为什么这是 MVP?
- 解决了核心问题(获取文章)
- 能跑通,能验证
- 其他功能都可以后面加
阶段 2: RSS 版
核心问题: 订阅公众号更新
新增功能:
- 把 API 拓展成 RSS 订阅
- 自动更新
- 生成 RSS feed
做完立即开源 → 验证需求
阶段 3: SaaS 版(非 MVP)
用户反馈: 开源版需要自己部署,太麻烦
SaaS 功能(非 MVP):
- 用户注册登录
- 订阅管理
- 付费系统
- 统计看板
为什么不是 MVP?
- 这些是"体验优化",不是"核心功能"
- 开源版已经能解决核心问题
- SaaS 是为了降低使用门槛
真实案例: AI News RSS
MVP 定义
核心问题: AI 领域信息聚合
MVP 功能:
- 抓取信息源(一手信息)
- AI 分析提取
- 评分排序
- 整合成日报
就这 4 个功能,其他都不要
非 MVP 功能(后来加的)
❌ 语音播报 - 体验优化,不是核心 ❌ 多主题日报 - 功能扩展 ❌ 自定义信息源 - 高级功能
为什么砍掉?
- 核心需求是"看到 AI 领域的重要信息"
- 语音播报虽好,但不影响核心价值
- 先做核心,能用了再加
反面案例: VoiceType 项目
最初的想法(错误)
特色功能: 引入 RAG(检索增强生成)
为什么想做?
- 市面上产品都用传统方案
- RAG 更精准
- 想做差异化
投入:
- 花很多时间开发
- 以为这是核心竞争力
测试后发现的问题
VoiceType 的真实定位:
- 语音输入工具
- 核心功能 = 语音识别(Speech-to-Text)
- 不需要 LLM 理解内容,不需要回复
RAG 的问题:
- RAG 是用来匹配知识库,增强 LLM 回答的
- 但我们只是做语音识别,根本用不上
- 增加了响应时间
- 对识别精准度没帮助
- 技术方案用错场景了
结论: 技术方案本身没问题,但用错场景了
痛苦的决策: 砍掉
砍掉 RAG 功能:
- ❌ 前期花了很多时间开发
- ❌ 觉得很可惜
但必须砍:
- ✅ RAG 用在了错误的场景
- ✅ 语音识别不需要知识库匹配
- ✅ 技术方案不匹配需求
教训: 先进的技术用错场景,不如简单的方案用对场景。
如何定义 MVP?
3 个关键问题
1. 核心问题是什么?
- 微信 RSS: 获取公众号文章
- AI News RSS: AI 信息聚合
- VoiceType: 快速语音输入
2. 最小解决方案是什么?
- 能解决核心问题的最简单方式
- 去掉所有"好但不必要"的功能
3. 能不能 2 周做出来?
- ✅ 能 → 是 MVP
- ❌ 不能 → 范围太大,继续砍
MVP vs 非 MVP 的判断
判断标准:
| 问题 | MVP | 非 MVP |
|---|---|---|
| 去掉这个功能,核心价值还在吗? | ❌ 核心价值没了 | ✅ 还在 |
| 用户没有这个功能能用吗? | ❌ 不能用 | ✅ 能用,只是体验差 |
| 做这个功能需要多久? | ✅ 1-2 周 | ❌ 需要更久 |
真实案例对比
微信 RSS 的 MVP:
| 功能 | MVP? | 原因 |
|---|---|---|
| 获取文章内容 | ✅ MVP | 没有这个就没法订阅 |
| RSS 生成 | ✅ MVP | 核心功能 |
| 用户注册登录 | ❌ 非 MVP | 开源版不需要 |
| 付费系统 | ❌ 非 MVP | 先验证需求 |
| 统计看板 | ❌ 非 MVP | 锦上添花 |
常见错误
错误 1: 把"好"当成"必需"
❌ 错误想法:
- "既然要做,就做好一点"
- "这个功能很酷,一定要加"
- "用户会喜欢这个"
✅ 正确做法:
- 只做核心功能
- "酷"不等于"需要"
- 先能用,再优化
VoiceType 的教训:
- RAG 很酷,但不符合定位
- 砍掉很痛苦,但必须砍
错误 2: MVP 做成"半成品"
❌ 错误理解:
- MVP = 功能不全
- MVP = 粗糙的版本
- MVP = 凑合能用
✅ 正确理解:
- MVP = 核心功能完整
- MVP = 能解决核心问题
- MVP = 其他功能没有,但核心功能做好
举例:
- ❌ 微信 RSS,但经常获取失败 → 不是 MVP,是半成品
- ✅ 微信 RSS,只能获取文章,不能管理 → 是 MVP
错误 3: 不敢砍功能
症状:
- 想法越来越多
- 功能越加越复杂
- 迟迟做不完
解决:
- 列出所有想要的功能
- 标出"核心"和"非核心"
- 砍掉所有非核心
- 留到下个版本再做
实战技巧
技巧 1: 用"没有 XX 能用吗"测试
逐个功能问自己:
- "没有用户登录,能用吗?"
- ✅ 能 → 不是 MVP
- ❌ 不能 → 是 MVP
微信 RSS 示例:
- 没有文章获取功能 → ❌ 不能用 → MVP
- 没有付费系统 → ✅ 能用(开源免费)→ 非 MVP
- 没有统计看板 → ✅ 能用 → 非 MVP
技巧 2: 2 周时间盒
规则:
- MVP 必须在 2 周内做完
- 做不完就砍功能
- 强制你聚焦核心
为什么 2 周?
- 太短(1 周)→ 做不出东西
- 太长(1 月+)→ 容易加功能
- 2 周刚好,逼你做取舍
技巧 3: 先做开源版(降低成本)
策略:
- MVP 做成开源版
- 功能极简,核心完整
- 上线看反馈
- 有人用,再做 SaaS
好处:
- 降低试错成本
- 快速验证需求
- 开源引流
核心原则
MVP 不是"做得少",而是"做得精准"
聚焦核心问题
- 只解决一个问题
- 解决得很好
砍掉一切非必需
- 功能再好,不必需就砍
- 留到下个版本
2 周能做完
- 做不完就继续砍
- 强制聚焦
能用,不是完美
- 能解决问题就够了
- 完美是迭代出来的
记住: 很多项目死在"想做太多",不是"做太少"。