Pieter Levels 的公开构建经历，常被概括为“一个人做出多个产品并获得持续收入”。但如果把项目、分发和收入结果拆开看，这更像是一套在特定能力与外部条件下逐步形成的经营方法，而不是一条可以直接复制的成功公式。对准备启动 OPC 一人公司的创业者来说，真正值得研究的不是某个营收数字，而是他如何选择问题、压缩产品范围、快速上线、处理用户反馈，并把公开构建变成分发渠道。

从“做很多东西”开始：先验证行动能力，而不是寻找完美方向

Pieter Levels 早期公开提出过“12 startups in 12 months”的挑战：在较短周期内连续尝试多个创业项目。这个做法的核心并不是要求每个人一年做出十二家成功公司，而是把“寻找创业方向”从长期研究，变成一连串可交付、可观察的产品实验。

在传统创业叙事中，创业者通常会先写商业计划、做完整市场调研，再投入较长时间开发产品。Levels 的公开构建路线则更接近另一种顺序：

1. 先识别一个自己能够理解的问题；
2. 用尽可能小的产品形态上线；
3. 观察是否有人访问、注册、付费或持续使用；
4. 再决定继续投入，还是转向下一个问题。

这套方法降低了单个项目的沉没成本。产品没有获得反馈时，损失主要是时间；一旦出现明确需求，再逐步增加功能和投入。

但这里有一个容易被忽略的前提：快速试错并不等于随意做产品。能够连续尝试多个方向，需要开发者具备较强的实现能力、基本的产品判断、快速发布能力，以及承受项目被放弃的心理准备。对于仍然需要数周甚至数月才能完成第一个可用版本的人来说，直接模仿“多项目并行”可能只会增加混乱。

公开挑战的价值，在于建立反馈节奏

“12 startups in 12 months”最值得借鉴的地方，不是项目数量，而是它把创业变成了有时间边界的验证流程。

时间边界会迫使创业者回答几个具体问题：

• 这个问题是否足够明确，能否在短期内做出可用版本？
• 用户是否已经在用其他方式解决它？
• 最小版本上线后，什么行为可以被视为有效需求？
• 如果没有反馈，什么时候停止继续开发？

对 OPC 创业者来说，可以把一个产品实验压缩成四个阶段：

这个表格中的“信号”不是固定指标。对于订阅软件，可能是试用转付费和留存；对于信息服务，可能是重复访问和付费订阅；对于面向数字游民的社区或目录产品，则可能是持续流量、会员购买和用户提交内容。

Nomad List 和 Remote OK：从具体人群切入，而不是从“大市场”开始

Levels 公开项目中较具代表性的两个产品，是面向远程工作和数字游民场景的 Nomad List 与 Remote OK。它们并不是从“服务所有互联网用户”开始，而是围绕相对具体的人群和工作场景展开。

Nomad List 关注不同城市对数字游民的生活与工作条件，例如生活成本、网络、气候和社区等信息。Remote OK 则围绕远程工作的职位发现。两者都将用户对“地点选择”或“远程工作机会”的模糊需求，转化为更容易浏览和筛选的信息产品。

从产品选择角度看，这类项目有三个特点。

第一，用户问题具体，产品边界容易描述

“帮助人们做更好的人生选择”过于宽泛，而“帮助远程工作者比较不同城市”就更容易转化为页面、字段和筛选条件。

一个小产品初期不需要覆盖完整行业，只需要先回答一个窄问题：

用户来到这里时，是否能比原来更快地完成一个决定？

如果答案是肯定的，产品就有机会从信息整理、搜索或目录服务起步。它未必一开始就是复杂的软件，也不一定需要大量自动化功能。

第二，数据和内容本身可以构成产品体验

这类项目的价值不完全来自代码。数据结构、更新机制、排序方式、筛选条件和页面呈现，同样决定了用户是否愿意持续使用。

因此，独立开发者不能只问“我能不能把功能做出来”，还要问：

• 数据从哪里来？
• 谁负责更新？
• 信息过期后如何处理？
• 用户为什么相信这些信息？
• 哪一部分内容是可积累的资产？

