Cohort-Gated Private Beta
Onboard early users in small waves so each cohort surfaces new bugs instead of duplicating the last cohort's feedback.
- Difficulty
- Easy
- Time to result
- ~months to results
- Steps
- 3
- Confidence
- 90%
Rather than opening an early product to everyone on the waitlist at once, Linear invited roughly ten people a week, fixed what that cohort hit, then invited the next cohort. Because a fresh product has obvious shared problems, a mass invite just generates redundant reports of the same bug; small sequential cohorts turn each wave into a fresh layer of feedback.
Origin
How Karri Saarinen ran Linear's ~1-year private beta, manually inviting users from a survey-gated waitlist.
Core principles
- 01A very early product has shared failure points, so many users will independently report the same problem
- 02Redundant feedback is wasted effort for both users and the team
- 03Fixing between waves means each new cohort discovers the next layer of issues, not the same one
- 04Manual, hands-on invitation lets you select for fit and follow up personally
How to run it
- 1
Gate the waitlist with a qualifying survey
Collect not just emails but what tools they use today, why they want the product, and company size, so you can prioritize who fits your current capabilities.
Pro tip Only invite segments your product already supports; you don't have to serve everyone in the first months.
- 2
Invite a small cohort (~10/week)
Read the actual survey responses, pick a small batch that fits, and send personal invite links; follow up after a few days to ask what they think.
Pro tip Prioritize people who show genuine interest over 'I just want to try it out' signups.
Watch out Don't scale the cohort size until earlier waves stop surfacing new blocking issues.
- 3
Fix the cohort's blockers, then invite the next wave
Collect the cohort's feedback, fix the problems they hit, and only then release the next cohort so they encounter new issues rather than the same ones.
Pro tip This cadence doubles as your development roadmap: user-reported blockers set the fix order.
Watch out If you invite everyone at once you lose this staged signal and drown in duplicate reports.
In the wild
After announcing on Twitter, Linear had ~4,000 waitlist signups within about a month. Karri read surveys in a spreadsheet, emailed invite links from his personal email ~10 people a week, gathered each cohort's feedback, fixed it, then invited the next cohort for roughly a year.
→ By public launch they had several hundred companies using it, and nearly every one converted to a paid plan.
Common mistakes
Inviting the whole waitlist at once
Everyone hits the same early-stage bugs simultaneously and floods you with identical feedback, wasting their effort and yours.
Collecting emails without qualifying data
Without tools-used and company-size info you can't prioritize the users your product can actually serve today, so early testers churn on gaps you already know about.
Is it for you?
Best for
Early-stage founders running a private beta with a waitlist larger than they can support at once
Not ideal for
Consumer/viral products where growth speed matters more than depth of iterative feedback
From the transcript
“if you just invite everyone at once or a lot of people at once all of those people going to probably hit the same problems…”
“we would just do this cohorts like let's invite these people and then they say like like hey this is a problem”
“in the beginning we maybe invited like 10 people a week”
“after after a month uh or so we had like maybe 4,000 people on the waight list”
“I would go read the actual surveys like in a spreadsheet then I copy the email and then I email them the invite link from…”
From the episode
Inside Linear: Building with taste, craft, and focus
Karri Saarinen (co-founder, designer, CEO)