enthiosys agile product management - agile product management, motivated from within

New Product, Upgrade Existing Product, or End-of-Life? Yes. Maybe.

 

One common misconception about roadmaps is that they’re all about the future. This perception is fortified by the use of roadmapping formats, including one of the formats that we prefer here at Enthiosys, that are indeed focused on the future. However, what product teams often discover when they’re building their roadmaps is that the act of considering the future forces teams to deal with the present, which, when roadmapping, quickly becomes the past. This, in turn, raises questions about your in-production/legacy offerings, which means product managers must make some tough choices about releasing a “new” product and keeping the old one around, upgrading existing products, and/or end-of-lifing existing products. Sometimes, of course, you do all three. In the process, you’ll find that your future oriented roadmap will likely need to be augmented with radar roadmaps and ripple guides.

New or Upgrade?

A good roadmap will help product teams understand their target markets, the unsolved problems within these markets, the times when customers want solutions, and an overview of how the technical team will architect the solution. The roadmapping process, which highlights the key new releases that address these issues, inevitably draws product managers into considering if the new release should be a new offering or an upgrade to an existing offering. Some factors that influence this choice include, but are not limited to:

• The rights that existing licensing agreements give customers relative to upgrades
• Whether or not the new offering contributes more profit as part of the core product or as a stand-alone offering
• Customer reactions to a new product vs an existing product
• The ability to attack new market segments with a new offering vs. the ability extract more revenue from existing customers with an enhanced offering
• A host of other considerations that are too complex to explore thoroughly in this post (although I do devote several chapters to this in my book Beyond Software Architecture)

Whichever choice you make, you need to be clear. But that doesn’t mean you’re free to make any choice that you want. We recently worked with a client who had substantially rewritten their core product offering. Should they use the “old name” with a new release number or a “new name” that reflected the new architecture? The product manager was drawn to offering a “new name”, until product marketing demonstrated that the costs of establishing a new branded offering was going to be quite prohibitive. We helped take some of the sting out of this choice by pointing out that their license agreement permitted charging an upgrade fee for major new releases. Since this release qualified, our erstwhile product manager took solace in a higher profit margin.

End-of-Life (EOL)

Software companies tend be pretty bad at EOL. I’m not entirely sure why, but I think it has something to do with an overly technical perspective of product management. Bits don’t wear out and that the Agile practice of continual refactoring our systems means that we can keep them on life support for a very long time—right?

Sure, but that’s missing the point. Bits may not wear out, and refactoring can indeed keep systems supple, but markets change, business models change, and customer needs change. I fondly remember many great software programs that I no longer use because larger changes obsoleted these programs.

Unfortunately, product managers often hang on to software offerings or, more often, versions of software far too long. They chant “I can’t EOL ver 2.2; customers A, B, and D are using it” without realizing that they sound downright lazy for not doing their homework and calculating just what supporting 6+ different versions is costing their organization. Toughen your roadmaps up and make sure that you clearly communicate which versions are going to be EOLed and how this process works. If you need a good example of how to manage EOL, check out http://www.juniper.net/support/eol/ or http://www.cisco.com/en/US/products/products_end-of-life_policy.html.

Radar Roadmaps

Once you’ve made your choices about which releases are coming the in future and which versions of your product you intend to EOL, you can put all of this into a radar roadmap. Just like the name implies, a radar roadmap shows what’s leaving you, what is near you, and what is coming. Done well, you can have a single radar roadmap show which products and versions of products are going to be EOL’d, which are going to be supported and for how long, and which are coming—and for how long you intend to support these new releases.

We’ve found that creating a radar roadmap works best after you’ve created a good future oriented product roadmap. It isn’t necessarily easy, but your extended team will thank you for investing the time in creating this picture. You’ll probably find that creating a radar roadmap will also help you identify new ways to make money through upgrade/EOL services and/or product upgrades.

Ripple Guides

I refer to a “ripple upgrade” as an upgrade that forces you to upgrade otherwise stable system components. Examples of ripple upgrades can involve either hardware or software or both. On the hardware side, it is common for a new version of an application to require more memory, a faster processor, more disk space—or all of the above! Examples of software ripples occur when you want to upgrade to a new version of an application that requires a new version of an operating system.

Think you’re immune? Think again. Your solution almost certainly relies on other components or technology in-licenses. Changes to these will cause changes to your solution, no matter what you want.

Since you can’t prevent ripple upgrades, you can make them as painless as possible, especially as it relates to software components. Do this by creating clear upgrade guides and testing the upgrade paths, using your Radar Roadmap as a guide to how you’ll manage the process.

Are all of these needed?

Maybe. Maybe not. If you’re working in a startup, with a single product in a single market, a basic roadmap is just fine. If you have a small portfolio, you may be able to get away with a few basic roadmaps and perhaps an integrated roadmap. Once you move into more complex portfolios of offerings, yeah, you need this. So stop complaining and start roadmapping.

Return to insights-tools