The Lighthouse Users Program (10 → 100 → 1,000)
Deliberately serve a tiny, named set of customers through defined stages instead of chasing MAU too early
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 3
- Confidence
- 95%
Rather than measure a new product on monthly active users, define success as progressing a deliberately small cohort of customers through three stages: 10, then 100, then 1,000. Each stage answers different questions and graduates only when its bar is met. It gives the team room to build the right thing, protects existing customers from a half-baked experience, and reframes success as qualitative learning (user snippets) rather than vanity metrics.
Origin
A term used informally at Atlassian that Tanguy Crusson formalized into a named, staged program for Jira Product Discovery; conceptually paired with Reforge's 'safety funnel' idea (limit how many people get a bad early experience).
Core principles
- 01A small number of named customers you can empathize with beats large-sample surveys for an early product
- 02Define success qualitatively (user video snippets) while the product is immature
- 03Put a hard stop on how many people get a bad early experience
- 04Embrace that you can't yet serve the majority — so don't measure yourself as if you can
How to run it
- 1
Recruit 10 lighthouse users and justify WHY they are the 10
Work with exactly 10 customers and prove the problems they had are the ones you solved. Spend most of your energy explaining why these 10 are a valid proxy for every customer you'll serve later.
Pro tip Answer every stakeholder question with a snippet of a user video call — them describing their problem and showing how they solve it in the product.
Watch out If you can't articulate why the 10 represent the future base, you're optimizing for a non-representative niche.
- 2
Grow 10 → 100 to catch variation
Recruit more customers (still not self-service, still hands-on) and test the core solution against the different scenarios, security needs, and subtleties that only surface across a wider set.
Watch out Between 10 and 100 you discover the edge cases that would have broken a premature public launch.
- 3
Grow 100 → 1,000 by removing the hand-holding
The solution works but still needs explaining via Slack, Zoom calls, and support tickets. Getting to 1,000 forces you to solve onboarding and self-service so the product can stand on its own — then you graduate.
In the wild
The 10 lighthouse users were put in front of the whole team — PM, designer, and engineers — on recurring Zoom and Slack syncs over months. In planning, an engineer could say 'wait, we talked to this customer and they struggle with X, let's fix that instead,' turning system engineers into product engineers.
→ Direct customer empathy drove prioritization; the product moved fast and shipped something customers pulled for rather than a spec pushed at them.
Common mistakes
Hiding behind research
As products grow, teams lean on formal user research and CSAT/NPS surveys and lose direct contact with the ground. Aggregate data rarely triggers the emotional pull that makes a team actually change the product; knowing 10 customers by name does.
Is it for you?
Best for
An early-stage product team that must resist pressure to scale a new bet before it's ready
Not ideal for
A mature product where you genuinely need statistically representative samples and broad rollout
From the transcript
“which is the lighthouse users program”
“the first stage is we work with 10 and we prove that the problems that they had are the things that we solved”
“everything that explains why we believe they are a proxy for every customer that will serve afterwards”
“then we get to a stage where we're like you know what it's good it solves people's problems but it's not self-service”
“the way I call it it's hiding behind research and not being close enough to the ground with customers”
From the episode
Hard-won lessons building 0 to 1 inside Atlassian
Tanguy Crusson (Head of Jira Product Discovery)