In the first two posts, I covered the “lightbulb moment,” validating the idea, scoping the MVP, and starting to code.
Cirrus Insight Origin Story series:
- Part 1: The “Lightbulb Moment” and identifying the problem
- Part 2: Validating the Idea, Scoping the MVP
In this post, I describe when I realized that I needed help and how we got to the point of launch.
Bringing in help
Up to this point, it had been a creative problem-solving exercise and coding. Fun stuff! But as soon as I had other people testing the early extension, the full scope of everything that lay ahead hit me… Not only did I have to build the app, but I was starting to realize all the other things that needed to be done to get this app out to market — not to mention supporting it and growing it.
There are some people who can do it all. I can code, and I’m competent in a lot of other areas, but I think this is just too much for one person to worry about all at once.
If you truly want to create something new and bring it to market, you’ll do it faster with a partner.
I go into more detail about how and when to select a co-founder in the post above, but I’ll keep it simple here: I was fortunate enough to have Brandon Bruce as one of my best friends. Aside from being smart and as eager to start something new as I was, he works harder than anyone you’ll ever meet. I’m not kidding; it’s exhausting and exhilarating.
Brandon and I had always shared the ambition of starting a company together and had taken a couple of shots at it during college (including a wine.com killer 😂). And importantly, he and I had a complementary set of skills: I was more technical, and he was more “salesy.” As I was still knee-deep in coding and we had a growing group of users playing with the app, we decided he’d do everything outside of coding for the moment, including getting a website up and handling incoming bug reports.
Running the beta
Once we had a (really bad) website up, we created a mailing list, and we started expanding our list of users invited to try the app. We still kept it to Salesforce consultants and MVPs, but we didn’t ask anyone to keep it a secret. We would send out weekly emails to our users, keeping them up to date on the latest additions and fixes to the app.
Continuous feedback loops
As the number of users grew, the support effort increased, and we started getting more and more feature requests. We didn’t want to lose track of this feedback, so we set up an Ideas forum for our beta users to submit and vote on ideas from other users. This was one of the best early decisions we made. It allowed us to engage with our growing beta user base and establish the beginnings of a methodology around collecting and quantifying user feedback. This helped us build a devoted user base and continue to build a solution that directly addressed user problems.
One important input we asked of our users was to ask them if they thought we were ready to launch at that time. We were surprised by how early they felt we were ready; while it seemed like the bus was on fire to us, most of our beta users felt it was ready weeks before we finally agreed to launch. While I don’t think we were ready to launch when our bleeding-edge beta users thought we were, their confidence in the app gave us the confidence to pull the trigger earlier than we probably would have otherwise.
Back office (boring) stuff
Speaking of the bus being on fire, as our beta user group started expanding, we realized we were going to get overrun quickly if we didn’t have a system for managing users. We needed to be able to manage trial periods, payment processing, customer licenses, user status, and 50 other things. I had recently built a License Management system in Salesforce for a customer, so I decided that it was better to add this to the list of pre-launch tasks rather than trying to manage it after launch.
I’ll skip the details, but despite adding several weeks to the plan, building our License Management in Salesforce ended up being crucial to the two of us being able to handle the pace of adoption we would see after launch. It evolved dramatically over the years, and it was never perfect, but this was the backbone of our user operations for over seven years.
Unfortunately, by the time we were at a size where it made sense to transition to something more Enterprise-grade, like Zuora, our license management system was so ingrained, not only into our operations but also our product, that it was too much effort to unwind.
The choice is either implement a complex (and expensive) system early and grow into it, or face growing pains of outgrowing a home-grown system. I don’t regret the decision we made here.
Ready for Launch
After over five months of development, collecting user feedback, and building everything else that went into being a semi-functional startup company, we decided to launch. Our beta process lasted about ten weeks, and during that time, we had amassed over 1,000 beta users. Five months is a long time, and I’m sure it could have been faster if I had made a number of different decisions, but I didn’t. I’d encourage startups I advise to launch earlier than this, but this was our path.
Next, LAUNCH!
Originally published at https://www.fractionalfounders.tech on April 1, 2023.
