“By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback.”
—Kent Beck, Approaching a Minimum Viable Product
Many thanks to Dave Morehouse for forwarding the quote and link to me – it’s perfect. I happened to read it again while also reviewing a paper written by a friend that highlighted some of the challenges of introducing software and software-related services at a large, successful manufacturing company. My past experience has always suggested that shipping is not only important, but it is THE most important thing. There are lots of things to worry about – does it have the right features, is the quality level there, etc – but despite all of these worries, when you have reached that crisis of confidence, this is when you have to double down and ship. I’m fond of saying that in the end game there are lots of reasons to NOT ship – that’s why shipping is the hardest thing to do. If you don’t have a maniacal focus on getting your product born, you risk the serious possibility of it never seeing the light of day.
Coon Rapids Dam - Coon Rapids, MN
This mentality is where the motto of “Shipito Ergo Sum” comes from – “I ship, therefore I am”. Very early on I discovered the rule of thumb that “organizations can’t stand to wait more than 4-6 months to see a product release come to life“, and if you take longer than that, then some crisis will divert the attention or resources of the company away from your goal and you will be left without a mandate. I saw this happen once – saw six months of effort by a half dozen people flushed down the drain (and some of the people with them) – very sad.
By the way, the corollary to this is “Life is too short to build things that no one will buy“. There was a point where I was willing to build just for the sheer joy of learning, but those days are long gone.
Enough about that – what was the message from my friend’s paper? Because of the past success of this organization in other areas, they were particularly conservative about protecting their brand image and shoring up any potential legal liabilities, and as a result they had even more reasons to NOT ship than the typical software organization. It’s hard to imagine how to bring balance between these concerns and the need to throw “Minimum Viable Products” at the wall to see if they stick. In my opinion, this could even be the fatal flaw that prevents organizations from venturing into software and related services unless their current success came from the software realm – large companies with much to lose have a hard time putting it at risk to compete aggressively enough to win at new markets.
Here’s a link to the full article if you are interested in learning more: http://www.threeriversinstitute.org/blog/?p=333
