Posted by Richard White
Fri, 01 Sep 2006 18:01:00 GMT
I was lucky enough to get in on the demise another Web 2.0 institution in the latest episode of the Web 2.0 Show aptly named "The DEATH of Web 2.0" (in a very tongue in cheek way). Josh, Chris and myself discuss SlimTimer, making the jump from developer to interface designer, AjaxScaffold and Streamlined collaboration, and of course Kiko (which I'm sure you haven't heard enough about). As an added bonus, if you listen carefully you'll be treated to a cameo by my wonderful dog, Emma, around the 20 minute mark.
I'm also putting the world on notice that, with two slayings in as many weeks, I can dismantle any Web 2.0 operation for the right price.
Posted by Richard White
Fri, 18 Aug 2006 01:31:00 GMT
With all of the buzz about Kiko
's demise (and how Web 2.0 is going with it) I thought, as a member of the Kiko team, I'm in a good position than most to give a detailed explanation of what we learned and what went wrong. Be warned, this post will be long on facts and stories so if you're looking for assumptions and hand waving I'd suggest reading some other posts* :)
First, a few common questions:
Did you see Google Calendar coming?
Yes. It had been in internal beta for over a year and not all the Googlers at the 'plex are good at keeping secrets. The launch that really surprised us was 30boxes.
Did Google Calendar kill Kiko?
No. One of our biggest traffic days was when Google Calendar was released because we were mentioned in all the new stories as one of their top competitors. In fact, we repositioned Kiko to take advantage of a market that most other players, including Google Calendar, were neglecting: users outside the US. We added options
like Monday week start and different date formats. We setup a wiki and let our users translate Kiko into 11
languages. And we moved away from a US-only SMS reminder system to one that worked internationally. At last count 60-70% of our users are from outside the US.
That said they did have an impact on our ability to garner press for our re-launch (see below) but it wasn't a case of Google coming into the calendar space and stealing all of our users.
Where was the business model?
Everything was predicated on getting a critical mass of users. Without that there's no point in coming up with alternatives and if you do achieve it then you can monetize through the usual hannels (ads and premium accounts). I agree with the 37signals argument that having paying customers forces you to hone in on what that market wants, and that probably would have done us a lot of good, *but* that's not why we went under (see next question). Many people seem to disagree with me on this point so feel free to post your counter arguments (or links to them).
Why did you guys decide to call it quits?
We didn't have the capital, and not just in the monetary sense, to take Kiko where we thought it would successful: the small business / OEM market. The team was burned out and we decided that it was time to find someone else to carry the torch. We did not run out of money. In fact, we pulled up well short of the end of our runway. So if you'd like to make the argument that our lack of a business model did us in, go for it, but it has little basis in reality. For more about this, read my Kiko eulogy.
And now, what I learned on my web 2.0 voyage
Stay focused
Justin mentioned this on his post mortem write-up but I'll elaborate a bit more. We were on track to release the new version of Kiko in the middle of January, when we *lost focus* and starting working on something totally different altogether. This was obviously a suicidal move in hindsight as it cost us 2 months: Kiko 2.0 launched on March 15th instead of January 15th. During that time two important things happened:
- 30Boxes came out of nowhere and launched on Feb 14. Thus becoming the new internet calendar darling.
- Screenshots of Google calendar were leaked and posted all over the internet.
The combination of those two events meant we got very little press coverage for our launch (or re-launch) since everyone was holding their breath for Google Calendar or fixated on 30boxes.
Release early, but not too early
You always hear "Release early, release often", especially if you hang around Paul Graham crowd, but the footnote that doesn't get enough airplay is that you shouldn't release too early (queue the sophomoric jokes in 3.. 2..). You only get one shot to impress people; don't blow it because they won't coming back next week to see if you've improved. Kiko 1.0 was released in September 2005 and was met with much fanfare for being one of the first AJAX calendars on the web. Unfortunately, the user interface was pretty bad (which is how I pushed my way onto the team) and people generally said "wow that's cool… next!"
The obvious problem is that when we launched version 2.0 I think the general reaction was "Kiko? Seen it. Hey how bout that new Google Calendar coming out?".
Too many features killed the cat
It didn't look it at first, but if you played around with Kiko 1.0 for 15 minutes you found out that there was a *lot* of functionality under the hood. Problem was that we felt we needed to bring *all* of that functionality over to Kiko 2.0. I mean you can't cut features between versions, right? Wrong. We should have cut features, probably about 40% of them and launched.
This also contributed to our late launch and slowed us down after the launch because we had so many features to maintain.
You must have a plan for escaping the Technosphere
To a degree, it didn't matter how many posts we got on TechCrunch, LifeHacker or Scoble; we would still be stuck in the same Technosphere duking it out with Google, 30Boxes and everyone else. You can make a nice living just pimping your wares in the technosphere (which is what I'm attempting with SlimTimer) but if you ever want to gain any real traction as an online calendar service you have to target the cubicle dwellers and their Outlook calendars that only exist outside the sphere. Techie users are fickle, transient and demanding. You can spend all of your time implementing ATOM feeds and hCalendar export and never be the better for it.
We didn't have a plan for how to go mainstream, which, in hindsight, was a prerequisite for our success. We would have needed capital to do old school PR, marketing and sales and develop a sync service for Outlook. That said, I don't think either of Google Calendar or 30Boxes have managed this feat either.
...
Regardless, we were feeling pretty good about ourselves around the middle of April. We were running neck and neck with 30boxes, according to Alexa, and we thought that the release of Google Calendar might be good because it would push one of the other big players into acquiring a calendar application to compete. 30boxes had stated that they didn't want to be bought out so, as the #3 player, things were looking hopeful. Things didn't pan out, but that's okay. None of us were ever had a Lexus on hold; we were just happy to be in the fight.
So, What's next for me? Well the 'next big thing' for me is already here: SlimTimer, online time tracker and the solution to the scourge of timesheets, launched to positive reviews a month ago and I'm working hard to keep the momentum going.
Digg
It! Reddit
Addendum (8.20.2006)
Stowe Boyd notes that an incomplete feature set, not Google Calendar or an empty business model, was a primary reason for our poor user
adoption and retention rates. Ineffective social networking components and no integration with complementary
applications, specifically Outlook calendar, were also significant factors in our demise (see other factors
above). Our social networking components, contact management and calendar sharing, *were* ill-conceived and,
despite making Outlook integration a top priority *after* we released, we were not able to follow through.
Our contact management and calendar sharing implementation did not meet our users' needs because we never
defined our target market. In addition, our designs for how these features should behave were negatively
affected by our marriage to the existing, and broken, workflow in Kiko 1.0. Techies, families, social groups,
and businesses all have different needs for sharing their calendar data with others and, by ignoring that
fact, we created a solution that met no one's needs. I think we knew that we were going down the wrong path
but we were so wrapped up in launching that no one could say what needed to be said: "fix it or dump it". We
would have been better off scrapping it and letting our early adopters tell us how it should work rather than
release something half baked (which would have also meant *less* features than 1.0 *gasp* -- see 'Too many
features killed the cat' above).
Our Outlook integration development was a disaster. Problems with vendors and team members (see hire slow, fire fast on Justin's post)
led to a protracted death. This was a morale killer not only for the team but for our users as well and was
the beginning of the end of our operation.
Footnotes
* The shot at Dharmesh's article is simply good natured ribbing. The fact that he posted on my blog and
linked to it makes me feel that he knows that. I mean it's not like I would really expect him not to make
assumptions since he can only analyze the situation from the outside, like everyone else (then again I guess
he could have emailed one of us). I just wanted to make a point that my article has a different point of
view.
Posted by Richard White
Thu, 17 Aug 2006 21:57:00 GMT
AjaxScaffold has been deprecated in favor of ActiveScaffold
I kinda let the cat out of the bag on this one with a comment this morning on the Streamlined blog. Justin Gehtland and myself have hatched an elaborate scheme to combine the best bits of both projects: the wonderfully declarative backend of Streamlined with the UI pleasantries of AjaxScaffold.
The tentative plan is to release the plugin version of AjaxScaffold that I’ve been using/testing extensively in SlimTimer. After that I will be looking to transition the project into more of a maintenance mode: putting out releases only as bugs are found. I feel that adding more features, such as search and improved handling of object relationships, would be redundant to the work on Streamlined and would make the project more complex than need be.
This is a huge win for RoR community, the users of each of these projects and myself.
AjaxScaffold will continue to be viable option for lightweight admin components but should you need more features Streamlined will be there in all its declarative loveliness and hopefully a hot new look.
Special thanks go out to Dan Snider for bringing both sides to the table and getting this ball rolling.
See Justin’s announcement
Update 10.20.2006:
The plugin version has been a huge success and has also really energized me again on the whole project. As such, we’re pushing ahead with new releases including those features I mentioned here that would not be done :)
We may still EOL the generator but the plugin is going strong.
Posted by Richard White
Thu, 17 Aug 2006 05:57:00 GMT
It was both a sad and liberating day for me as Kiko dived into the deadpool. I won't get into all of the
dynamics of the situation, but, in a nutshell, we had lost our spark and were letting our users down
by not improving the product the way we should have. We felt it best to move on to other ventures rather than try and drag this
one along even further.
I am actually proud of this exit strategy in a way. While it's not the one we envisioned going into things, I still think we are doing our best
to satisfy the two most important stakeholders in Kiko: our investors and our users. We do care about our investors' money and
instead of just burning through the rest of the piggy bank trying to get our groove back we are trying to recoup their investment (we stand to gain
little from the auction). We have also put in place both iCal export and account deletion so our users can take their data with
them over to another calendar service if they so choose (or stick with Kiko while we find an acquirer).
While Kiko may be seen by some as a another web 2.0 failure, for me personally it's been the catalyst for the greatest period of self development in my
career. Without Kiko there is no AjaxScaffold, SlimTimer or Brighthouse. Without Kiko I have a lot less really smart friends and cool "I met _____!"
stories.
So thank you to Justin and Emmett, Kiko's founders, for rolling the dice on a guy you'd never met in person and thank
you to our users for all your kind words and tolerance of our mistakes.
Update: I've also posted a take on what we learned and what we screwed up.
Posted by Richard White
Thu, 17 Aug 2006 04:59:12 GMT
The Geek TV crew was at OffTheGrid and I was lucky enough to even be included in some of the footage (I’m about 2/3 of the way through if you want to skip all those other jokers). I had a great time and was able to both sterotype myself and make friends at the same time, so mission accomplished. I want to give some shout outs to my new friends: John, Robert, Wayne, Aaron, Heather, Michael and Christian.
Hopefully the impassioned and zealtrous on film argument about PHP v Python v Ruby between John, Michael and myself will see the light of day (If not I’d like it for the home videos to show the grandkids one day). In it I sound like a total 37signals zealot talking about constraints and conventions but that’s what you get when you mix beer, geek egos and a camera. The oh so predictable developer argument began with the simple question “How does Rails help you write more maintainable software?”. I have had a lot of thoughts on the subject lately and started a manifesto of sorts of the subject of software maintainability for web applications. I’ll try and post that sometime soon.
