做最小版本

Gumroad 的第一个版本简陋到什么程度？2700 行 Python 代码，大部分是复制粘贴的。没有文件上传——卖家卖完东西后，得手动把下载链接发给买家。没有自动收款——每个月月底，Sahil 手动导出一份 PayPal 清单，挨个给每个人打款。就这么干了超过一年。

官网只有三行字：提供你的文件或链接 → 分享你的定价链接 → 收款。没了。

Sahil 后来说："10 年后，Gumroad 仍然感觉没有准备好。它今后也不会。"

但 Gumroad 解决了一个核心问题：让创作者在 5 分钟内开始卖东西。 其他全是多余。没有文件上传用户也能卖（给下载链接就行），没有自动付款用户也能收到钱（Sahil 手动打），只是慢一点。

这就是最小版本的判断标准：删掉这个功能，用户还能完成核心任务吗？如果还能，这功能就不该进第一版。

核心原理

真正的最小可行产品不是 MVP（Minimum Viable Product），是一个有价值的人工流程（Manual Valuable Process）。

在写代码之前，先用手动方式帮客户解决一次问题。记录你做了什么、用了什么工具、花了多长时间。这份操作记录比代码值钱，因为它验证了：这个需求是真实的，有人愿意付钱，你知道怎么交付。

先流程化，再产品化。 流程化是你一个人帮客户解决问题；产品化是你把流程做成别人可以自助使用的东西。很多创业者跳过了流程化这一步，直接奔向产品化——结果产品做出来发现根本没人需要。

克制比创新更难。 加一个功能很容易，决定不加才是真正的挑战。Gumroad 的拒绝清单包括：文件上传、自动付款、购物车、退款系统、推荐算法。这些功能后来都有了，但第一版通通不要。

做一半产品，不是做一个半吊子产品。 Gumroad 第一版只有三个页面——创建链接、分享链接、收款——但每个环节用户都能完整走通。砍功能可以，但剩下的那一半必须真能跑。不是"部分能用"，是"只做最重要的那部分，而那部分体验是完整的"。

有限的资源不是劣势。 Gumroad 第一版就 2700 行复制粘贴的代码，没有文件上传、没有自动付款——但反而逼它把核心功能做到了极致。条件限制迫使你只做最重要的事。可以给自己设一个时间框限，比如搞一次周末黑客松——做出东西 → 拿到反馈 → 改进。一周一周期，比闷头做三个月有效得多。

早早交付，经常交付。 Gumroad 在 10 年里从没有发布过版本 2.0——取而代之的是数万次大大小小的改进。每一次都让一些"我以后可能需要这个"的客户变成"我现在就需要这个"。你的反馈循环越快，找到产品市场契合点的速度就越快。

行动清单

确认你可以用手动方式跑通服务
用一句话定义核心功能
搭好基础设施（起名、网站、邮箱、社交账号、收款）
写一份拒绝清单
设一个硬性的交付日期

实操步骤

第一步：先用手动流程跑一遍

找到你在上一章积累的 3 个问题中你认为最值得解决的那个。然后：

用最简单的方式帮第一个人解决。可能是一份 Google 表格、一个微信对话、一封邮件。不要写代码，不要搭系统，全部手动操作。

做完之后把每一步写下来：

第 1 步：用户发给我什么信息
第 2 步：我用什么工具处理
第 3 步：我怎么把结果交到用户手上
总共花了多少时间

这份操作文档就是你的第一版"产品"。不要觉得它丢人——Gumroad MVP 只是 2700 行复制粘贴的代码，Sahil 手动打了一年的款。你的起步不需要比这更高级。

第二歩：把核心功能说清楚

用 10 个字以内说清楚你的产品做什么。如果你说不出来，说明你还想不清楚。

Gumroad 的 10 个字：让创作者在 5 分钟内开始卖东西。

你的呢？写下来。然后把它贴在随时能看到的地方——电脑桌面、手机壁纸、笔记本封面。每次想要加功能的时候，看它一眼，问自己：这个新功能帮我更好地完成这句话了吗？

第三歩：搭好商业基础设施

在动手做产品之前，先把这些基础的商业"硬件"搭好。它们花不了多少钱，但能让你随时准备接待第一个客户。

为产品起名字：最好选两个词组合的名字，方便拼写和口口相传。Gumroad、Dropbox、Facebook 都是这类。别纠结太久——产品做好了，名字自然顺耳。
创建网站和邮箱：花 10 美元买域名，挂到 Carrd、Gumroad 或类似平台。用这个域名创建商务邮箱（you@你的产品.com）。
创建社交媒体账号：建两个——一个你个人用，一个产品用。后续做营销时你会知道这个区分有多重要。
设置收款方式：注册 Stripe 或同类支付服务商。免费注册，每笔交易收 2.9% + 30¢ 手续费。

做到这四点，你的生意就可以接客了。有人问你在忙什么，你可以直接给他一个网址。

第四步：写一份拒绝清单

列出你觉得"最终要有"的所有功能。然后圈出最核心的 1-2 个，把剩下的全部写进拒绝清单，命个文件名贴在桌面上——"V1 不做清单"。

判断标准只有一个：假设删掉这个功能，用户还能不能完成核心任务？如果不能才放进第一版。

这个步骤很多时候比写代码还重要，因为它迫使你想清楚什么是真正要紧的。一版做好一件事，胜过十个半成品功能。

附一个来自 Rework 的规则：默认说不。 面对新功能请求先回答"不"——除非有足够好的理由破例。这样少数破了例的功能，你才确信它们真的该做。

第五步：设一个硬性的交付日期

先定日期，再砍功能。

如果你告诉自己"两周后上线"，那就是两周。不要延期。如果时间到了功能还没写完，砍功能而不是延期。一个今天能用的、只有 3 个功能的产品 > 一个下个月才能用的、有 10 个功能的产品。

把日期告诉你身边的一个朋友——发个消息说"我 X 月 X 号会发布一个东西"。说出去你就不好意思放自己鸽子了。

验收标准：

你的 MVP 能完整走通——哪怕里面全是手动步骤
拒绝清单上的功能没有偷偷溜回第一版
你有一个明确的日期，而且你知道那天会发生什么