Roadmaps and Feature Relationships

Our approach to developing agile product roadmaps emphasizes the evolution of products. Sometimes, this is best captured through a time-centric format, such as the format I first described in my book Beyond Software Architecture and described by Scott Gilbert and Jeff Brantley in their recent webinar. At other times, this is best captured through the organic growth and shaping metaphors of the Innovation Game(R) Prune the Product Tree. In both cases, the evolution of products is based on a holistic, balanced approach that emphasizes the relationships that exist among features within a product, products within a product portfolio, or projects within a project portfolio. We've found that making these relationships as explicit as possible helps produce clearer, more actionable roadmaps.

In this post, I'd like to share how we help our clients build better roadmaps by describing the various kinds of relationships that might between the items in a roadmap, in the hopes that you may find these ideas helpful as you create your own.

These relationships are:

• Depends On
• Replaced By
• Enhanced By
• Alternative To
• Groups

---

Depends On

One feature depends on another feature when the first feature must exist in the product before the second feature can exist. We find that this relationship is needed to capture the feedback from the engineering team, who love to remind us that they simply must integrate into the SMS service before they can send an SMS message, even though the product manager only cares about sending SMS messages. Representing dependencies in a strategic roadmap, especially for platform products that have modules, or product line architectures, in which many products are created from a set of shared components, is essential in making certain that your roadmap isn't missing critically important features. Keep in mind that dependency is indeed a strong relationship: removing the "root" item in the dependency relationship means that you're going to be removing all of its dependents.

---

Replaced By

One feature is replaced by another feature when you intend to remove one feature and replace it with another. This happened recently in our own Buy a Feature online Innovation Game(R). We had implemented a way to play the game that our initial usability testing indicated would work. However, actual game play revealed a number of flaws in our original design. Heading back to the drawing board, and armed with a lot of helpful user feedback, we redesigned our the user interface for game play. The old game board was replaced by the new game board.

The replaced by relationship is often required to manage the ripple effects of changes in your technology stack. Suppose, for example, that you're the product manager for an embedded systems project (everything from complex consumer electronics to the myriad of chips that manage the functions of the modern automobile). If your favorite chip supplier discontinues production of an important chip, you're going to have to replace it with another.

We encourage clients to think of replaced by in relatively stict terms: Replacing a feature means that the previous feature is going to be pruned from your product tree. Depending on the nature and scope of the feature, you may be able to get away with just putting the change into your release notes. Chances are good, though, that if you're replacing a "big" feature you'll need some kind of formal End-Of-Life (EOL) process to let customers know that their old item is truly gone forever. Otherwise you've accidentally created an "alternative to" (below) and added to your ongoing support and maintenance costs.

---

Enhanced By

One feature is enhanced by another when the first feature works better when the second feature is present. Enhancement relationships often existing in platforms or products that allow plug-ins. Firefox and Photoshop are two examples of consumer class software applications that have a myriad of enhancement options that enable these products to perform better. Enterprise class software platforms that allow for 3rd party plugins or optional modules also exhibit many enhanced by relationships.

Managing enhanced by features within your own product offerings can be tricky. Sometimes, customers will wonder why you don't simply roll the enhancement into the base products, improving the same, and converting an enhanced by relationship in your roadmap into a replaced by relationship. Managing 3rd party relationships cans also become problematic, especially if those third parties have a terrific idea. Consider salesforce, Oracle, and Microsoft. Salesforce claims that they won't acquire companies who enhance their platform. Oracle makes no such claim, and over the past few years has made many purchases of companies that enhance their platform. And yet... salesforce has also acquired companies that enhance their platform. Microsoft, of course, is well known for simply developing and then integrating 3rd party enhancement into their core offerings.

Please note that I'm not making a judgment call on the strategies of these companies. All are valid strategies, and the respective successes of these companies demonstrates that it's working for them. My goal is to illustrate that choosing how to manage enhanced by relationships is not trivial, so choose thoughtfully and with an eye towards longer term strategy.

---

Alternative To

One feature is an alternative to another feature when both features solve the same problem for customers in different ways and you choose to offer both options to customers. Think "power windows" and "hand crank windows". Both do the job of raising and lowering your car window. The former costs more than the latter.

Choosing to support alternative features within your roadmap is fairly common when you have a common platform that supports a multitude of market segments and you want to enable flexible customizations within these market segments. This must be balanced against the configuration, quality assurance, product delivery, and maintenance complexity associated with product deliverables.

---

Groups

One feature groups a set of other features when each feature within the group can solve a problem for a customer, but the group of features is required to solve a problem for another customer. A favorite example is a company who offers software that meets regulatory requirements in a given jurisdiction. Consider permitting software for managing shipments of complex or hazardous materials. If you're transporting the goods within a single geographic jurisdiction, such as a single city or single state, you need the "feature" that manages the permitting process for that jurisdiction. If, however, you're driving across jurisdictions, you will require software that manages the permits across the jurisdictions.

We like to maintain a distinction between groups and bundles. A group of features is required to solve a problem. A bundle, however, is often a collection of features and/or offerings that is created for marketing purposes, such as a bundle of casual games that you can purchase for a BlackBerry.

We've found that roadmaps are enhanced when relationships between features are clearly identified. What's your experience? What additional feature relationships have you found useful?