Sunday, April 13, 2008

Anew or not?

Is it better sometimes to kill the product you have and start anew rather than continuing to patch the existing one? But how and when you make that decision is something that I haven't perfected as yet. Over the past couple years, I've had to make this decision several times due to one reason or the other and each decision has been more informed and better than the previous one, but the timing has still been off. In all instances, I've either waited too long to pull the plug or in some cases not at all. I'm wondering if there is a better way to come to that decision and if I could borrow from another area where I've made better decisions using ambiguous information.

The analogy is letting go of a difficult employee - there is a period where you identify a problem, try to course correct and live through difficult times and if things don't turn around, you let go of the employee. Most people when asked if their decision was correct will say that they wished they had done this earlier.

So, what makes the people decision better vs. the product decision?
a) Is it the level of ambiguity (do you know more about a person's performance vs. a product's appeal or lack thereof),
b) Is it a case of differences in the level of cognitive dissonance (killing a product you built has worse implications compared to making a bad hiring decision)
c) Is it the level of commitment that's different? After all building a new product while supporting the old is not for the faint-hearted.

Maybe it's all three that cause one to be circumspect. While this is not an easy decision, the repercussions of not taking timely action can be just as troublesome.

On the other hand, is there a level or arrogance or naive optimism that one harbors in believing that the new product will cure all? In some cases, where one has inherited legacy software and there are too many moving parts and no resident expert, it might be better to re-haul, but even then doing so in parts is the best way to go.

No comments: