F*ck it, ship it

I'm a perfectionist.  I'd much rather have something perfected (and perfected, and perfected) until I feel satisfied, but that's not how product managers should work.  This quote from Dave Winer says it best: "Software is a process, it's never finished, it's always evolving. That's its nature. We know our software sucks. But it's shipping! Next time we'll do better, but even then it will be shitty. The only software that's perfect is one you're dreaming about. Real software crashes, loses data, is hard to learn and hard to use. But it's a process. We'll make it less shitty. Just watch!" 

As much as I'd like to sit here and say 'yep, I released everything I've ever worked on and it was perfect'... that's not the case.  Product managers spend some of their time prioritizing every issue and bug that we see so figure out the customer impact and level of effort required to fix the issue.  So my advice is this - ship your product before it's perfect.  Not only will it give you extremely valuable insight into how your customers are using your products, and how frequently they're using them, but it will tell you what they're using most.  That bug that comes up when a user clicks through to a specific page?  Maybe they don't even get far enough into the product to realize it.  (We can connect this to the post I completed on usability testing.)  

(This is a great blog post on 'f*ck it, ship it'.)

Stop obsessing - it's not going to 'prefekt'.  It's software, and we all make mistakes.  F*ck it, ship it- and watch what happens!

3 comments:

  1. Welcome to product management.

    I am in hardware, and I assure it it is no different. In general, Engineers are never ready to stick a fork in it and call it done. It falls to us in product management to determine "good enough" and to define upfront what "finished" means.

    It is also why Scrum always revisits "definition of done" in each iteration. It gives visibility to the need to complete the project and that there is an end.

    Everything we ship has warts, and missing features. Our value is to balance the warts and missing functionality against what the market needs. And sometimes, just to say "f*ck it" and slap that baby's behind.

    ReplyDelete
  2. It's a balance, isn't it?

    The opposite danger to trying to get it perfect is to release before it's good enough - "good enough" being the key phrase, and what they pay us PMs to be able to ascertain.

    I think of this as the 80% rule - the features have to be 80% there or more. Any 65% features will just cause you pain - a feature that works, just not in the common use case; or that works, but you can't get the data into or out of; or that supports the common use case, but crashes regularly.

    I've certainly shipped releases on-time that I paid for in terms of lost reputation because of them being "not good enough," and I have also shipped releases late that no one remembers were late, just that they were successful with customers.

    ReplyDelete
  3. Thanks for the comments guys!
    While I hate to think that "good enough" is where we need to be (I'm a perfectionist), it is certainly the job of a product manager to weigh their options. Nils - I love your example of the 80% rule - I'll have to try that out!

    ReplyDelete