Itch-scratching at its finest

Joshua Schachter had 20,000 bookmarks he was tracking in a single text file. He knew his homegrown system was breaking down and decided to develop a web-based system to manage his bookmarks. In 2001 he had a working version that published his bookmarks to his site and he was getting 10k visitors per day. By late 2003 he had reworked the system to be a multi-player version which we now know as del.icio.us. By the end of 2004 del.icio.us had 30k users.

Being over-capitalized would have killed it

Schachter attributes the success of del.icio.us as a product to the fact that it emerged slowly as a hobby site rather than a rocket-fueled, VC-funded company. It was constructed using best practices from everything he had learned in building his own bookmark tracking system so it incorporated the set of essential features that had been validated through personal usage. Schachter said, “I think in general being overcapitalized is a path to failure. The VC’s want you to spend. There are general ills with being over-funded…There was no point at which I said, ‘I’m inventing this wonderful new thing.’ I just sort of realized that I had evolved my own filing system, and it worked for me. I’d used it for a long time before del.icio.us even showed up. This was the codification of that practice.”

How to triage feature requests

Schachter said, “I think people ask for features - they want to do something, but they don’t say, ‘I want to do that something.’ They translate it into some feature that typically they’ve seen somewhere else and ask for that instead…So, stuff that people ask for, I tend to try and dig to the root cause, before reducing to practice.”

I recently wrote a piece called “How to tap the knowledge you don’t know you don’t know“- it covers this very scenario. There is a rift in translating customer needs into product features. The bridge-building that occurs in order to understand the desired feature set is typically done by the product development team soliciting feature requests from users. Schachter’s advice is to instead seek the root cause behind the features they’re requesting. For instance, in our realm, users of traditional installable desktop software typically aren’t aware of the capability to ship a mini virtual computer that is fully preconfigured and self-contained- they don’t know what they don’t know about virtual appliances and therefore the features they request are related to usability failings with their current, known offering. It’s up to product development team to cross that divide and help “build the bridge of understanding” from the customer end by understanding their needs and requirements rather than seeking implementation-level feedback.

More 37signals philosophy

Schachter echoes two of the core 37s tenets of “Embrace Constraints” and “Less Mass.” Schachter found that through working on del.icio.us during his full-time job at Morgan Stanley he had to work in bursts of fifteen-minute windows where he would be under hard time constraints and therefore severely limited in what features he could add. These constraints forced him to squeeze ultra productivity from the limited time he had and meant the product had less mass in terms of extraneous features. He says, “Reduce. Do as little as possible to get what you have to get done. Do less of it; get it done. If you’ve got two things that you want to put together, take away until they go together. Don’t add another thing. Because you can understand it better, you can analyze it more cleanly. The UI will be easier. Doing less is so important.”

On explaining a difficult value proposition

Schachter said, “It is a challenging product to do conceptually. It’s not something like, ‘Lets you file your taxes better.’ There’s no clear value proposition here. It is valuable, but hard to understand. You will be able to remember more things this way, and with that, people don’t even realize there’s a problem. So that’s a challenging value proposition to explain or get across.” I sympathize with Schachter on this because it’s a service that until you use it, you don’t fully comprehend what it does for you. Similar to the StumbleUpon service, it’s just not something that you need but it’s something that’s certainly useful once you use it.

The freedom paradox: “a robot on rails”

For all the apparent freedom that founders have in building their startups, once you’re in motion down a path there is not as much latitude as one might think. Schachter said, “It’s a combination of sudden freedom to run things as you please and crushing responsibility in which you know you have to do certain things in a certain way at a certain time. That eradicates all of that freedom. You become a robot on rails…every step was sort of the inevitable, inexorable progress due to the previous steps in the path. It’s not like I had no choice, but everything I did was the only choice because it was the only thing that made sense at the time.”

I would differ on this point from our perspective. During periods you’ll operate “on rails” but there are absolutely “switch ties” where a crossroads decision presents itself and the right decision isn’t apparent. For us these moments usually involve an afternoon of talking through the pro’s and con’s, doing a SWOT analysis on the different scenarios, examining the implications from every possible perspective internal and external to the company against the backdrop of our vision for where we’d like things to go. The dots make perfect sense in hindsight but not necessarily at the time looking forward.

Yahoo acquired del.icio.us in December of 2005 for an undisclosed sum rumored to be about $30MM. It continues to be the most popular social bookmarking service in existence today.

This entry was posted by Sean Tierney on Wednesday, May 16th, 2007 at 2:06 pm and is filed under Blog. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.