f01-four-stage-evolution

name: f01-four-stage-evolution description: | 用户有一个产品想法但在犹豫是否要开始写代码时；或用户问"我应该如何验证我的想法"时。用户处于"想创业但不知道从哪开始"的迷茫期，试图找技术合伙人或购买SaaS工具跳过验证阶段。不适用于：已有成熟产品需要迭代的情况；用户已有明确PMF（产品-市场契合）证明需要规模化。关键trigger信号："我有一个App想法"、"要不要先做个原型"、"不确定有没有市场" source_book: 《极简主义创业》 Sahil Lavignena source_chapter: 第三章「越少越好」 tags: [product-development, automation, process] related_skills: [p03-less-is-more, p07-software-not-labor]

极简主义创业四阶段演进框架

R — 原文 (Reading)

"你需要按照正确的顺序完成这些阶段，否则你会陷入永无止境的产品开发地狱。你的客户不是在为你将要构建的产品付费——他们在为你今天能解决的问题付费。"

— Sahil Lavignena, 第三章

I — 方法论骨架 (Interpretation)

这个框架揭示了产品开发的正确顺序不是"创意→代码→发布"，而是人工→流程化→产品化→自动化。

第一阶段"人工"是最被低估的起点：创始人自己充当服务者，用时间和技能直接解决客户问题，同时记录每一个步骤。这个阶段的核心不是"做得慢"，而是"学得快"——没有任何软件能替代真实客户互动中的信息密度。

当人工服务积累了足够的重复性操作，就进入第二阶段"流程化"：把记录下来的步骤整理成文档或清单。流程化的标志是：一个新员工能否在文档指导下独立完成这项服务？

第三阶段"产品化"是把流程变成可销售的软件或服务。此时开发者介入才有意义，因为产品需求已经被真实数据定义清楚了。

第四阶段"自动化"是让产品自行运转，创始人可以退出日常操作，转向更大的问题。

核心洞察：产品不是起点，流程才是。产品是流程的最终形态，而非起点。

A1 — 书中的应用 (Past Application)

案例 1: Gumroad 的起步

问题: Sahil 想验证"帮设计师卖数字产品"这个想法是否有市场需求
方法论的使用: 他没有先开发软件，而是手工帮每个客户处理 PayPal 付款——手动收集信息、月底手动转账
结论: 有人在付钱，这个需求是真实的
结果: 手工服务持续了数月后才开发软件，验证了需求才投入技术资源

案例 2: Endcrawl 的片尾字幕服务

问题: 影视公司需要快速处理片尾字幕，但市场上没有现成工具
方法论的使用: Endcrawl 创始团队用 Google 表格和 Perl 脚本手动处理，完全不用软件 UI
结论: 15分钟可以完成原来24小时的工作，市场存在
结果: 手工流程跑通后才开发产品，避免了"没人用的完美软件"

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill？

用户有一个产品想法，但不确定有没有市场，正在考虑"要不要先做个原型"
用户试图找技术合伙人或购买 SaaS 工具来"跳过"前期验证
用户在讨论"MVP 应该包含哪些功能"，而不是"MVP 之前应该做什么"
用户说"我担心自己的想法太小众，不值得做"
用户在构建产品时遇到瓶颈，迭代了很多版本但没有人用

语言信号 (用户的话里出现这些就应激活)

"我有一个 App 想法，但不确定市场"
"要不要先找个技术合伙人"
"我的 MVP 应该有几个功能"
"我在做一个 SaaS 产品"
"我已经做了 6 个月产品，但还是没用户"

与相邻 skill 的区分

与 p03-less-is-more 的区别: p03 是"克制做产品的冲动"，f01 是"按顺序经过四个阶段的框架"；p03 关注"不要做什么"，f01 关注"按什么顺序做"
与 f02-community-driven 的区别: f02 关注"从社区发现问题"，f01 关注"验证后如何演进"；f02 是起点，f01 是全程地图

E — 可执行步骤 (Execution)

当 skill 被激活后，agent 应按以下步骤执行:

识别当前阶段
- 完成标准: 确认用户处于哪个阶段（人工/流程化/产品化/自动化），通过问"你现在是怎么服务客户的？"来判断
倒推到前一个阶段
- 完成标准: 如果用户在做软件，问"你手工服务过多少客户？"如果答案是0，跳回阶段1；如果答案是几个，评估流程是否固化
- 判停条件: 若用户从未手工验证过，直接跳到步骤 2.1（重新开始人工阶段）
完成当前阶段的核心任务
- 阶段1: 用人工服务10个客户，记录每个步骤
- 阶段2: 把步骤整理成文档，让非创始人也能执行
- 阶段3: 用代码实现文档中的流程
- 阶段4: 消除创始人参与，建立监控和异常处理机制

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

用户已经有了明确的产品-市场契合信号（100+付费回头客），正在考虑规模化——此时应该用 f06-growth-stages
用户的问题是"如何融资"而非"如何验证"——这个框架不解决资本问题
用户在做 B2B 企业销售，需要定制化交付而非标准化产品——流程化可能不适用

作者在书中警告的失败模式

"跳过人工阶段直接做产品，就像在黑暗中射击——你可能在做没人要的东西"
"很多创始人把'忙碌'和'进展'混淆。手工服务客户是忙碌，建立流程是进展，写代码只是记录进展"

作者的盲点 / 时代局限

框架假设所有服务都可以最终自动化，但某些服务（如高定制化咨询）本质上不可自动化
框架对"速度"的要求可能过高——对于需要快速抢占市场的竞争性行业，跳跃式发展可能是必要选择

容易混淆的邻近方法论

精益创业 MVP: 精益用软件做最小化产品，这个框架更进一步——用人工做最小化服务；精益是"减少功能"，这个框架是"替换工具"
Y Combinator 的"做人们想要的东西": 两者都强调验证，但 YC 更强调速度，这个框架更强调顺序

审计信息

验证通过: V1 ✓ / V2 ✓ / V3 ✓
测试通过率: 待测试
蒸馏时间: 2026-04-17