As a 
software product manager, you are more than likely called to make the decision whether a product/service is ready for prime time. Often it is a challenge because there is a lot of pressure from internal stakeholders to release it.
There is a fine line between what I call a “lame duck” product/feature and phased release of a product or a feature. Lame duck is a product/feature that is dead on arrival. When customers try to use it, they either cannot figure it out (usability issues), find it to be so slow (performance issue) or basically find it useless (functionality issue). Phased release on the other hand is where a very large piece of functionality is broken down into logical units and delivered in a series of releases. The latter approach makes a lot of sense because each of these logical or atomic units are still usable by the customer to get their job done. The additive nature of the logical units also usually makes sense to the customer because it lets them start using the new functionality in a gradual fashion and eventually end up automating/changing their entire process over a series of releases.
Unfortunately, “lame duck” product releases are very common. I have heard the excuse of “If we build it they will come” or the reasoning of “Let us release it and customers will shape it for us.” – all of this will hold true ONLY if you have build something that is complete and useful for the target customers. Customers usually have a low tolerance for products especially when they have choices and will only put with something when they absolutely don’t have any. The latter is very rare if you ask anyone other than software vendors. This is even more true with new products especially websites targeted towards consumers. Customers will not give you the second chance if they visit your website, don’t see what they wanted and leave. First impression matters. It does not matter how much effort you put in the second round to make things better and complete, it is a lot harder to convince your prospects/customers to come back and try it for the second time.
I am not preaching “perfection” here by any means – I am a strong believer in “perfect is the enemy of the good”. But I continue to be appalled when companies release products into the marketplace as “lame ducks” and wonder why they are not successful. One of the common places where you can find such products is when a company takes an enterprise product, turns off a few features and releases it as a small business version. This assumes that small businesses don’t have the same needs as the enterprises – not always true.
To clarify further what I define as “lame ducks” vs. “phased releases”, let us consider some examples purely for illustrative purposes.
Lame ducks
1) Photo community website launches with a bunch of photos, but there is no ability for community members to contribute photos. Result, community cannot contribute content and the content becomes stale very fast.
2) Tables functionality inside word processor – can create tables, but cannot add/delete rows or columns after the table is created – have to delete and start over.
Phased releases
1) Photo community website launches with awesome functionality to view, share and upload photos. The experience is outstanding, the community spreads the word and the site takes off. The creators extend the site to support videos within 3 months of launch.
2) Tables functionality inside word processor – all of the basic functionality is included. However, you cannot create rich text inside tables (different fonts, font size, font treatment like bold, underline, italic etc.) is not supported in Release 1. Rich text functionality is released in release 2.
As a software product manager, the best way to avoid having to make a decision to ship or not to ship is to prepare for this during the product planning session than waiting till the tail end. Plan for this, because it is bound to happen. During product planning, make it crystal clear as to what you think is the minimum set of functionality that is needed to release the product into the market. Once agreed upon, all stake holders should be aware that this minimum functionality is not up for negotiation no matter what issues are uncovered during the product development process. The solution could change based on how the product development proceeds, but the functionality set cannot. You should plan on building support for this approach with your executive stakeholders upfront so that you do not have to face the death squad when you vote “No” to prevent the product from shipping.
Have you experienced such a situation? How have you made the right decision? Please share your thoughts.
If you enjoyed this post, please leave a comment or subscribe to the feed to receive future articles delivered to your feed reader.
Image: Courtesy of hwupdate.org
Software Product Manager by Gopal Shenoy 
I’m in favor of phased releases. In our case R1.0 would be the “minimum viable product” inspired from The Lean Startup.
Really enjoyed this one, Gopal, thanks!
It is definitely tricky to adopt the “fail fast” philosophy of agile without creating “certain to fail” releases (lame ducks).
Scott @sehlhorst
Interesting topic… a couple thoughts to share with fellow Product Managers:
Product Management is not an easy task in any industry. But in the software industry it is even harder due to the accelerating rate of obsolescence as generations of language, platform, OS and hardware continue to roll over at an increasing rate. Couple that with the massive growth in the number of software firms, and global demand and it’s very difficult to balance between being on the cutting edge,behind the curve or having a great solution that does not yet have a market.
We chased after a competitor who developed an icon based payment reporting solution, and kept investing at the insistence of the sales reps and PM. Years later that same competitor had sold their firm, started a next generation solution and was our new partner. Once we had gotten to know each other he confided that he was amazed we followed them into that market as they never covered their investment either, much less made a return ON that investment.
Product Management always struck me as a balance between the science and fact based, with a lot of gut feel and intuition (the art). By definition, its attempting to predict what will happen by looking at historical data.
Great post, Gopal. One of the biggest dangers is not realizing a release is a lame duck until after the release… The ability to recognize it before launch (and then delay) will be a huge step in the right direction for PM’s!
Great post! Thanks for calling a spade a spade on lame duck releases. This has happened to me in 2 companies. In each case the CEO met with a customer (minus the product team). The customer demanded feature X, or we would face losing the account. So the CEO promised feature X in the next release (uh oh!) When the product team went to investigate, the feature that the customer came up with didn’t solve the problem at all. In one case we found a whole different way to solve the problem and everyone was happy in the end. In the other case, there was a DOA usability issue for which there is no workaround. So we canned the release. It wasn’t pretty, but it really helped clean up the product development process – the CEO never tried to bypass the product planning phase again.