Software Product Manager by Gopal Shenoy

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