From Idea to Launch: Getting Your First Customers

line outside of Apple

After deciding to build an unlimited backup service and developing our own storage platform, the next step was to get customers and feedback. Not all customers are created equal. Let’s talk about the types, and when and how to attract them.

How to Get Your First Customers

First Step: Don’t Launch Publicly

Launch when you’re ready for the judgments of people who don’t know you at all. Until then, don’t launch. Sign up users and customers either that you know, those you can trust to cut you some slack (while providing you feedback), or at minimum those for whom you can set expectations. For months the Backblaze website was a single page with no ability to get the product and minimal info on what it would be. This is not to counter the lean startup “iterate quickly with customer feedback” advice. Rather, this is an acknowledgement that there are different types of feedback required based on your development stage.

Sign Up Your Friends

We knew all of our first customers; they were friends, family, and previous co-workers. Many knew what we were up to and were excited to help us. No magic marketing or tech savviness was required to reach them—we just asked that they try the service. We asked them to provide us feedback on their experience and collected it through email and conversations. While the feedback wasn’t unbiased, it was nonetheless wide-ranging, real, and often insightful. These people were willing to spend time carefully thinking about their feedback and delving deeper into the conversations.

Broaden to Beta

Unless you’re famous or your service costs $1 million per customer, you’ll probably need to expand quickly beyond your friends to build a business—and to get broader feedback. Our next step was to broaden the customer base to beta users.

Opening up the service in beta provides three benefits:

  1. Air cover for the early warts. There are going to be issues, bugs, unnecessarily complicated user flows, and poorly worded text. Beta tells people, “We don’t consider the product ‘done’ and you should expect some of these issues. Please be patient with us.”
  2. A request for feedback. Some people always provide feedback, but beta communicates that you want it.
  3. An awareness opportunity. Opening up in beta provides an early (but not only) opportunity to have an announcement and build awareness.

Pitching Beta to Press

Not all press cares about, or is even willing to cover, beta products. Much of the mainstream press wants to write about services that are fully live, have scale, and are important in the marketplace. However, there are a number of sites that like to cover the leading edge—and that means covering betas. Techcrunch, Ars Technica, and SimpleHelp covered our initial private beta launch. I’ll go into the details of how to work with the press to cover your announcements in a post next month.

Private vs. Public Beta

Both private and public beta provide all three of the benefits above. The difference between the two is that private betas are much more controlled, whereas public ones bring in more users. But this isn’t an either/or—I recommend doing both.

Private Beta:
For our original beta in 2008, we decided that we were comfortable with about 1,000 users subscribing to our service. That would provide us with a healthy amount of feedback and get some early adoption, while not overwhelming us or our server capacity, and equally important, not causing cash flow issues from having to buy more equipment. So we decided to limit the sign up to only the first 1,000 people who signed up; then we would shut off sign ups for a while.

But how do you even get 1,000 people to sign up for your service? In our case, get some major publications to write about our beta. (Note: In a future post I’ll explain exactly how to find and reach out to writers.)

Public Beta:

For our original service (Backblaze Computer Backup), we did not have a public beta; but when we launched Backblaze B2 Cloud Storage, we had a private and then a public beta. The private beta allowed us to work out early kinks, while the public beta brought us a more varied set of use cases. In public beta, there is no cap on the number of users that may try the service.

While this is a first-class problem to have, if your service is flooded and stops working, it’s still a problem. Think through what you will do if that happens. In our early days, when our system could get overwhelmed by volume, we had a static webpage hosted with a different registrar that wouldn’t let customers sign up but would tell them when our service would be open again. When we reached a critical volume level we would redirect to it in order to at least provide status for when we could accept more customers.

Collect Feedback

Since one of the goals of betas is to get feedback, we made sure that we had our email addresses clearly presented on the site so users could send us thoughts. We were most interested in broad qualitative feedback on users’ experience, so all emails went to an internal mailing list that would be read by everyone at Backblaze.

For our Backblaze B2 public and private betas, we also added an optional short survey to the sign up process. In order to be considered for the private beta you had to fill the survey out, though we found that 80% of users continued to fill out the survey even when it was not required. This survey had both closed-end questions (“How much data do you have?”) and open-ended ones (“What do you want to use cloud storage for?”).

By the way, despite us getting a lot of feedback now via our Support team, Twitter, and marketing surveys, we are always open to more—you can email me directly at gleb.budman {at} backblaze.com.

Don’t Throw Away Users

Initially, our backup service was available only on Windows, but we had an email sign up list for people who wanted it for their Mac. This provided us with a sense of market demand and a ready list of folks who could be beta users and early adopters when we had a Mac version. Have a service targeted at doctors but lawyers are expressing interest? Capture that.

Product Launch

When?

The first question is when to launch. Presuming your service is in public beta, what is the advantage of moving out of beta and into a “version 1.0,” “gold,” or “public availability?” That depends on your service and customer base. Some services fly through public beta. Gmail, on the other hand, was (in)famous for being in beta for five years, despite having over 100 million users.

The term, beta, says to users: “Give us some leeway, but feel free to use the service.” That’s fine for many consumer apps and will have near zero impact on them. However, services aimed at businesses and government will often not be adopted with a beta label as the enterprise customers want to know the company feels the service is ready. While Backblaze started out as a purely consumer service, because it was a data backup service, it was important for customers to trust that the service was ready.

No product is bug-free. But from a product readiness perspective, the nomenclature should also be a reflection of the quality of the product. You can launch a product with one feature that works well out of beta. But a product with fifty features on which half the users will bump into problems should likely stay in beta. The customer feedback, surveys, and your own internal testing should guide you in determining this quality during the beta. Be careful about “We’ve only seen that one time,” or “I haven’t been able to reproduce that on my machine,” those issues are likely to scale with customers when you launch.

How?

Launching out of beta can be as simple as removing the beta label from the website/product. However, this can be a great time to reach out to press, write a blog post, and send an email announcement to your customers.

Consider thanking your beta testers somehow—can they get some feature turned out for free, an extension of their trial, or premium support? If nothing else, remember to thank them for their feedback. Users that signed up during your beta are likely the ones who will propel your service. They had the need and interest to both be early adopters and deal with bugs. They are likely the key to getting 1,000 true fans.

The Beginning

The title of this post is “Getting Your First Customers” because getting to launch may feel like the peak of your journey when you’re pre-launch, but it really is just the beginning. It’s a step along the journey of building your business. If your launch is wildly successful, enjoy it, work to build on the momentum, but don’t lose track of building your business. If your launch is a dud, go out for a coffee with your team, say, “Well, that sucks,” and then get back to building your business. You can learn a tremendous amount from your early customers, and they can become your biggest fans, but the success of your business will depend on what you continue to do the months and years after your launch.

print

About Gleb Budman

Gleb Budman is a co-founder and has served as our chief executive officer since 2007, guiding the business from its inception in a Palo Alto apartment to a company serving customers in more than 175 countries with over an exabyte of data under management. Gleb has served as a member of our board of directors since 2009 and as chairperson since January 2021. Prior to Backblaze, Gleb was the senior director of product management at SonicWall and the vice president of products at MailFrontier, which was acquired by SonicWall. Before that, he served in a senior position at Kendara, which was acquired by Excite@Home, and previously founded and successfully exited two other startup companies.