操盘手年鉴The Operators’ Almanac
PD · PB · 106

灯塔用户计划

Lighthouse Users Program · lighthouse-users-program--tanguy-crusson
产品方法论 操作手册 过渡期 2024-06 Tanguy Crusson ✓ 已核验出处

解决什么问题

大公司在孵化新产品时,如果按成熟产品的指标(如 MAU)衡量早期项目,团队会被迫过早扩大用户规模,导致大量用户体验粗糙产品后流失,且无法挽回。同时,工程团队远离用户,缺乏直接反馈。

核心内容

将早期客户验证分为三个量级阶段,每个阶段有明确的目标和成功标准:

10 用户阶段(验证问题-方案匹配)

  • 只与 10 个客户深度合作,逐一验证他们的痛点是否被真正解决。
  • 最重要的是向利益相关方解释"为什么这 10 个客户是后续所有目标客户的代理"。
  • 成功标准是定性的:用用户视频通话片段展示他们如何用产品解决问题。

10 → 100 用户阶段(验证方案可扩展性)

  • 招募更多客户,测试核心方案能否覆盖不同场景、不同安全需求、不同使用变体。
  • 仍在非自助模式下运行,但捕捉 10 人阶段遗漏的边缘情况。

100 → 1000 用户阶段(验证自助服务能力)

  • 产品已能解决问题,但需要大量 Slack 沟通、支持工单、Zoom 解释才能用起来。
  • 此阶段的核心任务是解决自助服务障碍:新手引导、文档、产品内引导等。
  • 完成此阶段后"毕业",进入正常增长轨道。

团队面的关键设计:10 个灯塔用户不是只给 PM 看,而是让全员(PM、设计、工程)都在 Zoom 上直接接触,持续数月共同迭代。工程师会主动在规划会上说"我们跟这个客户聊过,他们在这个地方卡住了,我觉得应该先修这个"——从而将"系统工程师"变成"产品工程师"。

适用边界

  • 适用于从 0 到 1 阶段,不适用于已有成熟用户群的产品迭代。
  • 公司如果用 MAU 或客户数等规模指标考核早期项目,此方法会与之冲突——需要提前与利益相关方对齐。
  • 10 个用户必须是经过精心挑选的、能够代表未来目标客群的真实代理,而非随手找的愿意试用的人。

关键引述 · 原话

"I've seen a lot of teams... hiding behind research and not being close enough to the ground with customers." — Tanguy Crusson

关联卡片

与 Point A 框架的 Make 阶段配合使用;与 Safety Funnel / Incubate-Iterate-Integrate 模式互补。

出处Tanguy Crusson · 03-podcasts/tanguy-crusson.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2