Software products get inertia. A team works on one version of the product–pours their heart and souls into it, if the team is dedicated and passionate–and eventually ships.
So what comes next?
This is a silly question, right? If you just built version 5.0, then 6.0 is next. Or maybe 5.1. Unless marketing decides to call it Contraption 2013 instead.
I’d like to suggest that it is healthy to wonder if you should build a new incarnation of your current product at all. Sometimes, if you’re smart, you’ll realize that the answer is no.
It is not crazy that the default posture of dev teams is to release a new-and-improved version as a follow-on–staffing teams, organizing marketing, communicating effectively to the market, getting sales traction, and aligning your support and professional services teams on a common axis are all expensive and time-consuming.
However, the right solution to the world’s problem tomorrow might not be a slight variation on something you’ve already built. Companies that forget this are going to keep improving their tape decks even as CD players begin to ship. (If that reference seems archaic to you, you’ve proved my point yet again. CD players became a lot less compelling once personal mp3 players were a possibility…)
Clayton Christensen is famous for writing about this in The Innovator’s Dilemma, but I like his Blockbuster/Netflix example in How Will You Measure Your Life even better.
I’ve seen good examples of thinking outside the box during my career. The decision at PowerQuest to invest in disk-based backup instead of building another version of PartitionMagic comes to mind. But I’ve also seen the opposite–blind commitment to version 5.0 and 6.0 to such a degree that teams could not innovate.
Seth Godin writes insightfully about this in Poke the Box:
[Most organizations] are based on this assembly line model of scalability. The system is the system. Don’t mess with it. … Now, think about Apple, Google, director James Cameron’s team, Ideo, Pixar, and Electronic Arts. These are project-centric organizations. … No projects, no organization. Coasting isn’t an option because projects don’t last forever. The people stick around, the posture persists, but the projects need to be refreshed.
It feels to me like one way to encourage innovation in a software-creating org is to not assume that there will be a next version. There may be–but once this version ships, we spend at least a little time with first principles, re-validating assumptions about what can best delight customers.
Analyze where your current product fits on Clayton Christensen’s model of innovation vs. mature product. Does this suggest anything to you about a need for radical (as opposed to incremental) innovation?