Recently I was searching for literature about product management. To my surprise, I found a lot about “new” product management, but until now only one article about managing “existing” products (any hints welcome). That can’t cover all differences between managing new products and legacy products. But then, why? I good product management practice, I started making some lists:
Existing Customers
Legacy software has legacy customers. I don’t see that as a bad thing, it is great to have customers and something many new products fail to ever have. It makes many things easier (next to having some incoming cashflow).
- You can get quick feedback on what is currently working and what is not working.
- Your sales team might be able to expand within existing accounts.
- You get some (biased) ideas where you might be going, either through feature requests or during roadmap discussions.
On the other hand, there are some caveats:
- There is inertia in continuing to serve the same general use case, both from the customers and from your sales team.
- Support requests, bugs and feature requests block some of your and your engineering team’s queues (see below).
- In case you want to discontinue a feature, you need to transition existing users.
Existing Functionality
With legacy software, there is a lot of existing functionality. And that functionality must be managed:
- There are bugs, including security bugs.
- Customers want more features. Even to the level of “This button needs to have a different color.”
- Due to a changing environment, features need to be adapted to stay relevant. The introduction of the Euro or the mandatory usage of International Bank Account Numbers (IBAN) are examples.
While you might decide not to implement feature requests, it is much more difficult to do so with the other two. So that will eat up some of your resources. And it needs to be prioritized against new development efforts.
Legacy Technology
When you have existing functionality, there is technology that you used to build it. And every technology has its life cycle. When the functionality was built, it was probably new and cool. But at some point, every technology starts to get old, superseded by something better and finally, development and support will stop. Latest at that stage, you software needs to be migrated to new technology.
This happens on all levels:
- Programming languages (e.g. c++, Java, Python, JavaScript)
- Programming frameworks (e.g. Qt, Enterprise JavaBeans, Django, AngularJS)
- Databases and search engines (e.g. MongoDB, MariaDB, Elasticsearch)
- Protocols (e.g. SOAP, REST, Java RMI)
- Architecture styles (e.g. SOA, Microservices)
- Platforms (e.g. operating system, browser)
Different Licensing and Pricing Models
If your are managing commercial software, there will be some kind of licensing in place. Your software might have started out with a per installation per module licensing. At some point, you started switching to a per user subscription licensing, all modules inclusive. Or you started with a per CPU licensing, then virtualization arrived. The possibilities are endless.
If the licensing model changes, what to do with existing customer? If you keep them on the old model, you need to maintain the old licensing also in the code. If you switch them to the new model, you must either give out things for free or engage in a sales discussion.
Similar, with new functionality. What to do if existing customers are on old licensing models? Do you license the new functionality with the old model? With the new model? Are the models even compatible? Do you give it out for free?
Existing Product Management 