The Deployment Post Mortem

Your product just released. Customers are buying your product in droves and they love it. It saves them time and money, makes them better at their work, and it even slices bread!

That's wonderful and these moments are what we Product Managers live for. However, things don't always go according to plan. What happens when things don't go so well? Inevitably, a customer deployment will go poorly. They won't be happy with your product, and may even uninstall it. What can you do in a situation like this? One approach is what I will call the Leo Tolstoy approach. The great writer said: "All happy families resemble one another, each unhappy family is unhappy in its own way." In other words, treat the failure as an outlier, an anomaly, rely on your customer support to patch things up as best they can, and move on.

A better approach is to look at the failure as an early-warning mechanism. This is your opportunity to understand whether the failure is indeed an anomaly (as some will inevitably turn out to be) or whether it points to a systemic problem that you need to take steps to address. As Product Managers, we are attuned to issues in the field and actively search for patterns or trends that point to a broader problem. Depending on the type of problem, PM's should have a checklist handy to make sure they get the information they need. The two most common types of issues I have come across are:

Failure in the field. The software caused an outage in the customer's IT environment. A PM checklist should include:

• What was the problem exactly? Get a detailed explanation.
• Was it due to an unexpected software/hardware configuration?
• Was the configuration explicitly not supported? If so, why was it installed? Where did our internal process fail?
• Was the configuration explicitly supported? If so, go back to problem determination. What must be done to include this use-case in future QA plans?
  
• Was the configuration neither explicitly supported nor unsupported? If so, is this a configuration we did not expect to see and did not plan for? Is it an unusual combination that we're unlikely to see again? If it is likely we will see it again we should add to QA plans. In the case that this is a fairly common configuration that was not part of the QA plan, we need to go back and revisit the entire QA process. How closely does the QA test matrix map to what is encountered in the field? Do we need to do more research to ensure adequate QA coverage?
  
• In the problem determination phase, as we uncover the root cause, can we generalize the effects? I.e. Could the same problem manifest itself in other ways? How to we prevent those other problems as well?
• Once we understand the root cause, can we generalize a "graceful degradation" principle from it? Can we build in checks so that when faced with an analogous unknown situation, the software is able to adhust or "degrade" its functionality rather than cause an outage?
  

Mismatched expectations. The product works as specified, but it doesn't do what the customer thought it would do. They don't see value in the product. A PM checklist should include:

• Did we oversell or overpromise product functionality? If we did, this could point to at least two different problems:
  
• If we oversold, was it because the sales force was not trained adequately to know exactly what the product does and does not do? We will then need to work out a more comprehensive training plan for the sales team.
• If we oversold, was it because the sales team felt cornered into "improvising" in the field? This could be an early signal that the product is not meeting the needs of the target market very well, and the sales team feels pressured into setting unrealistic expectations.
  
• Figuring out whether it is a training issue or a product mismatch issue is extremely important - one can be fixed relatively easily, the other may require major realignment.
• Did we demonstrate value? Even if the product is implemented and works flawlessly, did the customer realize the benefits and/or return on investment they were looking for?
  
• If the customer did realize benefits, but is not aware of them or unable to articulate them, then we need to showcase these benefits better and make it easy for the customer to see it. Perhaps this needs additional reports, a dashboard, or some set of running statistics that enables customers to quantify the value they have received.
• If they did not realize their expected benefits, why not? If the software was meant to replace some manual activity, is the manual activity still being carried out? Is there duplication of effort because some component was not correctly or adequately integrated?

Product Bytes Newsletter

I've been a fan of Rich Mironov's newsletter, Product Bytes, for a couple of years now and wanted to provide a link to it for anyone who may be interested. It's a refreshingly BS-free take on the art and science of Product Management, and I always learn something new in every issue. It's a bit skewed towards enterprise software, reflecting Rich's long experience in that area, but I think the basic ideas apply quite broadly.

Long Bets

