When developing solutions for clients, legacy always had me worried. Having an existing system in-house, opened a host of unknowns for solutions we developed, or the estimates we prepared. There was always that one thing we couldn’t account for or wouldn’t be able to account for. 

The Legacy

Source: Wikipedia

Legacy, also, determined the expectations that people using them had. There would also be a basis for comparison, and these were often an influencing factor in determing the path to implementation. In fact, we had several prospects and clients factoring in how do we get our teams to use the new software in discussions. And, often, we would counter with extensive training and support.


We are not makers of history. We are made by history.
Martin Luther King, Jr.

With products, not many product managers have the ‘luxury‘ of working with a new product or product line. And I stress on luxury, because it is very much that. With new products, it’s a blank slate that has the benefit of being clean, free and devoid of previous expectations. It is the proverbial block of stone, ready to be sculpted by the product manager and his/her development team(s).

Existing products, often are bound by being ‘out there’. It’s in constant use. And this use, creates constraints thats related to operational considerations, users and data. More importantly, with existing products, decisions made previously are all inherited. Ignoring it, is not really a choice. To move ahead with new features, enhancements or implementations requires full cognizance of what has been already implemented – and, why it has been implemented the way it has.


Understanding the context of the product, helped me figure out what was done and what should have been done. The gap, which was quite sizeable at the time, helped me map out deviations from the roadmap. A thorough assessment of these deviations, provided us with insights into where we needed to rework our product, or provision for extra effort and time. It also helped mitigate several risks such as scalability, flexibility and otherwise badly implemented features.

The time and effort required to correct these deviations, were debated at length. Where a strong case emerged, it was taken up immediately, and where the case was relatively weaker, we held it off for a later date. Effective prioritisation helped us take up new features, while rectifying existing ones.

Sometimes, taking a few steps back, often makes the way ahead, easier.