**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.