ChurnBee taught me that even if you do most of things right, there is still room for failure. And startups have innate affinity towards failure and will seek every opportunity to fail should you foolishly offer it.
2013 was a very fruitful year, if I measure it by the amount of work done. I launched or co-launched no less than four startups that year. And all of them failed (I’ve covered them all in post mortems). This is the story of the fourth one – ChurnBee.
ChurnBee was literally born in a single morning, proving that you can start a startup with minimum cost and effort.
The idea? ChurnBee (a.k.a. “the NewRelic for startup CEO/founders”), a dashboard built specifically for SaaS businesses focusing on key subscription-business goals for every startup.
As opposed to the ability to track a number of standard and/or custom metric and define funnels (like KissMetrics or MixPanel), it offered ready-made recipes which helps founders focus on the key drivers for SaaS business – MRR, Churn, LTV/retention, Growth Ceiling, signups w/ Trailing Six Month Compound Growth Rate, and so forth. To provide useful and unique context, every recipe incorporated personalized industry best practices on targets, standards, or norms from experts like Jason Cohen, David Skok, Joel York and Dave McClure.
ChurnBee offered a special aggregate dashboard for people involved in multiple companies (advisors/investors/accelerators&incubators) called “Control Bridge”, which allows one to login with his/her portfolio companies, considerably saving time for doing reviews and going through key metrics.
ChurnBee would use ‘recipes’ that you can add together to create various dashboards.
Here is an example of tracking signups by using a couple of ‘recipes’.
I am very passionate about SaaS analytics and I was certain that businesses needed a better tool than what was available on the market. For one, we used a custom dashboard at ManageWP and I wanted to change that.
We put up a simple landing page and things started great.
In just one month we already had 350 signups.
All kinds of businesses were craving for a tool promising simplicity and actionable data.
Here is an example of user feedback we received during this period.
I signed up because I am working on a SAAS product and know metrics are everything!
I am excited to see what CHURN BEE has to offer. I am always being asked “what is the lifetime value or each customer” and “what is your cost per customer.” I am a programmer, not a statistician. I hope CHURN BEE can help in this area.
Glad to hear about Churn Bee, sounds like a great simple idea.
I’m a web developer at storyful.com and I’ve love learn more about churn bee. We currently use mixpanel/GA and it doesn’t provide the seamless solution which we would love.
Five months later we gathered 1,000 signups and decided it was time to launch the service.
On Nov 5th 2013, ChurnBee beta was officially launched.
Things were looking great. Among other things we got exposure on TNW, people included us in SaaS tools lists and developers started creating github repositories for integrations with the ChurnBee API!
So how could have this gone the wrong way?
The answer is, we screwed up the thing we were confident it – the technology. And we did it in two ways.
The first was that the integration from the user perspective was painful. Although the API was easy to use, a developer still had to manually connect data points in an app with ChurnBee. We even had problems connecting all data points in our own app ManageWP and it was clear that that was not going to work in scale. Meanwhile startups like Baremetrics were doing less robust analytics but with basically no integration. Our beautiful dashboards didn’t matter because nobody was getting to them! If I had to do it again I would go the baremetrics route – dead simple integration first, dashboards second.
The second problem was that building analytics is very technology and resource intensive. We had only a small team of developers, inexperienced with those kind of challenges. Our ambition was too big for the resources we had at home.
After we started signing up first users, these two problems started getting very obvious. We weren’t able to get many of them past the integration point, and for those we did, the software started breaking. Since we still didn’t have all features out, fixing bugs started being a huge obstacle for new feature development.
And even if we could deal with that by getting more engineers on the team, in the long run the difficulty of integration and system design itself was just too big of a hurdle.
Without the idea of a pivot we slowly started giving up on it. In retrospect, perhaps it was a hasty decision, but we were not 100% into this and our paycheck did not depend on it so that’s how we found justification to give up as easily.
The aftermath was around $40k spent and a valuable lesson learned: getting technology right is harder than you may think.
This was different to all the other startup failures I described and at the time came as a surprise. Previously we failed always because we failed to reach users , not with the product itself.
But this also proves an interesting theory: startups have innate affinity towards failure and will seek every opportunity to fail, should you be foolish enough to offer it.