This post formerly appeared on the Cloudlab Blog. Cloudlab was a SAAS product that failed to get traction and wound-up in June '12. It is reproduced here for posterity.
Since launching cloudlab we've gathered a wealth of lessons on what to do (and not to do). In this update, we're going to share some interesting analytics and some hard-learnt lessons with you in the hope you can see where we're going with cloudlab.
We chose Hacker News (HN) as our first point of release. HN is a great site to get brutally honest feedback and as far as prospective customers go, represents the scene we're primarily targeting. After a good half-day, it also showed up on Reddit.
Graphs & Numbers
Both of these sites (and the aggregators following them) generated a nice bit of traffic:
In terms of conversion (new users), if we take the number of visits as ~950 and the number of new users as ~50, roughly 5.2% of users who saw the landing page decided to sign up. Awesome!
Looking a little deeper at user engagement the result was surprising:
Of the users who signed-up, only 25% of actually made it to the meat of the product, the IDE. This is the part of the product that is the most awesome, yet only one percent of all visitors made it there!
Demographically, the U.S. and Europe represented the majority of visits which lines up with expectations:
Nearly three quarters of the traffic directed at the server was from a WebKit browser, with the next ~25% being Mozilla-based:
Good news is that the server held-up and had no troubles with our provider AppHarbor.
First Impressions Last
What a turd. Since they're apparently too good for their "links" to be actual links
<a data-target="#registerModal" data-toggle="modal" class="btn btn-large btn-success">
a user with noscript
Analysis: we use Bootstrap extensively. Opening modal dialogs can be done be done with a
href or a data attribute. This was a usability problem that was foreseen but put on the backburner - who cares about the landing page when the meat of the work is behind the scenes? USERS CARE.
(sorry, I'm sure it's a cool project, but I'm not signing in to anything just to test it, unless it's really, really worth my time)
a user with a good point
... the fixed password policy isn't really amusing. I guess you guys will track it and see what happens, but I bet that you'll notice a way depressed return user rate, because every time I'll want to log back in I'll need to go search through my email first, and I'll never really "activate" as a user after the first time or two playing around.
a user with a very good point
Analysis: trying to make registration painless is something you want. We thought that by sending passwords out in the mail and logging you in immediately, this would be as painless as possible. The fixed-password policy which account recovery easy while ensuring robust security. WRONG.
Solution: use BrowserID. Don't have to worry about passwords or email verification.
Crux of the Matter
There was one major piece of feedback that really struck home:
What kinds of data formats do you support, and how big can the data get? I have something like 5 terabytes of data lying around waiting to be analyzed. JSON doesn't really sound compelling when I'm talking about huge matrices or gigs of timeseries data.If your scripting environment makes lots of assumptions about your platform in a way that makes it nonportable code, and you don't open-source it, it'll be hard to get people to make the investment and move projects onto your platform now knowing it could disappear at any time.
We agree. Going down that path of making all data JSON in a RDBMS was a road that ended up being a dead end. To date, less than ten new sets of data have been uploaded. It's a monumental failure. People don't want to have to convert their data to JSON and then back again. It's a transport language dummy!
So now we're going down the Dropbox route. You link your account and we pull and push files from your favorite provider. If you don't have a Dropbox account, they give you a 2GB one for free. To enable this different way of treating data, we've partially implemented a number of CommonJS specifications.
No plan survives battle, and no launch goes according to plan. Feedback, no matter how harsh, is something that validates and disproves any preconceived notions you have about what you're trying to make. Revel in it and most importantly, learn from it.