What is early access?

Before Crazy Egg launched in 2006, more than 23,000 people signed up for early access. One of them wrote a blog post asking to get in sooner. I replied with three words: “You’ve got mail…”

His name was Max Limpag. He’d joined our waiting list, but he wanted access sooner. He called the post “I want my Crazy Egg.” Max got his invitation, and the exchange is still online (opens in new tab).

Neil Patel and I were building Crazy Egg to show people where visitors clicked on their websites. More than 23,000 people had signed up before the public launch. We had reached many of them through web design communities and ads on CSS galleries. Over the months leading up to launch, we gave early versions to people in our target audience and watched how they used them.

Early access means letting people use a product before it’s generally available. It could be a private invitation, a public beta, or a paid product still under development. What these have in common is that people get to experience something the team is still improving.

When I run early access, the work often starts before there’s anything to use. I look for people who already have the problem, study how they handle it, and invite them to help shape what we’re making. That’s customer discovery. Once they can use the software, I want to see what happens in their actual work and let that evidence influence what we build next.

I’ve been doing versions of this for more than twenty years. Some experiences helped us find a better direction. At other times, we spent too long pursuing assumptions that should have been questioned much earlier.

This Friday at 10 AM PT, I’ll show how we used early access to learn from real users and change what we built before launching our latest product. Join Early Access 101 for free. (opens in new tab)

The work starts before the invitation

The original Crazy Egg landing page (opens in new tab) was an invitation to people who cared about how their websites performed. Those email addresses told us we’d found substantial interest. We still needed to see whether the software helped people improve their sites.

I saved that page and several other early product pages in an old Hitenism article about validating business ideas (opens in new tab). It has the original landing pages and surveys for Crazy Egg, KISSmetrics, KISSinsights, ShareFeed, and projects that never became recognizable companies. Looking at them now, I’m struck by how much of the work involved finding the right people and asking about what they already did.

ShareFeed began with a simple tool we were already using to find and share links on Twitter. We asked other people about their sharing habits before growing it into a small SaaS product, which Buffer later acquired (opens in new tab).

At KISSmetrics, the consequences of misunderstanding what people needed were much more expensive.

We spent roughly eighteen months pursuing two directions that missed the mark. One was analytics for Facebook application developers who weren’t in a position to support the business we wanted to build. The next required people to invest too much effort in setup before seeing value. We had software to show and people who could react to it, but important assumptions about the customer were still wrong.

I wish we’d studied their existing workflows earlier. We eventually did, particularly how people were using Google Analytics and where it was failing them. That changed the product direction, but we’d already spent a lot of time.

By March 2011, when I presented the KISSinsights story at SXSW, we’d developed a more deliberate process. The original slides (opens in new tab) record about twenty phone interviews, three paper prototype tests, two landing pages, a rough MVP on the KISSmetrics website, and eight alpha testers.

Each gave us something different to work with. Interviews helped us understand the difficulty of getting useful customer feedback. Paper prototypes let us test possible approaches. The rough MVP showed what happened when a feedback tool became part of a real website.

Finding people who can show you the problem

We used a similar approach when Marie Prokopets and I started researching FYI in 2017. We spent five hours writing a six-question survey about people’s work with documents. We avoided describing the product we imagined because we wanted to learn how they currently found and organized files.

The last question asked how they could participate in helping us build the software. People could volunteer to talk, review screenshots, or try an early version. We received 653 survey responses and conducted 52 interviews. Those were two different steps in the research. The interviews helped us understand what people were struggling with and find participants for the next stage.

You don’t need an existing audience of thousands to start this way. Look for the places where people already discuss the job your product could improve. Ask about the last time they did it and what they used. Someone who has worked around a problem for years can often teach you far more than somebody who says a new idea sounds interesting.

The people you invite determine which problems you’ll get to see first.

When Linear was preparing its first product, the team screened people on its waitlist (opens in new tab). It had built an issue tracker aimed initially at small software startups, with GitHub as an early integration. Inviting teams whose work already fit those capabilities gave Linear a way to learn about the core experience before expanding the product.

That gave the team useful feedback on the product it had actually built. It also meant learning from a fairly forgiving group. As Linear expanded access, it would encounter other teams, tools, and expectations.

When your first users love what you’ve built, it’s worth asking whose work hasn’t been represented yet.

A working product changes what you can learn

After the FYI survey and interviews, we built a search-focused MVP in five days (opens in new tab). It connected document services so people could search across them. We tested it over the following month with two groups of ten.

The test exposed a problem that was difficult to settle in an interview. People often couldn’t remember the file title or the keywords they needed. They were more likely to remember who had shared something or what they had been doing when they saw it.

We started exploring ways to find documents through people and activity, not only search terms. That was a product decision shaped by people trying to finish a real task.

