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.

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).

Long Lived by Design

Picking up where my last post left off, the issue of data longevity is specially important to developing economies where the process of digitizing government records and making government services available online is just beginning. The lessons to be learned from data loss from the early adopters in more developed economies should be taken to heart.

There's no question that this is a well-understood problem and many projects are tackling different aspects of it. For example, open standards such as ODF reduce the risk of unreadable data. Digitization and hosting of content by service providers offloads the problem from individual consumers to service providers who are, presumably, better suited to deal with it. At the cutting edge, there's even talk of using bacteria for long-term data storage!

My point is not that adequate steps are not being taken. My point is that product design should incorporate principles with longevity in mind. What might these principles look like? A great place to start is by looking at the Clock of the Long Now, conceived by Danny Hillis (of Thinking Machines fame). As he explains the genesis of the project:

I want to build a clock that ticks once a year. The century hand advances once every one hundred years, and the cuckoo comes out on the millennium. I want the cuckoo to come out every millennium for the next 10,000 years. If I hurry I should finish the clock in time to see the cuckoo come out for the first time.

This seemingly quirky endeavor is actually a deeply insightful way to examine our notion of time and its impact on technological progress. Hillis lays out a list of design principles for his 10,000 year clock.

• Longevity: The clock should be accurate even after 10,000 years, and must not contain valuable parts (such as jewels, expensive metals, or special alloys) that might be looted.

• Maintainability: Future generations should be able to keep the clock working, if necessary, with nothing more advanced than Bronze Age tools and materials.

• Transparency: The clock should be understandable without stopping or disassembling it; no functionality should be opaque.

• Evolvability: It should be possible to improve the clock over time.

• Scalability: To ensure that the final, large, clock will work properly, smaller prototypes must be built and tested.

These principles seem to me to be broadly applicable. If your product, software or hardware, may be used for any duration longer than five years, you would do well to consider each of these issues (adapted for your specific situation) and how you plan to address them in your product.

Microsoft Office v. 2100?

Those of us who have an interest in technology and want to build widely adopted products will do well to consider the issue of longevity. Building products with a long-term view is a good practice in itself; but also thinking long-term yields design requirements that tend to be beneficial for the overall product.

As an example, consider the Domesday Book, a comprehensive survey of England, commissioned by William I of England, and completed in the year 1086. The book still survives and can be viewed in Britain's National Archives. Today, more than 900 years later, the book is readable, understandable, and provides valuable historical, social and economic insights to historians and scholars. Inspired by the Domesday Book, the BBC undertook to create a similar survey of England in 1986. The contents were stored as 12-inch video discs (remember those?) which are now obsolete. The digital version of the Domesday book lasted all of 20 years!

Think about how much of the information generated in the last 40 years or so is already lost to us. Data created in some proprietary format for which the program is no longer available, or stored in obsolete media which can no longer be read. Clearly we generate a lot more content that we did before, and perhaps not all of it needs to be preserved. However, since there is no way to distinguish what should be preserved from what should not (and who gets to decide this anyway?), they are treated identically. There are groups, such as the Digital Preservation Coalition, based in the UK (started as an attempt to save the 1986 version of the Domesday book as their top priority!) that are tackling the issue. But a lot more remains to be done.

Even more important than preservation efforts are design principles that allow for the creation of long-lived content. Products designed with longevity principles in mind are the only proactive and scalable way to solve the problem. Preservation will always be a reactive and expensive fall-back option and will never offer a complete solution to the problem.

SMS is the Platform

A good friend of mine, Rishi Bhargava, recently returned from a trip to India. He shares my interest in technology, innovation, and the emerging Indian market. We had a long chat after he returned and he had some very interesting observations, which I'm going to summarize here:

• SMS is the Platform. We already know about the importance of mobile devices to technology adoption in India, but my friend made an even more pointed observation: your product or service has to be accessible via SMS to have any chance of gaining a large user base. Even when people buy data-enabled smartphones, they often have no interest in mastering a new interface when SMS is familiar and easy-to-use. For example, jewelers are paying for SMS-based alerts for price changes in precious metals. These same people are not familiar with the internet and are unlikely to be early adopters of an internet-based marketplace for precious metals.
  

• Lack of Trust Hinders Adoption. The medium for social networking is the clearest indication of the generation gap. In India, for people in their 30's or older, social networks are largely physical. Business is done in this way and social relations are conducted in this way. It's a perfectly rational response to the lack of effective remediation and redress. If you got cheated out of some money, how would you get it back? The police are often inept and/or corrupt and the court system is notoriously slow moving. The only rational thing to do is to minimize your risk by dealing only with people in your social network. Today's teenagers are comfortable moving their social networks online, but this generally tends to reflect their physical networks. The same issue of trust, just in a different medium.

• Internet Connectivity is Cumbersome. Beyond a small number of tech-savvy users in large cities, the internet has largely not touched people's lives in a meaningful manner. Even when people sign up for email accounts, they don't check them on a regular basis (and certainly not at the frequency that has become the norm in the US). Setting up and managing a broadband connection can still be cumbersome. Customer service at providers like BSNL and VSNL are universally acknowledged to be terrible. Even providers such as Airtel are getting poor reviews in this department. This has resulted in a cottage industry of "computer service" technicians who often do nothing more than apply the latest Windows patch. Still, they are needed to provide peace of mind to the non tech-savvy. Pricing plans are still archaic in terms of pricing by bandwidth usage (as if people actually know their expected bandwidth usage!) This entire process has to become a lot more streamlined before we can expect wider adoption.
  

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!

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?

Yet another blog on innovation?

What is this blog about? Well you might ask: this blogosphere of ours is already thick with treatises on innovation. Virtual forests have been felled to explore this topic in every conceivable way and from every possible angle. Can anything, well, innovative, be said on innovation? Read on and decide for yourself.

Developing Innovation is dedicated to exploring software innovation in developing countries. I've been interested in technology adoption and software for a while. As an Indian, I've followed the technology outsourcing boom, and the creation of world class IT services companies such as Infosys and Satyam in the last decade. More recently, I've observed innovative software solutions developed in India for the local market. In many instances, the new technology is more advanced than that available in the US (e.g. in the areas of mobile and wireless). Yet, the vast majority of Indians remain unaware of technology and its potential to improve their lives. How to reconcile this "leapfrogging" adoption on one hand, and a complete lack of awareness on the other?

Is this an opportunity for software innovators to step into the breach? Or is India decades away from using technology in any broad-based manner? Are there similarities between India and other developing countries in the way technology can be built and used? Can those synergies be leveraged to go after ever-larger markets if your own market is too small for you to grow? The answer to all the questions, I believe, is a resounding YES. I think it is an opportunity: a very large opportunity. Here are a couple of reasons why (and I'll expand on these in future posts):

• High Growth: Emerging economies are undergoing higher rates of growth than they have in 50 years.
• Demographics: Developing countries are generally younger and more open to technological innovation.
• Greenfield Opportunity: Current software investment in most emerging economies is negligible.
• Local requirements: In many cases, the requirements for software products in the developing world are substantially different than those in the developed world. Not just product features, but also pricing and delivery models.