克服完美主义

完美主义的三个谎言

谎言 1："等我再优化一下就上线"

真相：

• 你觉得的"优化"，用户根本感知不到
• 你担心的"bug"，用户可能根本不会触发
• 你纠结的"性能"，在 100 个用户之前都不是问题

案例： 某开发者做了一个 Chrome 插件，功能已经能用，但他花了 3 个月优化：

• 重构代码结构（用户看不到）
• 优化加载速度从 200ms 到 50ms（用户感知不到）
• 设计了 10 种主题（用户只用默认主题）

结果：上线后发现用户最需要的功能他根本没做。

谎言 2："用户会因为质量差而骂我"

真相：

• 没人用的产品，连被骂的机会都没有
• 用户骂你，说明他在乎你的产品
• 早期用户很宽容，他们要的是解决问题，不是完美体验

正确心态：

• 把第一版当成"可交互的原型"
• 用户反馈 > 你的想象
• 快速迭代 > 一次做对

谎言 3："我要做一个比竞品更好的产品"

真相：

• 竞品有 100 人团队，你只有 1 个人
• 竞品有 10 万用户反馈，你只有自己的想象
• 竞品的"好"是迭代出来的，不是一开始就有的

正确做法：

• 不要全面超越，只在 1-2 个点上做到极致
• 先做到 60 分能用，再根据反馈优化到 80 分
• 永远不要追求 100 分

80/20 法则

核心原则： 80% 的功能只需要 20% 的时间。

实战建议：

第一版只做核心功能

• 列出 10 个想做的功能
• 删掉 8 个
• 剩下 2 个做到能用就上线

用最简单的方式实现

• 能用 Google Sheets 就不要建数据库
• 能用现成 UI 库就不要自己设计
• 能手动处理就不要写自动化脚本

设定上线 Deadline

• 给自己 2 周时间
• 到期必须上线，不管做到什么程度
• 上线后再根据反馈迭代

如何判断"能上线了"

问自己 3 个问题：

1. 核心功能能跑通吗？

   • 能 → 可以上线
   • 不能 → 继续做

2. 有明显的致命 bug 吗？

   • 有 → 修掉
   • 没有 → 可以上线

3. 用户能理解怎么用吗？

   • 能 → 可以上线
   • 不能 → 加个简单的引导

其他问题（UI 不够美、功能不够多、性能不够快）都不是上线的阻碍。

实战案例

案例 1：Twitter 第一版

• 只能发 140 字
• 没有图片、视频、话题、@功能
• UI 极其简陋
• 但核心功能（发消息、看消息）能跑通

案例 2：Stripe 第一版

• 创始人手动处理每一笔支付
• 没有自动化系统
• 但用户能收到钱

案例 3：Airbnb 第一版

• 创始人自己拍房子照片
• 手动审核每个房源
• 网站是用现成模板改的

共同点：

• 核心功能能用
• 其他都是手动或简陋的
• 快速上线，快速迭代

行动清单

今天就做：

1. 列出你的产品核心功能（只能 1 个）
2. 删掉所有"锦上添花"的功能
3. 设定 2 周后必须上线的 Deadline
4. 找 3 个朋友试用，收集反馈
5. 上线，哪怕只有 60 分

记住：Done is better than perfect.