Prototyping for communication and innovation

2 minute read

Really great article from the creator of Gmail on how important it is to be experimenting constantly with live code to drive innovation and how much more strongly is speaks than a fat PPT deck.

Two great gems here, the first on time for unapproved ideas:

The other point is that it’s important to make prototyping new ideas, especially bad ideas, as fast and easy as possible… This is also where Google’s “20% time” comes in – if you want innovation, it’s critical that people are able to work on ideas that are unapproved and generally thought to be stupid. The real value of “20%” is not the time, but rather the “license” it gives to work on things that “aren’t important”.

And about the importance of mechanisms to crowdsource your innovation :

One of the best ways to enable prototyping and innovation on an established product is though an API.. Twitter is possibly the best example of how well this can work. There are thousands of different Twitter clients, with new ones being written every day, and I believe a majority of Twitter messages are entered though one of these third-party clients.

Public APIs enable everyone to experiment with new ideas and create new ways of using your product. This is incredibly powerful because no matter how brilliant you and your coworkers are, there are always going to be smarter people outside of your company.

I’ve often wondered (with others) how google manages to constantly improve their gmail and calendaring clients while still keeping their user base happy. Just today, I was floored by how nice their out of office feature is on the Gmail web client (I normally use over imaps), since it adds a small visible status bar to remind you it’s on (as well as hyperlink access to the settings to turn it off). Great UX.

Interestingly enough, one of the reasons I’m a big fan of Rails and tools like git for source control management and capistrano for deploys is that it makes it stupidly easy to try new things and branch features cheaply while maintaining the original code base to roll back to, making mistakes and bad ideas very low cost.

dev gtd