November 24, 2010 Leave a comment
It’s inspirational, to hear project managers telling the team to try harder and do better……That the software is not yet good enough….….”It should be like this”…”It should be like that” . It works to undermine excuses for poor or shabby work. And, most importantly, it helps team members develop the courage to stand up for these values in stressful situations. Under pressure, the temptation to cut corners, or to hand off shoddy work to another department(QA or Support) is overwhelming. It requires courage to stand up and say: “this work is simply not good enough. Sure, we could get away with it, but that’s not how we work.” Good PM’s work hard to create an environment where this courage thrives.
On the other hand, there are many stories of companies achieving a breakthrough by shipping something that was only “good enough.” One such ‘gist’(guess it was Weiss-Malik that mentioned it….not very sure) , tells of the launch of Google Maps. The team was demoing their AJAX-powered map solution, the first of its kind, to senior management at Google. They were impressed, even though the team considered it still an early prototype. Larry and Sergey, so the ‘gist’ goes, simply said: “it is already good enough. Ship it.” The team complied, despite their reservations and fear. And the rest is history: Google Maps was a huge success (though some of my colleagues think Nokia maps rule ). This success was aided by the fact that it did just one thing extremely well – its lack of extra features emphasized its differentiation. Shipping sooner highlighted this difference, and it took competitors a long time to catch up.
So when exactly is it good enough to ship?? When the product is ‘very finished’ or work in progress?
Most of us (in software development) intuitively have a “split the difference” attitude when faced with recurring difficult choices. Everyone naturally falls along an array of entity, from “ship anything soonest” to “always build it right, no matter what it takes.”
I want to explore the idea of releasing “crap”: that our product is of such low quality that we will release it, customers will hate it, and we’ll have accomplished nothing but alienating them. But notice how many forecasts are cooked into this supposedly simple scenario…..we believe we have already solved the distribution problem for our product (or else how could customers try it?). We already know who to distribute the product to (or else why would we care what they think?). Naturally, we already know the standard of quality that they(users) will use to judge our product. And, of course, we already know that they will care enough to be offended and they will most likely tell their friends how unhappy they are…..(and we know that’s bad for business when it happens) In fact, we know so much that we already know what they will care enough about (namely, the product’s quality – as opposed to, missing features).
It is entirely possible that we can ship “crap” and have one of the aforementioned facts fail to materialize. In fact, that is one of the best possible outcomes, because it will force us to learn something. What if customers actually like the “crap” product? Or what if we can’t get any of them to even try it? Or what if the features they demand we build are different from the ones we were planning to build? In those cases, we can’t help but learn a great deal. Remember, the minimum in minimum viable product does not mean that you should ship just anything at the nearest possible date. It means to ship as soon as it is possible to learn what you need to learn…..depending on what you want to learn.
So what about the question of whether ‘ready as in ready’ or work in progress? What’s needed, I think and like david hansson(37 signals) said, just build something awesome, something you yourself would love to use and ship it while staying focused .Talking about being focused, following the idea with rigor while continuously improving, there is no such thing as good enough. Our pursuit of learning is ongoing and our commitment is absolute. But when it comes to the specific of a product release, business plan, or marketing launch, all that matters is: do we have a strong forecast that will enable us to learn? If so, execute, iterate, and learn. We don’t need the best possible forecast. We don’t need the best possible plan. We need to get through the build-measure-learn feedback loop (sometimes it enters an endless loop…at least facebook is a good testimony) with maximum speed.
Moral of the story, good enough won’t happen as fast as we expect (in my opinion)….get excited, build(……try to stay off the crappy path though), deploy ,patch, iterate on and on….you feel differently? Please, leave a comment or send a message and let’s discuss.
Follow me on twitter for short bursts 140 xters or less.