Opening up Helios to the world, and other learnings on going from a private beta to a fully-open product.
I’m excited to share that today, we’re making Helios available to all developers around the world for free.
Helios is a developer platform that helps increase dev velocity and productivity when building cloud-native applications. Over the past few months we’ve worked closely with dozens of private beta users to build a product that we believe will make a difference. We now have a strong conviction that Helios can make an impact on developers’ day-to-day, save them time and make it a bit more enjoyable to develop distributed applications.
Opening up our product to self-serve onboarding is a cultural decision, more than it is a go-to-market strategy. It solidifies the DNA of our company, from its very early days, to be focused on developers – our core users – and how we can enable them to get more value out of our product. I’ve put together this blog post to share our thought process behind making this move, what we learned along the way, and where we hope to go from here.
Why we decided to open up Helios to free self-serve onboarding for all
❊ To put the developer at the center of what we do
We truly believe that Helios needs to deliver value even to a single developer before it can capture value. Opening up our product holds us accountable to focusing first and foremost on optimizing for the developer journey, as a core company value.
❊ To build a delightful product
Having Helios used by many developers is an efficient strategy for gathering feedback that matters. Our assumptions over our users’ biggest pain points and what is most valuable to them can now be validated (or refuted), quickly and at a larger scale than what could have been achieved had we not gone down this path. These insights enable us to build the best developer platform possible.
❊ To live by our mission
We joined Helios because we’ve truly bought-into the mission of improving the developer journey when working on cloud-native and distributed applications. It’s personally important to us that our product gets into the hands of as many developers as possible around the globe and that even the free-forever plan makes an impact on dev teams’ day-to-day work.
❊ To embody empathy when thinking about our users
We are a team of developers, who ourselves use many SaaS products for a range of needs. We expect to understand how a certain product can help us, fast, by getting our hands dirty with it. So really, what better way to get developers familiar with our product than by making it widely available to all.
❊ To lay the foundation for growth
Product-led-growth (PLG) is a strategy that, when executed well, powers the company’s non-linear growth, driven by early product adoption and user advocacy. Developing our B2D approach from the bottom up will pay dividends when we get to the top-down sales motion.
❊ To “just do it”
There are always so many concerns that are top of mind before you release your product to the world: it’s not there yet, it’s embarrassing (as Reid Hoffman says, “If you are not embarrassed by the first version of your product you’ve launched too late”), it doesn’t do much, it can do so much more, there are still little quirks and edge cases that need to be solved, etc. A big part of me still thinks this is true for Helios. But what can’t be denied is that our developer platform – imperfect as it is – is already delivering value; developers are using it and paying for it. So today seems like the perfect time to put ourselves out there.
Making it real
When we decided a couple of months ago that the time had come to conclude the private beta and open up our product, we knew this effort would require cross-team planning and collaboration – and focus. In this section I’d like to share our thought process for getting the product ready and available. Note this is not an exhaustive description of the launch program, which also included activities across the entire company and specific launch goals.
To kick off the planning process, we started with some research – both on products we ourselves use and love, and on literature and content on this topic. For example, Userpilot published an excellent piece, The ultimate guide to self-served onboarding in the product-led era, where they detail how to prepare for self-serve onboarding (including the epiphany that in order to scale, you need to be prepared to ‘do things that don’t scale’); another great resource was OpenView’s Your guide to self-serve onboarding: How to get your product to sell itself providing concrete suggestions on how and where to improve onboarding. We then used the Product-Led Growth Collective PLG Flywheel framework to combine the research findings with our own product vision. We created this high-level plan of important items that need to be taken care of in order to open the product:
We then ran an intense prioritization drill to ask ourselves, honestly, what the bare minimum is that we need to do to support the goals of each phase and to trim this list even further.
The first meaningful milestone we achieved was the launch of the Helios Sandbox. Optimizing for the developer meant that we had to make a conscious effort to cut through the noise and get to the essence of the product really fast. We took our internal demo environment (that had some mock data running through it already), beefed it up a little, added a simple guide highlighting interesting experiences in the Sandbox, and made it available on our website without requiring authentication.
This immediately made it so simple to share the Sandbox – with prospects, investors, and also our own friends and colleagues. More importantly though, it was putting a stake in the ground for our product and rallying the team around making it available to all, for real. Suddenly there were no secrets, it was just out there.
What we learned at Helios from the process of opening up our platform to all developers
❊ Shift left
At Helios we speak a lot about ‘shifting left’ and empowering developers as early as possible in the development process to identify and troubleshoot issues. This ‘shift left’ mindset was something we also embraced when thinking about enabling the developer to experience the value of our platform as early as possible in his/her journey. As I wrote earlier, this mindset has transformed the DNA of our company forever.
❊ Plans and pricing
We decided a while back to offer a usage-based pricing (UBP) model as (a) it’s simple, and (b) it aligns the value provided really well with the value captured. We tested it out a bit during our private beta and already have customers paying based on this model. When we decided to publish a pricing page on our website, we performed a thorough analysis to create well-defined plans, and also decide which PLG model we’re going to use (opt-in free trial, regardless of our free-forever plan).
❊ Helios Sandbox is essentially another product
Once the Helios Sandbox was out, suddenly internal issues with generating the mock data became a lot more critical. So, we made it more robust and implemented the right testing and monitoring to avoid regressions and to make it as stable as possible. We started analyzing how users are interacting with it, and quickly created a wish-list for the Sandbox itself to improve and make it better. Another thing we didn’t take into account initially is how wide-spread access from mobile devices was going to be, so we needed to adapt some things there as well to make the Sandbox mobile-friendly (traditionally, our product is not something that is used from a mobile phone).
❊ Data
Shifting from beta customers to an open product also forced us to put in place a solid analytics / usage tracking system, and hone in on strategic decisions such as what is our north star metric? How do we count “aha moments” and activations? What makes a product qualified lead (PQL)? What goals/milestones should we be celebrating? Etc.
❊ Bonus – focus
Working together with the team of superstars I’m fortunate to have with me at Helios while we make our product available to all, rather quickly, is a reminder of how much can be achieved when a strong team can focus on a clear goal.
Conclusion
Opening up Helios so that any developer can use it is an important milestone for our team – and it’s only the beginning. This is an enabler to fulfill our mission of improving how distributed applications are developed and we’re excited to continue our journey at Helios, together with our users.
Back to OpenView’s guide, opening up a product is not just a pricing thing – “It means designing for the end user and helping those users see value as quickly as possible.” It’s a mindset that defines the company’s DNA. Developers are at the core of what we do and why we do it; to that end, it’s important for us to provide value – quickly – to any developer working on cloud-native and distributed applications. We hope developers sign up, experiment with, and enjoy the product – and we welcome any and all feedback as we work to make it better.
