The Innovator's Creed

A project I’ve taken on this summer at eBay is the identification and assessment of innovation activities going on around the company, with the end goal being delivery of recommendations on how to grow the practice of innovation there.  A big part of that has been my conversations with those who have taken ideas from outside of their assigned work, successfully built them out, and brought them to market.

What is fascinating about their explanations of success is that all the cases include a set of principles that were learned along the way.  This set is consistent across the lot of them at eBay, and indeed is consistent with what I found at Intuit when I innovated there, leading me to the conclusion that this set is likely universal, at least across mid-to-large-size tech firms.  In creed form, this is what I found contributes to the success of an innovation project in a tech firm:

1. I will not ask permission, I will just do it.
2. I will have my own release cycles, independent of the rest of the company.
3. I will have a completely separate code base from other products in the company.
4. I will have dedicated resources.  (This can mean 100% on the project or some regular time blocked off, like every Friday or every weekend, which is fully respected.)
5. I will have rapid product iterations, with customer feedback at each iteration.
6. Upon completion of a prototype, I will gain the sponsorship of an executive.
7. When it comes time to integrate with other products, I will leverage the executive sponsor to cut through red tape.

Another angle I’m starting to explore is what role innovation events play.  eBay calls them Skunkworks, Intuit calls them Idea Jams, and LinkedIn calls them Hackdays, but the premise is always the same.  Those who have successfully innovated almost universally deride these events as mere working sessions, not the innovation jump-starters they claim to be.  My theory is that the true value in these events lies in the relationships built, the knowledge gained, and the positive energy captured by the participants.  Thus executives should spend less time trying to convince everyone that x% of the company’s products have come from innovation events than highlighting the number of participants that learned a new API or programming language, or the number of participants that got to experience a new role. (e.g. Product managers acting as marketers, designers acting as developers, and so on.)