I saw the same kind of learning with Beam this fall.

Sam and I kept opening Screen Sharing to reach one application running on another Mac. We built Beam to bring that window onto the computer in front of us. It worked on our machines. On September 5, I asked people on X about their multi-Mac setups (opens in new tab) and invited some of them to try what we’d made.

https://x.com/i/web/status/2096383878336303336 (opens in new tab)

One early tester liked how little of the Mac’s resources Beam used compared with Screen Sharing. Their mouse clicks also landed a few pixels away from the pointer. They had a 50-inch display attached to the other Mac, and getting the window to work comfortably from a laptop was difficult.

We could bring over the window. The tester was still struggling to use it for their task.

Others ran into permission dialogs outside the remote window, sleeping machines, and keyboard or display behavior we hadn’t seen on our own setups. Sam kept improving the product as those reports came in. We worked on input and sizing, added support for more situations involving unattended Macs, and eventually provided a way to control the whole desktop when a single window wasn’t enough.

The environments people bring into early access are part of what you’re testing. That applies well beyond desktop software.

Before eero released its home Wi-Fi system, the team ran a six-month beta across different kinds of homes (opens in new tab). The beta included different layouts, internet providers, devices, and levels of technical experience. One participant even wanted Wi-Fi in a treehouse. A router that works in an office doesn’t establish that it will work in someone else’s home.

These are exactly the kinds of failures I want to discover before opening a product to everyone.

The hard part is deciding what to change

Once real people start using a product, suggestions come quickly. Many are reasonable. They don’t all belong in the product.

A request for more search filters might mean someone can’t find an important document. A request for another dashboard might come from a question a customer needs to answer every week. I try to understand what happened before deciding whether the requested feature is the right answer.

Following those requests too closely creates another problem. A few unusually engaged users can persuade a team to build for their specific habits. Each feature looks justified when considered alone. The result can become harder for everyone else to use.

I’ve learned to ask what the person was trying to do, what stopped them, and how often the problem comes up. Then we have to decide which problem we’re actually trying to solve. Sometimes that means building the requested feature. Sometimes it means choosing a different solution or explaining why we’re not going to do it.

Supergiant Games went further with Hades. The studio designed it around early access from the beginning (opens in new tab). Players used the game while the team developed it, and the release approach influenced the game’s structure and even how its story unfolded. Version 1.0 arrived in September 2020.

Early access can shape a release plan. In some products, it changes the product’s design. The essential work is deciding which observations deserve a response and what that response should be.

What happens when the person needs it again?

The first experience can tell you whether someone gets value. For a product used repeatedly, I also want to understand the next opportunity.

With Beam, the question was which tool someone opened when they needed an app on another Mac again. Some people came back with problems and tried newer builds. A few told us they had started choosing Beam over Screen Sharing for parts of their work. One early user publicly recommended Beam (opens in new tab) after describing nearly a month of beta testing.

https://x.com/i/web/status/2112182511526887805 (opens in new tab)

That was encouraging evidence about particular people. We couldn’t turn those reports into a retention rate for the entire early group.

A person might not return because your product failed them. They might also have no reason to repeat the task yet. A monthly reporting tool shouldn’t be judged by whether someone opens it the following morning. An AI agent might perform its job successfully while the user never visits a dashboard.

I want to know whether the product delivered when it was next needed. And I want to know how much help it took to make that happen.

Rows provides a revealing example of that second question. During its beta, the spreadsheet company spent years onboarding people individually (opens in new tab). Those calls helped the team understand the work and get people to their first useful result. Rows also recognized that the users were unusually motivated and often received personal attention.

When Rows gradually opened access without onboarding calls, it was testing something new. Could a person who’d never met the team get value on their own?

That transition matters for any product whose founders are manually setting up accounts, adjusting data, writing prompts, or fixing problems behind the scenes. Helping people succeed can be the right thing to do early on. Eventually, you need to know what happens without that help.

Be careful what you count as proof

I’ve seen founders celebrate large waitlists and worry about small betas. The numbers deserve a closer look before they drive a decision.

Here are a few from products I’ve worked on or studied:

The Slack example connects to an earlier experiment of mine. In 2015, I worked with volunteers on an open research project about Slack (opens in new tab). We received 731 survey responses. Fifty-one percent of respondents said they’d be very disappointed if they could no longer use Slack.

Rahul Vohra later referenced that research when explaining Superhuman’s approach to product-market fit (opens in new tab). His team surveyed users, studied the group receiving the most value, and worked on the problems standing between other relevant users and that experience. Superhuman reported its “very disappointed” result moving from 22% to 33% when the team narrowed the audience being measured, and later to 58% during further product development.

That survey helped the Superhuman team make decisions. The numbers still need their context. Narrowing the audience changed the score before the subsequent product work; the survey wasn’t a direct measurement of retention or willingness to pay.

