What We’ve Learned About Running a Beta
SSD Nodes had been around for 6 years now, but we’d never run a beta—at least not on an official basis—until last month. In all honesty, that was a scary step for us to take.
Back in early May 2017, we reached out to a select number of current users who, in the past, had mentioned a desire to 1) have a newer kernel on their VPS, or 2) run Docker on their VPS. We got in touch via email and Intercom (the chat interface that appears on our website and dashboard).
We let these users know about our new Virtuozzo 7-powered servers, which come with a 3.10.0 Linux kernel that’s fully Docker-compatible. In exchange for helping out with our beta test, we offered these users a free server for about two weeks, with the option to continue the service after the fact at a discounted rate.
And in the weeks that followed, we learned a number of critical lessons about not only running a beta, but also how we manage our platform and talk with our users.
When we launched the beta, we knew we wanted to target users who had previously expressed interest in Docker, in particular, but it was tempting to simply open the floodgates.
After all, if you can handle the capacity, why wouldn’t you want more beta testers, and thus more data?
But not all beta testers are built the same. Most importantly, existing users bring a certain type of “tribal” knowledge to their beta testing.
For example, our beta testers, being existing users in our Montreal data center, have a good sense as to what kind of network bandwidth they should be able to rely on. When a bug in the Virtuozzo 7 code affected that network capacity, these users were the first to respond and inform us about the issue. In the end, they helped us discover a bug in the Virtuozzo 7 platform that no one else had discovered yet. We sent the bug upstream, and they squashed it and deployed a fix.
If we hadn’t relied upon existing users and their inherent understanding of our platform, it might have taken much longer to understand the scope of this bug and get it fixed.
Every time we’re about to try something big (and potentially risky) here at SSD Nodes, Matt (our founder and CEO) tempers our fear with an important message: We will always learn from the moves we make, but we won’t learn from the moves we don’t make.
Every new project, whether it’s this blog or a beta test, comes with results in the form of both raw data and user feedback, and we can learn from every iota of it. Reminding ourselves of that reality helped mitigate a lot of the initial assumed “risk” in trying something new and different.
That’s not to say we’re going to “move fast and break things,” the famous development strategy that Mark Zuckerberg championed in Facebook’s early days. But if we let our fear stop us from trying something new as a company, we simply won’t be able to compete in a crowded and competitive market.
We recently had a user reach out after seeing that Digital Ocean had just launched a new feature that helps create and customize firewall rules. He suggested it was a feature that we should add to our platform, and we were able to give him the pleasant news that firewall configuration via the dashboard had already been a part of this preview from the beginning.
The problem? The mention of being about to create “sophisticated firewall rules with the ease of a GUI” was rather hidden on on our landing page and in the rest of our verbiage pitching the beta to our users.
In short, we were afraid to lean into our new features because, being a beta, we couldn’t be sure that they were flawless. It took this one user for us to remember that nothing in software is flawless. Many times, it’s better to let people try a feature and have it fail at first than leave them completely in the dark.
After the two-week beta period was over, we launched a public preview of the containers platform, and allowed anyone to purchase a new server. This public preview continues through today, and we’re still working hard on finalizing a number of additional features, such as backups and block storage.
In July, we plan on running another beta test for our KVM option, which will offer custom kernels, custom OS options, and a whole lot more. We think that beta will be even stronger, given what we’ve learned from this effort.
Much of that has been technical, from how we configure servers to the nuances of what make our platform hum, but the most critical lessons have all been in how we talk to and learn from our users.
All in all, we can’t wait for the next great way to talk to you all about how, why, and where you host your services online.