第一个产品怎么控制功能范围：先砍再加的规矩

2026-08-19 独立开发,功能范围,MVP,清单

我做烧烤店小程序那单，手写代码不到 20 行。第一个产品怎么控制功能范围，答案不是"少做点"，是"先把范围砍到只剩主流程，后面按证据加回来"。

那单交付收入 ¥3000，客户要的功能一个没少。

下面这套规矩是我自己撞了墙之后定下来的，一共六条。

一、主流程超过三步就砍

拿纸写下用户从进入到拿到结果的完整路径，数一数有几步。

我第一版画板的主流程只有两步：打开、开始画。它后来累计收入过了 ¥6000，纯前端、零运维、两天写完，靠的就是这个窄。

步数越多，每多一步就多一个用户流失点。 第一个产品承担不起太多流失点。

具体动作：把主流程写在纸上，超过三步的，找出哪一步可以不要，直接划掉。

二、通用模块一律后置

我自己就栽过。曾经在一个还没人用的东西上花了两周写权限系统，写完发现用户一个没有。

通用模块有明确的完成感，但它不产生任何验证价值。

具体动作：在需求清单上给每条打标签，标"通用"的全部移到第二版，第一版只留"能不能用"相关的。

三、能用现成的绝不自己写

判断标准是：这个功能会不会成为你的竞争力。

腾讯云服务器加域名 ¥300+、微信个人认证 ¥30，这些钱花出去是为了不自己造基础设施。AI 员工小码能生成的部分，我也不再手写。

你写过的功能越熟，越应该把它自动化掉，把时间留给没做过的那部分。

具体动作：列出第一版需要的每个模块，问一句"有没有现成方案"。有就用，别纠结。

四、一条功能对应一个可验证指标

功能不是凭感觉加的，每个功能都要能对应到一个你上线后能看到的东西。

我做小游戏那次，核心假设是"孩子会连续玩"。结果种子计划来了 180 人/天，次日留存只剩 5 人，人均时长不到 2 分钟。

这个数据直接告诉我假设错了，不需要再加功能去救。

具体动作：给每个保留的功能写一句"上线后我怎么知道它有用"。写不出来的，砍。

五、加功能必须有外部依据

第二版开始加东西时，加的理由不能是"我觉得应该加"。

外部依据可以是：有人直接问了、有人愿意为它付钱、数据里出现了明确的卡点。三者都没有就先不加。

这一条是防止你在第二版把第一版砍掉的东西又加回来。 我见过不少人在这一步反复横跳。

具体动作：准备一个"待加清单"，每条都要写清是谁提的或者哪个数据支持的。空着的就一直放着。

六、第一个产品怎么控制功能范围：给自己一个硬截止时间

范围控制到最后，本质是时间控制。

我第一款自研小游戏从想法到上线没花太久，问题不在工期，在方向。所以我现在给第一版设的规则是：到一个固定时间点，无论做到哪一步都上线看数据。

没上线的功能，永远只是你的猜想。

具体动作：定一个上线日期，写下来。到这个日期，能跑的版本直接发。

先做哪条：第一个产品怎么控制功能范围的答案

六条里，如果你只做得动一条，做第一条和第六条。

先砍主流程，再定死上线时间。这两条做完，范围基本就自动收敛了——因为时间有限，你会被迫把不重要的东西砍掉。

剩下的四条是防止你在开发过程中反复扩范围，属于防守动作。

常见问题

Q：第一个产品怎么控制功能范围？

A：主流程砍到三步以内，通用模块全部后置到第二版，能用的现成方案不自己写，每个保留的功能都要能对应一个可验证指标。

Q：第一版功能太少会不会没人用？

A：只要主流程能跑通就不会。我那款画板核心只有两步操作，靠自然搜索每天进来几十人，累计收入过了 ¥6000，说明用户要的是能解决问题，不是功能多。

Q：第二版什么时候可以开始加功能？

A：等出现外部依据再加。有人直接提、有人愿意付钱、或者数据里看到明确卡点，三者有一个就够了。