I have always heard from many people that our product works when implemented. But when I ask to demonstrate one feature or another I get this common restraint saying - this patch has to be applied, this is a development area. There is an feeling that a product has to be implemented -for months perhaps - for it to work.Many a times I have not been able to do an end to end check of a functionality often at times when the check is critical for a solution.
The result of such an exercise is obviously speculation. The product may work today and may not tomorrow. Something like tracking our SENSEX. There may be a method but who knows what it is.
This leads to a question, does the product really work or is it that it is implemented to get it working. In a product business the onus I have been told is on non-linear grown, if every implementation involves development of a product where does non-linear growth come. Instead it is double dose of expenses one in the name of product development and another as implementation - not considering the others.
Implementation is to set up those parameters that are specific and often exclusive to a bank or a few of them that cannot be in the out of the box product. Perhaps some customization that we have not been able to bring to the products or that we cant for technical framework or due to product economics.
What is the solution for it? A possible direction is to ensure that what has been promised is available as it is in hand-over environment to internal customers. If there is a belief that the problem is a "set up" issue then the solution is to build standard set-ups that can be demonstrated. An interesting approach already implemented at many places is to have a "model implementation" with standard "set ups or end products" that can be sold as a standard industry practice. We have modelled for the market and we need to validate that what we developed is required for the market.
But where does the effort start at bringing organization into the product business. Does it have to be the product management group that has to drive it. How does one build in the technical, functional and consulting capabilities into it. Particularly when the product is existing and involves re-working processes from day one when the product was initially conceptualized. Or does one do it only for new modules and changes. How does one link the new modules that require old processes.
These are some of the issues that one needs to consider when one builds a new product. With this should be the ability to create an infrastructure that sustains changes in the organization, people, trends and technology. But for a mature product that wants to streamline and become more profitable, the answer lies in tough decisions and meticulous planning at creating change.
Till that time budget n-times of rework at each of the departments through which your product flows - design, engineering, implementation, support and else where....and speak to the world about non-linear growth ....and hide this blog spot.
The result of such an exercise is obviously speculation. The product may work today and may not tomorrow. Something like tracking our SENSEX. There may be a method but who knows what it is.
This leads to a question, does the product really work or is it that it is implemented to get it working. In a product business the onus I have been told is on non-linear grown, if every implementation involves development of a product where does non-linear growth come. Instead it is double dose of expenses one in the name of product development and another as implementation - not considering the others.
Implementation is to set up those parameters that are specific and often exclusive to a bank or a few of them that cannot be in the out of the box product. Perhaps some customization that we have not been able to bring to the products or that we cant for technical framework or due to product economics.
What is the solution for it? A possible direction is to ensure that what has been promised is available as it is in hand-over environment to internal customers. If there is a belief that the problem is a "set up" issue then the solution is to build standard set-ups that can be demonstrated. An interesting approach already implemented at many places is to have a "model implementation" with standard "set ups or end products" that can be sold as a standard industry practice. We have modelled for the market and we need to validate that what we developed is required for the market.
But where does the effort start at bringing organization into the product business. Does it have to be the product management group that has to drive it. How does one build in the technical, functional and consulting capabilities into it. Particularly when the product is existing and involves re-working processes from day one when the product was initially conceptualized. Or does one do it only for new modules and changes. How does one link the new modules that require old processes.
These are some of the issues that one needs to consider when one builds a new product. With this should be the ability to create an infrastructure that sustains changes in the organization, people, trends and technology. But for a mature product that wants to streamline and become more profitable, the answer lies in tough decisions and meticulous planning at creating change.
Till that time budget n-times of rework at each of the departments through which your product flows - design, engineering, implementation, support and else where....and speak to the world about non-linear growth ....and hide this blog spot.
1 comment:
Srinivas,
I think what you say is very pertinent. I guess, most product co's first look at getting a product to work to suit individual aspirations without making sure it works well as an intergated part of the big equation (of all that the customer had identified as pain points in the first place) that determines the need and then facilitates the development of the product (the typical adage of 'end justifies the means'!)
There are multiple reasons for this shotgun approach that leads to some of the conditions you mentioned aptly.
Product 'Time to market' conditions being strictly limited to get it out to the market - to stay in business, lack of maturity of personnel handling this product development and of course, the cliched one - the product management team being incapable of conceptualizing the product needs on a holistic 'customer first' perspective - keeping the product functions working to stay competitive to earn incremental revenue as opposed to giving customers what they actually want ona bigger picture that may far outweigh their marginal 'penny wise and pound foolish' approach.
On a side note, since this is your first blogpost and my first entry on this, the product mindset in India will have to change - India is realizing the value of IP and people will begin to understand products better and put what it takes to take a product 'glocal'.
Cheers,
Naveen
Post a Comment