如果产品依赖外部数据、用户提交或社区贡献，维护成本可能随着规模增长而上升。看起来简单的目录产品，长期经营时可能需要处理数据准确性、重复内容、恶意提交和客服问题。

第三，窄人群更容易形成早期分发

远程工作者、数字游民和独立开发者都有较强的线上聚集特征。他们常出现在社交平台、论坛、社区和行业媒体中，产品也更容易围绕明确关键词被发现。

这并不意味着只要选择一个细分人群就一定能获得流量。更准确的说法是：当用户群体足够清晰时，创业者更容易找到他们、理解他们，也更容易用他们熟悉的语言描述产品价值。

快速上线不是粗制滥造，而是把复杂度推迟

公开构建模式强调快速上线，但快速并不代表一开始把所有功能都做得很粗糙。它更接近于：只实现当前验证所必需的部分，把暂时无法证明价值的复杂度推迟。

以一个远程职位产品为例，最小版本可能只需要：

• 职位列表；
• 基础筛选；
• 职位详情；
• 提交或发布入口；
• 一个能够完成付费或联系的流程。

它未必一开始就需要复杂的推荐算法、企业后台、多角色权限、移动端应用和完整的数据分析系统。

这是一种“先验证主路径”的产品策略。主路径通常是：

用户发现产品 → 理解价值 → 完成关键动作 → 获得结果。

如果主路径还没有被验证，提前开发外围功能只会让产品看起来更完整，却无法回答最重要的问题：用户是否真的需要它。

复杂度控制的判断标准

独立开发者可以用三个问题判断某项功能是否应该现在开发：

1. 没有它，用户是否无法完成核心任务？
2. 它是否会直接影响用户是否付费或继续使用？
3. 是否已经有真实用户明确提出，并且这种需求重复出现？

如果三个问题的答案都是否定的，功能通常可以延后。

这套方法尤其适合一人 SaaS。单人团队的最大限制不是想法少，而是同时处理开发、设计、客服、销售、内容、财务和运维。每增加一个功能，就可能增加测试、文档、兼容性和售后负担。

用户反馈：从“听意见”转向“观察行为”

公开构建经常被理解为持续发布开发日志、进度和收入变化。但对于产品经营来说，公开表达只是反馈系统的一部分，不能替代对用户行为的观察。

用户说“这个产品很有用”，是一种信号；用户实际注册、使用、付费、续费或主动推荐，则是更强的信号。两者之间可能存在明显差距。

反馈可以按强弱分层

对于独立开发者来说，反馈还应当尽量转化为具体任务。例如，用户说“筛选不好用”，需要进一步确认是筛选条件不够、结果不准确，还是页面无法理解；用户说“希望增加某个功能”，则需要判断这个功能服务的是一个人的特殊偏好，还是一批用户共同遇到的问题。

Levels 的公开构建方式提供了一种低成本获取反馈的渠道：把开发过程、产品变化和经营结果展示出来，让潜在用户主动回应。但这种方式仍然要求经营者能够区分噪声与信号，而不是被每条评论牵着走。

公开构建降低了部分获客成本，但也提高了表达要求

公开构建的商业价值，不只是“让别人看到你在开发”。它可能同时承担三种作用：

• 建立可信度；
• 提前积累潜在用户；
• 将产品开发过程转化为内容分发。

当一个产品从零开始公开迭代时，创始人发布的内容本身就可能成为产品的早期入口。用户可以看到产品如何变化、问题如何解决，也更容易形成对创始人的认知。

这对一人公司尤其有吸引力，因为内容、产品和个人品牌可以共享同一套时间投入。一次产品更新，既可以成为开发记录，也可以成为社交平台内容、邮件通知或社区讨论的主题。

公开构建并不等于公开全部经营信息

适合公开的内容包括：

• 当前正在解决的问题；
• 新增了什么功能；
• 用户反馈带来了哪些调整；
• 哪些尝试没有效果；
• 产品接下来准备验证什么。

不一定适合公开的内容包括：

