The Product Hack

Have you ever experienced the “thrill” of releasing an exciting new version of your product only to have customers complain about a feature that is now broken?

“But, how could this happen?, you ask. “Doesn’t development have a regression test to ensure these things are caught?”, you scream to the unfortunate and convenient program manager scapegoat.

Then you find out the issue: there was never a feature specifically coded to support how your customers started to use your product. It could be anything for which a work-around (argh! I hate that phrase…) might be created. Uh-oh. What to do now?

First, apologize. Yeah, it may technically not be your fault or that of the company’s, but taking the high road when you break a customer’s process is pretty much what you have to do.

Second, quickly identify where the application behavior changed so you have a grasp of the scope.

Third, canvass your customer based to identify any other potential use that could be impacted by the software change.

Then issue a notice to the entire customer base, describing the change and some of the use cases that could be affected. Sit back. Let the emails and calls pour-in.

Not too many emails or calls? Count yourself lucky. The customer, if not a major account may just need some additional assistance to find an alternative path. Or they could engage with a professional services group to create what they need. Or they could just deal with it.

But if you find that there are many affected customers, then you have come across one of the most interesting events that a product manager can encounter: the unintended product feature.

What do you do? You have perhaps hundreds of customers that have been using your product to perform an action or support a process for which it was not originally designed. But thing about it a little bit more. Isn’t this actually an exciting and perhaps serendipitous discovery of a new use or extension for your product? If many of your customers are using your product in a new and (more importantly) common  way, couldn’t there be more potential customers out there? Have you discovered an unmet need that your product solves in a good way? With a little more attention, could this be a key feature to unlocking a complimentary market?

So you need to handle this situation with both a short-term and longer-term plan. First, what you need to do is figure out a way to get these customers back to the functionality they need. That might be rolling-them back to the previous version with a simple utility. Or you might issue a directed patch that restores the functionality but without backing-out the other useful enhancements or defect fixes.

Longer-term, you need to do some real customer needs research and market analysis. This is an opportunity that is begging for some action. Who knows, it might be the genesis of an entirely new product line, or at a minimum, a way to further differentiate your product from the rest.

Good luck!