Friday, February 06, 2004

User Pain Lifecycle and an approach to solving the problem

Basically why does a company buy a product even after building it in-house? I can think of some technical reasons (I am sure there a lot of non-technical reasons) -
  1. Vendor has more subject matter expertise – A simple idea that if vendor has designed and developed a product, then vendor would have designed solution in an environment independent and framework model which can be used to address most of the use case out of box and at the same time can be extended to cover all the use cases.
  2. Vendor will have more SME – As the time progresses, the vendor integrates products in more diversified environment and would have had to enhance the system for different use cases and so the when company will run into those use cases vendor would be able to provide solutions.
  3. Vendor have dedicated resources and can spend more time, money and effort to make sure that the product works.
But given my limited experiences with new products, it seems that most of the time none of this is true.

Pain Life Cycle

Typically most of the companies have “pain” to start with and then some one comes up with an idea to solve the problem. So a small system is built to solve the pain which slowly starts getting accepted and enhanced. As the time progresses the small product grows to become a large product which fulfills most of the internal users need.

Depending on how good the architecture and coding team was the IT departments ends with a fine product or a blob of code that works but no body understand.

While this thing was going on, somebody (The Vendor) noticed that this requirement exists in a lot of places (the start of the hype) and so tries to· start building a product to address client needs (please note this may not apply to a few companies that are started by people from academic background). Marketing/Sales wants to get the the first few versions of the product to the market as soon as possible resulting in a faulty architecture, sloppy code and limited testing. This product has very basic functionality, is defective and is architecturally weak.

·At this point the media and analysts have started to pick on the hype and added words like “paradigm shift” and “next generation” to these requirement. At the same time company is in deep pain from managing the in-house developed blob of code.

The Company buys the product after some evaluations and pilots with no idea how the requirements are going to change over time.·

So the company ends up with a product that does not provide all the functionality that in-house product provided, does not integrate well in the environment of the company, is defective/unstable/bad performance and non-extensible.

Why do companies do that?

I don't know.

Another approach

But what if the company took a different approach -

  1. Consortium of Vertical Industry users - So form a consortium of IT professionals who will come up with a set of use cases which are common to all the people. So instead of the vendors developing fuzzy use cases and even fuzzier standards around them, each vertical segment should have the requirements laid out. The consortium may have its own lab or donated labs where the products can be verified to be requirement compliant.
  2. Selectively "Open-design" their internal product - Basically this is based on the idea that the products developed internally are superior to the first few versions of vendor products. So in order to cut down the time and provide vendors with roadmap, the customers can open-design(could not think of any other word) the high level design and development information which can be made either public or provided only to legitimate members. This will help vendors and other open-source developments to get a handle on "what client wants".
  3. Share the experiences with the consortium - This is another important idea that must be used to ensure that the knowledge is not wasted and people can learn from the mistakes of other.4. Vendors Interface - Force vendors to implement the common features required by most of the members of consortium and make them follow a framework architecture.

Most of these thoughts are not something new and I guess people have not seen the benefits of sharing out weight the benefit of keeping their internal information secret. But till we don’t have a legal memory erasing device or a single giant enterprise, people will continue to change jobs and take these "internals secret" to the competitors. So why not do this sharing in a formal way especially when it is going to help achieve companies to·improve their core·functionality·and not·be obsessed with·IT.

No comments: