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.

What's your blood commit?

There is a great article in the always informative Infectious Greed blog by Paul Kedrosky. The article talks about putting together a board package, but it provides great insights into the challenges of forecasting/planning at software startups. What metrics are appropriate to track? How can you create the right incentives for the field sales reps? How do you get visibility into the sales pipeline - what is real vs. what is wishful thinking. The underlying issue, apart from accurate forecasting, is about ironing out revenue lumpiness. Lumpy revenue is valued significantly less than smooth revenue and any planned exit needs a plan to decrease lumpiness.

The question of metrics is an interesting one and one that needs careful thought through in a start-up environment. I''ll save that issue for a future post, though, and just focus on the sales process. Here are some rules of thumb that I've seen work well at start-ups.

• Hire sales reps familiar with how your product is bought, not how it works. What I mean by that is the specific domain knowledge of the sales rep is much less important that their familiarity with the selling process that your company requires. For example, lets say that you're selling a specific type of data security product, one that is useful for CFO's and the financial department. You have two possible sales reps in the hiring queue: one has sold a financial app to CFO's in his past job, and one has sold security software to the CIO in her past role. Who should you hire? You're much better off hiring the person who is familiar with your buyer - the guy who sold the financial app, not the woman who sold security software. Domain knowledge can be learned pretty easily during the course of a sales-kick-off meeting or two, but understanding the modus operandi of your buyer, their concerns, their quirks and sensibilities - that's invaluable and it can't be taught.
  

• Fear is not a substitute for metrics. Often, sales leadership will compensate for a lack of metrics by ratcheting up the pressure on sales reps. The title of this post, "What's your blood commit?" is an actual question I've heard asked. I love the term: its very evocative of the near-desperation at the exec level when management doesn't have a good handle on forecast. While the intent is good (to understand what sort of discount factor to apply to over-optimistic forecasts), the approach is almost always counter-productive. Sales reps will respond to pressure by telling you what you want to hear. Use whatever management tool works for you, but it cannot be a substitute for hard numbers.
  

• Be the ant, not the grasshopper. The old fable, about the importance of hard work and preparation, is very relevant in sales territory development. A common scenario with a new sales rep is that they come on board and start working their Rolodex. It may work for a couple of quarters, but once its done, like the ant, they find they have no pipeline to work with. Reps should be plugged into the marketing, lead generation and follow up process as soon as possible. This is the only sustainable way for them to develop their pipeline. This means that sales reps should allocate some time for cold-calling every week, develop local relationships such as those with industry trade groups and participate in trade shows and other events. These activities need to be built into their compensation plans.

What are some other sales lessons you've learned from your own start-up experiences?

Enterprise Software: Feeding Frenzy Continues

Yesterday Symantec (NASDAQ: SYMC) bought Altiris (NASDAQ:ATRS) for $830 million. Today shares in BusinessObjects (NASDAQ:BOBJ) rose on rumors of a takeover bid by Oracle (NASDAQ:ORCL). Looks like 2007 is off to a roaring start as consolidation in the enterprise software market continues after a record 2006.

Enterprise software in flux

The world of enterprise software is fundamentally changing. This is not the enterprise software market of old with its bloatware, n-year implementations, painful upgrade cycles, fragile interfaces and ROI analyses that can charitably be described as "aspirational". Just look at two news releases today:

• First, SAP announces a hosted solution for the middle market. This in the face of a negative market reaction to their mid-market foray due to increased customer acquisition costs and lower margins.

• Then, hot on the heels of IBM's announcement yesterday, Oracle announced WebCenter Suite - its own Web 2.0 offering. A great example of "me-too" press, although Oracle had actually first talked about this product a few months ago and failed to capitalize on it.
  

I don't recall a time when there was this much uncertainty in the enterprise software market. The large vendors are scrambling to accommodate entirely new areas of functionality (collaboration, participation) that are antithetical to today's centralized way of providing IT-enabled value. At the same time, the delivery models have shifted to subscription-based, hosted services. The big players are struggling to keep up while not abandoning their current , highly profitable, product franchises.

All this means there's a huge opportunity to innovate in enterprise software. And the place to start is in fast-growing but still-developing countries with a need for IT, but under served by the large global players. The need is acute, the new delivery models match well with the lower capital expense outlays common in these countries, and there is no legacy to overcome. Just like the old order is slowly turning over in consumer software, there is no reason to believe that today's dominant providers of business solutions will be dominant tomorrow.

Big Blue Gets Hip

IBM just announced its entrance into the world of Web 2.0 with the release of Lotus Connections , announced yesterday at Lotusphere. They're calling this category social software for business and it includes collaboration tools such as user profiles and connections, blogging, shared bookmarks, online communities, shared workspaces, search and tagging.