The Ladies Home Journal from December 1900 contained an article listing predictions for the year 2000. The author writes:

These prophecies will seem strange, almost impossible. Yet, they have come from the most learned and conservative minds in America. To the wisest and most careful men in our greatest institutions of science and learning I have gone, asking each in his turn to forecast for me what, in his opinion, will have been wrought in his own field of investigation before the dawn of 2001 - a century from now. These opinions I have carefully transcribed.

Some of the more remarkable themes:

• Telecommunications: "Man will See Around the World. Persons and things of all kinds will be brought within focus of cameras connected electrically with screens at opposite ends of circuits, thousands of miles at a span."
  

• Spy satellites: "Balloons and flying machines will carry telescopes of one-hundred-mile vision with camera attachments, photographing an enemy within that radius. These photographs as distinct and large as if taken from across the street, will be lowered to the commanding officer in charge of troops below."

• Genetically modified food: "peas as large as beets" and "strawberries as large as apples."

There were some exercises in wishful thinking, such as the view that we would all be athletic and fit in a hundred years:

Gymnastics will begin in the nursery, where toys and games will be designed to strengthen the muscles. Exercise will be compulsory in the schools. Every school, college and community will have a complete gymnasium. All cities will have public gymnasiums. A man or woman unable to walk ten miles at a stretch will be regarded as a weakling."

We'll try to get there in 2100. And my favorite, the somewhat mystifying prediction:

There will be No C, X or Q in our every-day alphabet. They will be abandoned because unnecessary.

The full article is available here.

Fight Poverty with Connectivity

The notion that large-scale handouts of aid hasn't worked to alleviate poverty is well documented. In the worst case, it enriches corrupt, autocratic kleptocracies (e.g. as it did with Mobutu in Zaire). More commonly it's simply wasted because the institutions necessary to use it are not effective, and a sort of low-grade ineffeciency and corruption takes hold. Even the biggest provider of such development aid, the World Bank, has now recognized that aid must be linked to governance to be successful (championed by Paul Wolfowitz, whose current woes do not invalidate this notion).

The basic underlying lesson, according to Iqbal Qadir, founder of GrameenPhone, is that poverty can be reduced only by empowering individuals, not governments. His own involvement in setting up a cell phone company in rural Bangladesh is testament to the individual-centered, connectivity-based model of economic development. Qadir is currently a director at the MIT Center for Developmental Entrepreneurship, which has already brought to market several innovative products for developing economies.

See below for a talk that Mr. Qadir gave at the TED conference in 2005, explaining his ideas about ending poverty through connectivity. (If you don't see the embedded video, click here).

Living La Vida Local

Things are different here. The first thing I noticed were the number of "IIT " bumper stickers. Around here there are more IIT bumper stickers than for all other colleges put together! The pool in our building is full of Indian kids splashing about while their parents call out to them protectively in Hindi, Gujarati or Tamil. And the once-familiar sight of clothes hanging out to dry on window ledges and balconies, is once again common.

We can walk to not one, but two, different Indian grocery stores. Steaming hot platefuls of idli and dosa are available in abundance - and cheaply! My wife and I love Keralan food, so we were delighted when we found a great little place with fantastic pepper-fried chicken. Even though we don't have kids, our friends in the neighborhood tell us about the cultural center they take their kids to on the weekends - to learn Indian classical music and dance. For us less cultural pursuits, like watching Guru, suffice. Or, if we feel like staying in, we can go pick up an Indian movie at the local video store.

No, I'm not back in Bangalore - we live in Sunnyvale, CA! Although it wasn't planned this way, it's turned out to be a great transitional place for us when we moved from San Francisco last year, and get ready to move to Bangalore next month. Sunnyvale and Fremont in the East Bay are the two centers of Indian life in the Bay Area. Everyone planning to relocate from here to India, whether Indian or not, should come and spend a couple of months here to make the transition smoother!