Posts Tagged ‘innovation’

March 13 2009

The rate limiter on innovation

by Hang

I’m a huge tetris geek and so when I discovered Torus, my first reaction was “That’s so obvious, why the hell didn’t I think of that?” which lead me to thinking about how almost every person has their own personal theory about how they think innovation happens and yet they are so rarely inclined to put that theory under empirical scrutiny.

Some people believe that innovation is technology limited and that as soon as a new product becomes practical, someone will build it. Often, the critical technological factor might not be the most obvious one. Looking at torus, their reaction would be that sure, it would have been technically feasible 20 years ago but such a variant never would have spread without the viral power of the internet. Because there’s so many entrepreneurs working on so many different approaches to the problem, one of them is bound to hit on a good idea eventually.

Other people believe that innovation is a matter of luck, talent and persistance. MP3 players as good as the iPod and search engines as good as Google were perfectly possible well before they came out but it took the genius of the designers at Apple/Google to finally show people what an MP3 player/search engine could be.

There are still others who believe innovation is a social process driven by fads and fashions. People innovated in social networking because social networking was what’s hot. Now, they’re innovating in iPhone apps. Driving innovation is largely a matter of pushing trends.

In truth, all of these explainations are more or less valid in different areas and every sophisticated person holds a complex mix of all these views but I think it’s interesting and useful to articulate your own view so that you can determine whether it’s correct or not.

February 27 2009

The natural unit of innovation

by Hang

**WARNING: INCOMPLETE FOR NOW, feedback still welcome*

This fascinating visualization of the writing process was at the top of Hacker News and unfortunately, it’s easier for you to view it than for me to try and describe it for you. But looking at in made me consider how long it took for that idea to fully develop. Stripping out the whole online component of it, when could you have realistically developed something like that? 1960? 1970? There was a good 40 years between when it became technically feasible and when even 0.1% of the computing population had even been made aware of it.

One thing I started noticing quite a while back was this consistent pattern of a brief period of innovation when a new technology hits followed by a stultifying grind in which ideas barely change. And I think the reason for this is not because all the good ideas were already developed, I was seeing absolutely brilliant ideas coming out of academia every year that were markedly superior to what we had before. I think the right explaination is that the natural unit of innovation is the idea and the natural unit of competition is the product and so when those two get too far out of sync, innovation grinds to a halt.

I can guarantee you the guys at etherpad were not the first to have this idea. At a conservative estimate, I would say that that particular demo had been tried by maybe a thousand people in the past, everyone from grad students to bored hackers to geeky artists. But consider the process from the genesis of an idea to it being a feature that people could use. If you were in the 90’s, everyone would have been writing in Microsoft Word. In order to convince anyone to try out your feature, you essentially had to build something better than Microsoft Word just in order to test this new feature. This is, to say the least, mildly impossible.

The difference between the effort required to create a feature and get it into use was so impossibly large that such an obvious feature languished for 40 years for lack of an opportunity in the market. I think the ratio of effort required for a feature:effort required for a product is an extremely important metric to optimize because even small reductions can have highly non-linear and cumulative effects. In this case, as a rough cut, I’m defining effort required for a product as the amount of work it would take to have your software be installed and used by 1,000,000 people or 10% of the market, whichever is smaller. That includes the coding, marketing, sales etc.

So what are some ways of drastically cutting down on the feature:product ratio?

  • Hiring innovative people: The easiest way to get a feature deployed is to work for the company building the product. Hiring the right people and getting out of their way can push the feature:product ratio essentially down to 1 for that group of people.
  • Open sourcing:
  • Plugin architectures: Plugins allow you to leverage off all the other features that aren’t the feature you want to implement. If you want to prototype a cool comment system, you don’t have build an entire blog, you just download wordpress and start hacking away at a plugin.
  • Good API Design:
  • Great documentation: Sadly, something ignored by most open source projects
  • Scripting languages: Building your product out of a dynamic scripting language allows others to easily dive into the guts of what you’re doing.
  • Orthogonal design: A good plugin architecture is useless if you can’t actually add useful features because everything is so interdependant on everything else.
  • Automated Deployment: Remember, the feature:product ratio doesn’t just involve coding, all the other activities that go around getting an app installed matter too. Huge complicated deployment strategies might make sense for a product but can become disproportionate for a feature. This means you need to provide one click installs, auto updates, an in-product plugin store and a vibrant viral community to help with the marketing.
  • Lots of eyeballs: The larger and more active your community is, the more ideas bubble and ferment to the top and result in concrete results.

If your product can provide all of these things, they can pull a long way ahead of the competition. Look at the example of firefox vs IE, firefox has steadily gained market share because, among other things, you can install an ad blocker. Nobody on the firefox team ever built an ad blocker and it would probably have been deemed low priority if it were ever proposed to them. The sole reason an ad blocker exists today is because the person who thought about writing an ad blocker didn’t also have to contemplate writing a HTML parsing engine.

Copyright ©2009 BumblebeeLabs — Theme designed by Michael Amini