Clearest indications that Big Blue is getting hip to the ways of Web 2.0:

• IBM has a virtual marketing booth for Lotusphere in Second Life (launching today).
• They're following the "-kr or -zr endings are cool" philosophy by naming a content repository product Lotus Quickr.

It's getting a lot of press coverage, including ZDNet and BusinessWeek. The always interesting John Paczkowski of Good Morning Silicon Valley blogs about it here.

This is being billed as an IBM vs Microsoft battle, but the IBM offering seems at first glance a much stronger contender to bring collaboration to the enterprise than Microsoft's SharePoint 2007. Watch this space!

Chicken or Egg?

The Economic Times of India has a debate about whether or not India is ready to produce great software product companies. The arguments are interesting on both sides, though not particularly new. On the pro side, the writer brings up the development of an eco-system of VC's, the social acceptance of entrepreneurship and the emergence of a domestic market. The con argument talks about the lack of skills and product knowledge.

The basic issue is one that is not mentioned in the article but is an implicit assumption on both sides. This is the issue of demand. Supply issues such as social acceptance, available funding etc, are not the bottleneck - demand is. If India grows a large domestic IT market, Indian product companies will thrive. If not, they won't. Necessity, as they say, is the mother of invention: a demand-side argument if there ever was one!

The underlying cause of disagreement in the article is really about how large the Indian market will be. The pro side says big, the con side says, not quite yet. That's the real question that needs to be analyzed and debated.

I've been surprised to see very little emphasis in the media and the blogosphere on this question. Mobile phone adoption rates are well-known, and there is some information available on internet usage in India, although sometimes the numbers should be taken with a grain of salt. Enterprise demand in India is not even discussed at all. Time to change the debate from supply to demand!

Enterprise Mashups

Great post by Dion Hinchcliffe on enterprise mashups. Unlike consumer mashups, there is no monetization issue. The tools are getting simple enough to allow non-IT staff to build their own. More grist for the mill for The End of IT....

The end of IT?

I was struck by two articles I read recently. The first was this little nugget from the more comprehensive survey conducted annually by the good people at CIO Magazine:

The average CIO makes $23,562 less in real dollars today than five years ago.

The average salary for CIO's at large companies is still almost $300,000, so I'm not shedding any tears. Still, these numbers are certainly on a trajectory that suggests that the IT department is becoming less, not more, important, to the businesses they serve. Notice that I said "the IT department" not IT itself. The importance of IT is not in question here, its how it is delivered and accessed that is the issue. Which brings me to the second article. This article, subtitled "Consumer technologies are invading corporate computing" (subscription required) appeared in the last issue of the Economist magazine. It talks about business users taking more control of their productivity tools, from IM and VoIP to Email and Calendaring. If the IT department is not on board, they are simply bypassed by their users. The article mentions Adrian Sennier, CIO at Arizona State University, who recently moved the entire university to a productivity bundle from Google called Google Apps for your Domain. The article goes on to say:

For Mr Sannier, however, a bigger reason than money for switching from traditional software to web-based alternatives has to do with the pace and trajectory of technological change. Using the new Google service, for instance, students can share calendars, which they could not easily do before. Soon Google will integrate its online word processor and spreadsheet software into the service, so that students and teachers can share coursework. Eventually, Google may add blogs and wikis—it has bought firms with these technologies. Mr Sannier says it is “absolutely inconceivable” that he and his staff could roll out improvements at this speed in the traditional way—by buying software and installing it on the university's own computers.

Is this the end of IT as we know it? Software as a service, empowered users, tools to allow encoding of business rules and workflows by non-technical users - what will this mean for the IT department of tomorrow? Or, for that matter, to the legions of IT consultants (whether onsite or offshore) who assist them?

The Indian Enterprise: Hot or not?

Conventional wisdom has it that the domestic enterprise software market should be shunned like the plague. After all, the argument goes, Indian enterprises don't place strategic value on IT, don't want to spend money on IT, are comfortable using pirated software and are too hide-bound to restructure their processes to make them more efficient. Besides, in a place where the relative costs of labor and capital often favor labor, why invest in automation and process efficiency?

The numbers seem to bear the cynics out: India, despite all the hype, is still a tiny market. According to IDC, the entire IT market in India in 2005 was $12.5 billion, with the bulk of that amount ($7.5 billion) going to hardware. Services accounted for $3.5 billion and packaged software just $1.5 billion. The software market is predicted to grow at a annual rate of about 20% over the next 5 years. At that growth rate, the entire software market will be less than $4 billion in 2010.

Hmm.. pretty gloomy stuff. So is there an opportunity? If I were to start an enterprise software company specifically for the Indian market, would I be mad, a decade ahead of my time, or both?