案例库

Pieter Levels:多产品组合与自动化运营案例

基于 Pieter Levels 的项目清单和公开复盘,分析多产品组合、自动化运营以及哪些条件不能被新手直接复制。

可复制的是快速验证、公开记录和自动化思路,不可复制的是长期受众与既有分发优势。

作者
AOPC 编辑部
发布
AOPC 编辑部
发布时间
更新
2026/7/20
核查
已核查
公开项目记录和复盘资料经过人工核查后形成多产品组合案例结论
从公开来源到可核查案例结论的证据路径

经营快照

30 秒经营判断

一人经营模式复制难度:高
产品
Nomad List、Remote OK 与公开项目组合
目标客户
寻找城市、社区和远程生活信息的数字游民
团队状态
创始人主导产品组合,公开资料出现承包商、合作方和用户贡献
商业模式
会员、社区服务与远程招聘职位付费
主要获客
公开发布与持续更新项目
经营证据
有经营披露
核查日期
2026/7/20

收入与成本边界文章只引用带日期的创始人公开披露,并明确标记未经独立审计;不把历史数字写成当前收入。

方法标签

本案例可学习

产品类型
社区平台、企业服务
商业模式
订阅制、多产品组合

60 秒结论

一分钟看懂这篇文章

可复制的是快速验证、公开记录和自动化思路,不可复制的是长期受众与既有分发优势。

人负责

  • 选择问题
  • 决定取舍
  • 承担产品责任

AI 负责

  • 公开工具未完整披露
  • 自动化重复运营
  • 辅助信息整理
  1. 核查来源
  2. 拆解产品
  3. 判断边界
  4. 提炼经验

直接结论

Pieter Levels 的公开资料支持一个有限结论:他长期发布多个产品,让相邻产品围绕数字游民、远程工作等需求形成组合,并把数据聚合、筛选和发布中的重复步骤交给软件系统。这个案例值得学习的是低成本试验、持续迭代和流程化运营,不是“项目越多越好”或“一个人可以不用承担运营责任”。

本文不提供当前收入结论。来源中出现的收入都属于特定年份或访谈时点的本人披露,未经独立审计,也不能外推到 2026 年。当前团队、外包规模和完整技术栈均未公开。

证据状态

  • 公开事实: 截至 2026 年 7 月 19 日,项目清单页面可直接看到 Nomad List、Remote OK 等项目及其状态,也同时列出大量失败、停止或非营利项目;Nomad List 五周年页面展示了城市数据、用户评论、众包图片和合作数据等产品机制。
  • 创始人自述: Levels 在 2019 年复盘中称 Nomad List 的首版于五年前发布;在 2022 年访谈中,他回顾 Remote OK 从聚合岗位到向雇主收取发布费的过程,并提到当时有承包商处理客户支持。这些说法没有在本文中被当作独立审计事实。
  • 编辑判断: 多产品不是目的。较有价值的模式是先验证一个窄问题,再让同一客群的相邻需求共享认知与分发;是否适合新经营者,仍取决于获客能力、数据责任和人工容量。

产品与目标客户

Nomad List 面向需要比较城市、远程生活条件和社区信息的人。2019 年五周年复盘公开展示了城市数据、匿名评论、众包图片与地点索引等机制。Remote OK 则把远程岗位求职者与发布岗位的雇主连接起来。

两者相邻但并不相同:一个帮助用户判断在哪里生活和工作,另一个帮助用户寻找或发布远程岗位。项目清单还显示他做过许多未成功或已经停止的尝试,因此不能只看留下来的产品,再倒推出每次发布都会成功。

商业模式与获客

2022 年访谈中,Levels 回顾 Remote OK 早期先聚合其他招聘网站中的远程职位,后来开始向直接发布岗位的公司收费。具体收费数字和收入曲线属于当时的创始人自述,本文不把它们写成当前价格或当前收入。

公开资料反复出现产品发布、公开记录和社交媒体传播。编辑部据此将公开发布、长期内容记录、搜索与口碑视为主要获客路径,但不把某一次病毒传播归因于可稳定复制的公式。市场时点也很重要:Levels 在访谈中明确把 Remote OK 后来的增长与远程工作市场变化联系起来。

人工工作与自动化

可以确认的系统化部分包括岗位聚合、数据筛选、地点索引、用户评论与众包图片流程。2019 年复盘还写到外部数据合作和语言匹配。这说明软件、用户贡献和合作数据能够减少重复录入,但不等于数据无需审核或产品无需维护。

人的工作仍包括选择问题、定义字段、调整产品规则、处理异常和承担收费与数据责任。2022 年访谈提到当时有客服承包商,因此“完全由一个人完成所有运营”不成立。公开来源没有完整披露当前人员安排,也没有披露可用于这些核心产品的完整 AI 工具链;本案的 aiStack 因而记录为“未公开”。

可复制做法

  1. 从一个具体问题发布可用的小版本,让真实行为而不是宏观趋势决定下一步。
  2. 把项目状态、失败和复盘保留下来,避免只展示幸存项目。
  3. 将可规则化的数据收集、筛选与发布做成系统,同时保留异常处理入口。
  4. 在同一客群中寻找相邻需求,但要求每个产品各自有清楚的用户与付费理由。
  5. 对收费、数据质量和用户支持设置人工责任人,不把自动运行等同于无需治理。

不可复制条件

Levels 的长期个人受众、搜索资产、品牌认知和公开分发记录不是新项目上线时自动拥有的。数字游民与远程工作在特定年份的市场变化也无法通过照抄页面或功能重现。

项目组合还会放大维护、支持、数据授权和注意力切换成本。没有稳定获客渠道与取舍规则的新经营者,同时启动许多项目更可能稀释验证,而不是形成组合优势。

AOPC 适配判断

本案与 AOPC 相符的部分,是经营者亲自决定问题和规则,让软件承担大量重复执行,并通过多个数字产品放大个人产出。不相符或证据不足的部分,是它并非“只有创始人、没有其他人参与”:来源明确出现过客服承包商、数据合作方和用户贡献,当前协作结构又未公开。

因此,适配结论是“部分符合,可借鉴系统化方法,不可当作纯一人全自动模板”。AOPC 实践者应复制清晰责任、窄范围验证和可审查的自动化,不应复制未经验证的项目数量、收入预期或技术栈。

来源

所有商业结果与经营过程均按来源时点理解;本文的 AOPC 适配结论属于编辑判断,不构成收入预测或经营承诺。

从案例到行动

前 30 天怎么借鉴

不照搬结果,只把案例中可复制的方法拆成三个验证阶段。每一步都要结合自己的客户证据重新判断。

  1. 第 1–7 天

    收窄问题

    用小版本验证具体问题,再依据真实使用反馈迭代

  2. 第 8–14 天

    验证流程

    公开记录成功、失败与项目状态,保留可追溯的学习材料

  3. 第 15–30 天

    形成闭环

    把数据收集、筛选和重复发布流程做成系统

唯一主行动

把下一步变成可执行动作

阅读对应工作流