• 用户个人数据；
• 未经授权的客户信息；
• 具体合同和敏感财务细节；
• 可能影响安全的系统信息；
• 容易造成误解的单月收入截图。

公开构建需要建立边界。它的目标是提高信任与分发效率，不是把所有经营数据变成公共材料。

内容分发存在明显的个人优势差异

Levels 的公开表达能力、技术能力和线上影响力，是其分发效率的重要组成部分。其他创业者可以借鉴“持续公开、围绕产品讲故事”的方法，但不能假设自己会获得同样的曝光。

如果创始人不擅长社交媒体，也可以采用更稳定的分发方式：

• 针对用户问题制作搜索内容；
• 建立邮件列表；
• 参与垂直社区讨论；
• 与相关服务商合作；
• 发布案例、教程和产品更新；
• 直接联系早期目标客户。

公开构建是一种渠道，不是渠道本身的替代品。

收入结果要拆成四个问题，而不是只看数字

关于 Pieter Levels 的项目，网络上经常流传收入和利润数据。这些信息有一定参考价值，但在分析时必须先区分数据来源、统计口径和时间范围。

公开收入通常可能是：

• 创始人自行披露的数字；
• 某个月或某个阶段的收入；
• 总收入而非净利润；
• 多个项目合计，而非单个产品；
• 订阅、广告、招聘发布、会员或一次性付款等不同来源的混合。

因此，看到一个公开营收数字时，至少应拆成四个问题：

1. 这是收入、利润，还是年化收入估算？
2. 统计的是哪个项目，还是整个个人业务组合？
3. 收入是否具有持续性，还是来自短期流量或一次性交易？
4. 经营者投入了多少时间、技术资产和既有受众？

只有在这些问题得到回答后，数字才有经营分析价值。

公开营收不能直接等同于可复制结果

同样的产品模式，换一个人执行，结果可能完全不同。原因包括：

• 个人已有技术能力不同；
• 是否有稳定的线上受众不同；
• 产品上线时的市场环境不同；
• 领域竞争强度不同；
• 维护和客服能力不同；
• 对风险和收入波动的承受能力不同。

更合理的学习方式，是把收入结果当成案例终点，再向前追问支撑条件，而不是把它当成保证。

持续经营：产品组合可以分散风险，也可能放大负担

Levels 的案例还体现出一种产品组合思路：不把全部收入和时间押在一个项目上，而是经营多个具有不同用户和收入来源的产品。

这种方式可能带来几个好处：

• 某个产品流量下降时，其他产品仍可能产生收入；
• 不同项目可以共享技术、内容和分发能力；
• 创业者可以在不同市场之间测试机会；
• 成功产品的现金流可以支持新项目试验。

但产品组合也会带来管理成本。每个产品都可能需要：

• 修复故障；
• 处理支付和退款；
• 回复用户问题；
• 更新依赖和基础设施；
• 处理数据、隐私与合规事项；
• 持续解释产品价值。

如果没有清晰的维护标准，多个小产品最终可能变成多个需要随时响应的客户服务台。

可以建立“继续经营”而不是“继续开发”的标准

产品上线后，不应只看是否还能增加功能，还要判断它是否值得继续占用经营资源。

可以从以下维度评估：

• 收入是否稳定，还是完全依赖偶发流量；
• 用户是否持续使用；
• 支持成本是否可控；
• 产品是否有清晰的增长渠道；
• 是否存在明显的平台或合规风险；
• 它是否与其他业务共享资产；
• 停止维护的机会成本是否更低。

有些产品不适合继续扩张，但仍然值得保持低维护运行；有些产品虽然有收入，却消耗了过多客服和运营时间。对一人公司来说，“不再加功能”与“彻底放弃”之间，还有收缩、自动化和降低服务承诺等经营选项。

哪些做法适合借鉴，哪些条件不能照搬

把这个案例转化为 OPC 方法，可以分成“可复用原则”和“不可直接复制的条件”。

更适合借鉴的部分

用小产品验证，而不是先构建完整公司。 先验证用户是否愿意采取行动，再决定是否扩大产品范围。