The same reasoning applies to early access. A signup can identify somebody worth talking to. A task completed with the founder’s help shows what’s possible under those conditions. An independent attempt tells you something else. A person paying to solve a problem introduces an economic commitment, though it doesn’t prove continuing value.

I prefer deciding what question needs an answer before choosing a metric. The next useful piece of evidence is often more specific than a dashboard number.

Access creates expectations

People who try unfinished products are giving you their time. They may also be handing over data, changing a workflow, or spending money. They need to know what they’re getting.

Steam has unusually explicit rules for paid early access (opens in new tab). A game should offer value in its current state. Developers shouldn’t sell it on promises about features they may never ship. People should be able to understand what works now and what is likely to change.

I think the underlying principle applies to every product category. Describe the state of the product clearly. Make support available. Tell people what feedback you hope to get and what will happen when something breaks. Don’t assume that calling something a beta makes failures inconsequential to the person trying to use it.

We learned that in a very ordinary way while preparing Beam’s commercial release. We introduced accounts and plans. Some existing early users ran into sign-in loops or access they hadn’t expected. We’d spent weeks improving how people reached another Mac, and then our own account system made it harder for some of them to get there.

The account system wasn’t separate from their experience of Beam. It was now part of the product they had to rely on.

Those are the moments when early access can earn trust or lose it. People don’t need you to build every feature they request. They do need an accurate understanding of what they’re using and a reasonable way to get help.

Opening access to everyone changes the test

At some point, the next useful step is to invite people who haven’t been carefully selected or personally helped.

Linear gradually expanded its beta and experimented with an optional paid plan before opening more broadly. Rows reduced its dependence on individual onboarding. In each case, the team could observe what happened under less controlled conditions.

A public release also changes the stakes. Someone using a feature inside an existing product may need a way back to the old workflow. A product handling important operational work may need a higher reliability standard than a reversible experiment. And a product can be useful to employees while still lacking a buyer willing to pay for it.

There’s no universal number of interviews, signups, or happy users that tells you it’s time. You need to decide whether the current product delivers enough value, what failures remain, and what you’ll be able to learn by widening access.

Beam reached #1 on Product Hunt (opens in new tab) on October 19. It was gratifying to see people who’d spent weeks using it recommending it publicly. The launch also exposed us to new questions and setups. Demand for Intel Mac support became more visible, and we shipped it for Macs running macOS 14 or later on October 22.

The ranking was a launch outcome. We were still working on the product, and we still needed to learn what people would choose when they next had the problem.

AI changes the time between building and learning

In 2005, producing a usable product could take a long time. Today I can build a working first version with AI in hours. I can try another approach after an afternoon of research and make a change as soon as someone encounters a problem.

The time it takes to build software has dropped dramatically. The chance to see whether it works in a person’s real job still depends on when they need it.

If your product helps with a monthly financial report, you can rebuild it ten times today. You won’t get ten new month-end reporting cycles to observe. If an AI agent runs in the background, opening its dashboard may tell you very little about whether the work is being completed correctly. You’ll need evidence from the work itself.

For tasks that happen frequently, AI can make the learning loop much faster. A problem observed this morning can become a better version someone tries this afternoon. For infrequent tasks, the wait for another meaningful opportunity remains.

Steve Blank recently wrote about the Initial Untested Product (opens in new tab): software that looks complete before anyone has tested the assumptions behind it. I think it’s a useful description of the risk. Something running on your laptop can feel finished, even when nobody has established whether it solves a problem people care about.

I use AI to organize research, look for competing explanations, and make it easier to prototype changes. Synthetic interviews can help me prepare. They can’t tell me what an actual person did when they needed the product.

We can put working software into people’s hands earlier than ever. We need to be just as deliberate about learning what happens once they have it.

After the invitation

I like that the little Crazy Egg exchange from March 2006 is still online. Max wanted to try the product, and I could let him in.

Since then, I’ve built products where early users helped us find a better direction, and others where we spent too long following our own assumptions. We can build software much faster now. We still need to find out whether it works for people doing the job.

I could send Max an invitation in three words. We still had to build something he’d want to come back to.

This Friday, October 30 at 10 AM PT, I’m opening up the six weeks of early access behind Beam.

I’ll show the original X post that helped us find early users, what happened when they tried the product, and which reports influenced what we shipped. I’ll also share the problems we introduced ourselves and what we still needed to learn at launch.

You’ll get the six-play process and a one-page field card you can use for your own product, whether you’re starting with an idea or already have customers.

Join Early Access 101 for free. (opens in new tab)

I also wrote The Early Access Playbook v2.0 (opens in new tab) as a practical companion to this essay, and documented the six-week Beam story in Would anyone use our product again? (opens in new tab)