Question: How do I manage two separate products on the same platform?
I am responsible for two products that use the same underlying code, but I have to plan out the new features. Should I try to get a few upgrades to each product or release upgrades for each product separately?
The scenario you described is similar to how companies split product development into two discrete functions: platform and application. The platform is the base technology that does all of the heavy lifting and provides the core functions of the software. One or more applications can sit on top of the platform and utilize its capabilities, but are tailored to the specific needs of a particular user.
From your question, it’s not clear if you really have a platform/application setup or if you just have two applications that share some of the code base, but are sufficiently different to be considered separate products. For the sake of this discussion, I’ll go with the latter, since the platform/application model of development is pretty common in enterprise software. Here are a few places to learn more about it:
For distinct products that share some or most of the same code base, you should treat each product as discrete and create separate product roadmaps for them. This will provide the appropriate focus and attention that each one deserves. If you keep them on the same roadmap, there will be a tendency to combine or merge them which, if that is not your plan, could hamper the success of one or both of the products. Keeping them together also increases the risk that you will make compromises between the two versions which will dilute the benefit of having distinct products.
By keeping them separate, you can plan for features that address the needs of the specific users of that version. New features and defects can be evaluated on their merits as they relate to the individual product, rather than as a component of the shared software. Tradeoffs will still need to be made, but your focus should be on solving the problems of the users rather than compromising between products.
As for release schedules, a lot depends on your Engineering and QA teams and your release process. One option is to alternate releases so that every X weeks or months you have one release that is focused on a specific product. This allows you to put in new features on a regular basis and puts some defect fixes in that benefit both products. You can fix more defects this way, but the cycles to get them into releases is longer. Another option is to make changes to the common code in one release and then have separate releases for new features to each of the product-specific code bases. This is similar to the platform/application model, and gives you the opportunity to have more frequent releases.
Don’t kid yourself, though. This is not easy and will require some sophisticated tracking by you and the development team to keep things from getting messy. Depending on the size of your organization and product sophistication, it may make sense to move to the platform/application paradigm. That model provides a clear delineation between the underlying shared code base and the application-specific code base.
Additionally, you should also evaluate whether you really want to keep the products separate in the future. It may turn out that keeping the products separate causes more problems than combining them. Using a licensing mechanism, you can have a single version of the software act like two separate products by controlling what features and functions are available in each version of the product. This adds complexity to the software, but makes it much easier to maintain and provides a greater level of flexibility in creating variations of the software for different users/verticals/markets.