Who Needs Reliability When Your Consumers are Addicted?

Twitter logo Lately Twitter’s database crashed. They occasionally have to turn off features for technical reasons. Sometimes they’re down and they don’t even know why (having been a sys admin I feel their pain). It seems they’ve picked a service with a a hard technical problem: scaling a web messaging system. And it’s reached the point of parody.

Do Twitterers complain? Sure. But they keep using it. They even send the Twitter staff pizzas.

Considering we don’t actually need Twitter and could easily go back to life without it, the devotion of Twitterers is amazing. But I realize this is nothing new for Evan Williams, the founder. In the early days of Blogger there were also massive technical problems. As an early Blogger I remember them devoting weekends to keeping the service up as I sent in my donation to keep them going.

This approach feels like a key variation on the beta launch approach: if the app is addictive enough, consumers will hang on and tolerate downtime. So launching a good idea even earlier than the usual beta may pay off despite technical pain later on (e.g. Blogger survived nicely). For many product development and IT managers, launching betas is radical enough, launching unscalable betas will be a tough lesson to absorb.

p.s. check out their nifty over capacity page…


  1. What’s most interesting about the technology and platform to me is that it’s text+a small picture, and appears to create a flow state.

  2. Victor.. somehow missed this…….. your statement “Considering we don’t actually need Twitter and could easily go back to life without it, the devotion of Twitterers is amazing. ” could mean “I don’t need twitter but other people seem to feel it meets an unmet and unarticulated need” which means there is something seductive about it … so it will continue to gain momentum….
    Another way of looking at the risk of a new concept is also to look at the cost of another iteration of modelling/making it tangible to share with interested parties (possible lead users) and getting feedback for understanding the opportunity (prototype’s validity) rather than putting a value on it.. at some stage we can embark on testing for viability.
    So at an early stage we can explore for validity (= someone, a possible user, likes it)… then as costs begin to mount we can move towards testing for viability (we can produce it at a price that makes it of value for all parties). Managing risk in this way allows for simple techniques that are based on the opportunity and cost of offering that opportunity to the next stage.

Comments are closed.