Ask A Good Product Manager

Your product management questions answered

How can products sharing the same platform best be managed?

Posted on October 5, 2008 · 5 Comments

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?

Answer from Ivan Chalif of The Productologist: Unless the two products are tied together (they interoperate or one requires the other), it’s best to focus on them as separate entities.

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.

5 other answers so far ↓

  • Justin Dillard // Oct 5, 2008 at 11:24 am

    Thanks for the reply.

  • How to Manage Two Separate Products Built on the Same Code | The Productologist: Exploring the Depths of Product Management // Oct 6, 2008 at 7:02 am

    […] Here’s another cross-post from Jeff Lash’s Ask a Good Product Manager. This one asks the question: How do I manage two separate products on the same platform. […]

  • Raj // Oct 7, 2008 at 1:55 pm

    I agree with Ivan’s thoughts. Especially – “Unless the two products are tied together (they interoperate or one requires the other), it’s best to focus on them as separate entities.”

    I used to work for a company which had two different products targeting two different markets – but had evolved from the same code base.

    The CTO for that company wanted to keep the code base the same so that “common features” only had to be done once, instead of twice.

    It sounded great in theory, but in practice it made it nearly impossible to plan product releases, prioritize features, prioritize bugs, and so forth. Eventually the releases ended up requiring difficult & painful compromises between the two teams.

    Based on that experience, I’d highly recommend separating products that are really separate and are targeted at different markets.

    Hope this helps.

    – Raj
    Accompa – Affordable Requirements Management Software for Product Managers

  • Justin Dillard // Oct 7, 2008 at 7:01 pm

    The Two Products are related, but both can work on their own. They can be combined to be a “suite” if you will. One product is lacking compared to another. Just due to time in development. One product has been around for 4 years or so and the other about 1. I understand that the 4 year old product is more stable but, we have a larger customer base that is more demanding. Just having trouble doing the balancing act.

  • David Locke // Nov 30, 2008 at 4:00 pm

    At one point, we had several products that ran in a console. We treated that console functionality as a part of the product itself. This meant that the code and functionality of the console component diverged. And, development costs for the consoles were incurred by each team.

    At some point we split out the console and removed that functionality from the products. Each product ran in the standard console. The console was maintained by one team and only that team.

    That console was considered to be a platform. There was an inhouse technology platform under the console. And, there was a Windows platform amoung other third-party platform running under the console as well.

    The products were nicely issolated from the platform changes. Layers, adopters, and sublimation got the job done. Modularization simplified the code as well as the interfaces amoung the roadmaps.