Sponsored Ads

Syndication

AddThis Social Bookmark Button

« The Tipping Point debate | Main | Virtually There »

Failure to Launch

There's probably nothing more depressing than being confronted with the fact that your new product or service is going to fail.  If you've put a lot of effort, time and sweat into a new product, you have an emotional and psychological attachment to its success.  That makes it all the more bewildering when the reasons behind the failure are directly caused by a failure to plan and manage a project.

A client I worked with recently complained that his project did not receive the results he expected.  Toward the end of the project it became evident that a lot of issues had not been considered or adequately addressed.  Many threads were left hanging, as if other people were going to step in at just the right time to take on training his customers or developing a support mechanism for a new solution.  What's surprising and somewhat frustrating is that these issues were raised earlier in the project, but there was never enough time to plan, to consider what other capabilities and needs surrounded the development of the project.  What my client lost sight of was the fact that in almost every case, the product or service that you build is just a small part of the total solution that a customer expects. 

Given the complexities that we live with and the expectations we have of our products and services, it is not enough to simply create a great new product.  Along with that product, you need to create what Geoffrey Moore calls the "whole product" - that is, the manuals, support, training, registration, help and surrounding infrastructure that can make or break a product or service.  The old thinking is that people don't want drills, they want holes.  The new thinking is that people want to understand how to drill the hole effectively, and want someone to call in case they need help with their hole.

Understanding this from the start of any project is important.  Too often we cleave off all the "extraneous" stuff in a project plan that does not have to do directly and immediately with the product we're building.  It's easy to push off the documents, help guides, training, support, channel development and a host of other activities to place all emphasis on the product.  But, at the end of the day, without all of that other stuff that seemed so much less important, a product has little chance for success.

Think about it - two seemingly similar products hit the market, at roughly the same time and same cost.  One has information about how to use it most effectively, powerful user guides, websites full of information, support lines, documentation and trained partners.  The other is just a product - a fine, high quality product, but missing all of that "unnecessary" stuff.  Which one do you want to buy?

Too many products and services fail not because there's no need, but because the project planners and managers either fail to account for these critical elements or strip them out of the plan.  Any project manager worth his salt should be asking the question - Who uses this?  What information do they need?  How do we train and support them?  Simply building a great, high quality product is not enough.

In any business, the training budgets are one of the first things to get cut.  In any project, customer training, documentation and support are the first things to go.  As a project manager, do you have the backbone to demand that these critical elements are in the plan?  Do you have the ability to convince others that they should stay in the plan when things get tight?

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/t/trackback/176631/25697386

Listed below are links to weblogs that reference Failure to Launch:

Comments

Post a comment

If you have a TypeKey or TypePad account, please Sign In