围绕具体人群和场景选题。 细分用户更容易理解、更容易触达，也更容易发现重复问题。

把用户行为放在口头反馈之前。 评论和点赞可以帮助发现方向，但付费、留存和推荐更能说明产品价值。

控制产品复杂度。 优先建设影响核心任务和经营结果的功能，延后边缘需求。

把公开构建作为分发实验。 持续记录问题、过程和结果，观察它是否带来访问、注册、反馈或成交。

给项目设置停止或收缩条件。 没有明确退出标准，快速试错很容易变成长期拖延。

不适合直接照搬的部分

“一年做很多项目”的节奏。 这依赖高开发效率和较强的切换能力。对多数创业者来说，同时经营过多项目会降低质量。

公开收入截图带来的激励。 收入数字不能代表利润、稳定性和可复制性，也不能反映全部投入。

完全依靠个人品牌获客。 有影响力的创始人可以降低早期分发成本，但普通创业者仍需要建立可持续渠道。

极简产品的技术和运营结构。 看似简单的产品可能依赖多年积累的开发经验、基础设施能力和自动化能力。

跨多个产品经营的方式。 组合业务需要稳定现金流、维护体系和时间管理能力。没有这些条件时，单产品聚焦通常更稳妥。

给 OPC 创业者的一套小产品验证流程

如果把上述经验转化为可以执行的流程，可以从一个四到八周的验证周期开始，而不是直接复制多项目创业。

第一周：明确人群和问题

写清楚三个句子：

• 我服务的是哪一类具体用户？
• 他们在什么场景下遇到问题？
• 现在通常用什么方式解决？

如果这三个问题都无法回答，说明选题仍然过于宽泛。

第二周：确认现有解决方案

不要只研究竞品页面，也要研究用户的替代方案。替代方案可能是表格、邮件、人工服务、社区帖子或多个工具的组合。

有替代方案并不代表不能创业。相反，已有替代方案说明问题可能真实存在。关键是确认新产品能否在速度、准确性、便利性或价格上提供清晰改进。

第三至四周：上线最短主路径

只完成一个核心结果。例如：

• 让用户找到一个职位；
• 让用户比较几个城市；
• 让客户生成一份结果；
• 让服务提供者获得一个有效线索。

这阶段不追求完整品牌体系，也不急于开发复杂后台。先确保用户能够从进入产品走到获得结果。

第五至六周：收集行为与付费信号

记录访问、关键操作、注册、试用、付费、留存和反馈。对用户访谈时，不要只问“你觉得怎么样”，还要问：

• 你之前如何解决这个问题？
• 最近一次遇到这个问题是什么时候？
• 哪一步最浪费时间？
• 如果这个产品消失，你会回到什么替代方案？
• 哪个结果值得你付费？

第七至八周：做出经营决策

根据证据选择四种路径之一：

• 继续扩展；
• 缩小目标用户；
• 调整定价或交付方式；
• 停止投入并保留经验。

停止一个没有形成信号的项目，并不代表验证失败。它可能帮助创业者排除一个不值得继续投入的方向。

结语：值得复制的是判断过程，不是公开结果

Pieter Levels 的公开构建案例，最有价值的地方不在于“一个人做了多少产品”或“某个项目产生了多少收入”，而在于它展示了一种不同的创业节奏：先用小产品接触真实需求，再通过用户行为决定投入；同时利用公开表达获取反馈和分发，但不把曝光误认为产品价值。

对 OPC 创业者来说，这套方法可以沉淀为几个基本判断：

• 产品是否解决了一个足够具体的问题；
• 最小版本能否在短期内上线；
• 用户是否愿意采取真实行动；
• 公开构建是否带来可观察的分发结果；
• 收入是否稳定到值得继续维护；
• 经营者是否具备支撑这种模式的技术、表达、运营和风险承受能力。

这些问题没有统一答案，也不能保证任何人获得相同结果。公开案例真正能提供的，是一套观察经营过程的框架：把产品迭代、分发方式、用户反馈和收入结果分别分析，再根据自己的能力与资源决定哪些可以尝试，哪些只能作为别人的特定条件。