# MVP Design Principles

## 目录

- [概览](#概览)
- [核心原则](#核心原则)
- [单一功能设计法](#单一功能设计法)
- [技术栈选型指南](#技术栈选型指南)
- [7天构建计划模板](#7天构建计划模板)
- [成功指标定义](#成功指标定义)
- [常见错误](#常见错误)

## 概览

MVP(最小可行产品)设计的核心目标是用最小成本验证产品假设。本指南遵循"7天构建、1个核心功能、极简技术栈"原则，帮助快速将痛点转化为可测试的产品原型。

**设计哲学:**
- 速度 > 完美
- 验证 > 功能
- 用户反馈 > 主观臆断

## 核心原则

### 原则1: 一个核心功能

**定义:** MVP只解决一个痛点的一个方面

**为什么重要:**
- 开发时间短(7天内可完成)
- 用户理解成本低(一句话能说清价值)
- 验证周期快(快速获得反馈)
- 迭代方向清晰(基于数据决策)

**如何确定核心功能:**
```
1. 列出用户痛点
2. 问:"如果只能解决其中一个子问题，哪个最关键?"
3. 问:"这个问题能否在7天内用代码解决?"
4. 确认:这就是你的核心功能
```

**示例:**
```
痛点: "Notion移动端太慢"
❌ 错误MVP: 重写整个Notion
✅ 正确MVP: 做一个轻量级的"快速笔记"工具，支持同步到Notion
```

### 原则2: 7天时间限制

**为什么是7天:**
- 足够短，保持专注和动力
- 足够长，完成可测试的原型
- 避免过度设计和不必要的功能

**时间分配:**
```
Day 1: 设计+技术选型
Day 2-4: 核心功能开发
Day 5: 基础UI/UX
Day 6: 测试+修复
Day 7: 发布+收集反馈
```

**硬性规则:**
- 必须在第7天发布(即使功能不完整)
- 第7天后根据反馈决定继续或停止
- 不追求完美，只追求可测试

### 原则3: 技术栈熟悉度优先

**选型原则:**
- 优先使用已掌握的技术
- 避免在MVP阶段学习新框架
- 选择快速开发工具，而非"最佳"工具

**技术债接受度:**
- MVP阶段可以接受"不优雅"的代码
- 优先可工作，而非可维护
- 验证成功后再考虑重构

## 单一功能设计法

### 步骤1: 痛点分解

**方法:** 将大痛点拆解为小问题

**示例:**
```
原始痛点: "内容创作者选题困难"

拆解:
├── 话题发现: "不知道写什么"
├── 趋势分析: "不知道什么话题热门"
├── 竞品分析: "不知道对手在写什么"
└── 灵感管理: "灵感零散难整理"

选择核心: "话题发现" (最基础、最高频)
```

### 步骤2: 核心功能定义

**用户故事模板:**
```
作为一个[用户类型]
我想要[核心功能]
以便于[解决问题]
```

**示例:**
```
作为一个内容创作者
我想要快速发现热门话题
以便于解决选题困难的问题
```

**功能描述模板:**
```
功能名称: [Feature Name]
一句话描述: [What it does]
输入: [User provides what]
输出: [System returns what]
限制: [What it doesn't do]
```

### 步骤3: 功能边界设定

**必须做(Must Have):**
- 核心功能的完整闭环
- 基础的用户交互
- 最小必要的数据存储

**不做(Must Not Do):**
- 用户账号系统(除非核心功能)
- 支付系统(验证阶段不需要)
- 高级设置和定制
- 多平台支持(先做Web或移动端之一)
- 管理后台

**示例:**
```
MVP: "TrendFinder" - 热门话题发现工具

✅ Must Have:
- 输入关键词
- 返回Reddit/Twitter热门话题
- 显示话题热度分数

❌ Must Not Do:
- 用户注册/登录
- 话题收藏功能
- 数据导出
- API接口
- 移动App
```

## 技术栈选型指南

### 选型决策树

```
问题: 你最擅长什么技术?
│
├─ Python → Flask/FastAPI + Streamlit/Gradio
├─ JavaScript → Next.js/Remix
├─ Ruby → Rails
├─ PHP → Laravel
└─ 无技术背景 → No-Code工具(Airtable + Zapier)
```

### 推荐技术栈组合

**场景1: 数据处理型工具**
```
前端: Streamlit/Gradio (Python)
后端: FastAPI
数据库: SQLite/PostgreSQL
部署: Railway/Render
开发时间: 3-5天
```

**场景2: Web应用**
```
前端: Next.js (React)
后端: Next.js API Routes
数据库: Vercel KV/PlanetScale
部署: Vercel
开发时间: 5-7天
```

**场景3: 移动优先应用**
```
前端: React Native/Flutter
后端: Firebase
数据库: Firestore
部署: App Store/TestFlight
开发时间: 7天(基础版本)
```

**场景4: 浏览器插件**
```
技术: Chrome Extension API
存储: Chrome Storage
后端: 无/Cloudflare Workers
开发时间: 3-5天
```

### 技术栈快速选择表

| 产品类型 | 推荐技术栈 | 学习成本 | 开发速度 |
|---------|-----------|---------|---------|
| 数据工具 | Streamlit + Python | 低 | 快 |
| Web应用 | Next.js | 中 | 中 |
| 移动应用 | React Native | 中 | 中 |
| 浏览器插件 | Chrome Extension | 低 | 快 |
| API服务 | FastAPI | 低 | 快 |
| No-Code | Bubble/Airtable | 低 | 快 |

## 7天构建计划模板

### 通用模板

```markdown
# [产品名称] 7天构建计划

## Day 1: 设计与规划
- [ ] 完成用户故事
- [ ] 绘制核心功能流程图
- [ ] 确定技术栈
- [ ] 搭建项目骨架

## Day 2-3: 核心功能开发
- [ ] 实现核心算法/逻辑
- [ ] 基础数据结构设计
- [ ] 单元测试(关键部分)

## Day 4: 用户界面
- [ ] 核心页面UI
- [ ] 基础交互逻辑
- [ ] 简单的样式

## Day 5: 集成与测试
- [ ] 功能集成
- [ ] 端到端测试
- [ ] Bug修复

## Day 6: 完善与优化
- [ ] 错误处理
- [ ] 基础文档(README)
- [ ] 性能优化(如必要)

## Day 7: 发布
- [ ] 部署到生产环境
- [ ] 准备演示视频/GIF
- [ ] 发布到目标社区
- [ ] 收集反馈表单
```

### 时间分配原则

**开发时间占比:**
- 核心功能: 50-60%
- UI/UX: 20-30%
- 测试修复: 10-20%

**关键提醒:**
- Day 7下午必须发布，不留缓冲时间
- 如Day 6发现重大Bug，删减功能而非延期
- 保持"可发布"状态从Day 4开始

## 成功指标定义

### 量化指标

**用户指标:**
```
- 注册用户数/访问量
- 核心功能使用次数
- 用户留存率(Day 1, Day 7)
- 用户推荐意愿(NPS)
```

**产品指标:**
```
- 功能完成度(核心功能是否可用)
- 系统稳定性(错误率)
- 性能指标(响应时间)
```

**验证指标:**
```
- 付费意愿用户数
- 反馈收集数量
- 正面反馈比例
```

### MVP成功标准

**最低成功标准(必须达成):**
- [ ] 核心功能可用
- [ ] 至少50个用户测试
- [ ] 收集至少20条反馈

**理想成功标准:**
- [ ] 核心功能稳定
- [ ] 200+用户测试
- [ ] 50+条反馈
- [ ] 有用户表达付费意愿

**失败信号:**
- [ ] 核心功能无法实现(技术障碍)
- [ ] 用户无法理解产品价值
- [ ] 负面反馈>50%
- [ ] 无用户愿意付费

### 数据收集方法

**方法1: 内置分析**
```
- Google Analytics (访问量)
- Mixpanel/Amplitude (用户行为)
- Hotjar (用户录屏/热力图)
```

**方法2: 反馈表单**
```
- Google Forms
- Typeform
- 内嵌反馈组件
```

**方法3: 直接沟通**
```
- 社区帖子评论区
- DM私信
- 邮件反馈
```

## 常见错误

### 错误1: 功能蔓延(Feature Creep)

**表现:**
```
"如果加上这个功能会更好..."
"用户可能还需要..."
"顺便把这个也做了..."
```

**后果:**
- 延期发布
- 核心功能不聚焦
- 验证周期延长

**解决方案:**
- 使用"功能冰盒"(Feature Icebox): 记录但不实现
- 严格遵守7天时间表
- 每个新功能想法问:"这是核心功能吗?"

### 错误2: 过度设计

**表现:**
```
- 追求代码完美
- 设计复杂的架构
- 过早优化性能
```

**后果:**
- 浪费时间
- 延迟验证
- 增加维护成本

**解决方案:**
- 接受"技术债"
- 优先可工作代码
- 代码质量标准: "可读即可"

### 错误3: 忽视用户反馈渠道

**表现:**
```
- 发布后不收集反馈
- 没有反馈入口
- 不回复用户评论
```

**后果:**
- 无法判断产品方向
- 错过早期用户
- 浪费验证机会

**解决方案:**
- 发布前准备反馈表单
- 发布后积极回复评论
- 建立用户沟通渠道(Discord/邮件)

### 错误4: 追求完美发布

**表现:**
```
"再优化一下UI..."
"还有一些小Bug..."
"等完全准备好再发布..."
```

**后果:**
- 永远无法发布
- 错过市场时机
- 浪费开发时间

**解决方案:**
- 设定硬性发布日期(Day 7)
- 接受"不完美"的首次发布
- 发布后再迭代优化

## MVP设计检查清单

使用此清单确保MVP设计合理:

- [ ] 核心功能只有1个
- [ ] 核心功能可在7天内实现
- [ ] 技术栈是自己熟悉的
- [ ] 不包含账号系统(除非核心)
- [ ] 不包含支付系统
- [ ] 有明确的成功指标
- [ ] 有用户反馈收集方案
- [ ] 发布日期已确定(Day 7)

**评分:**
- 8项全中: 设计合理，可开始开发
- 6-7项: 需调整后开始
- <6项: 重新设计

## 下一步

完成MVP设计后，进入 [Validation Post Templates](../assets/validation-post-templates.md) 准备验证文案。