A Roadmap Provides Direction

Product roadmaps are a tool used to visually present an approach to translating a business strategy into the real world. The visualization of the impact of a strategy on a product allows all relevant constituencies to grasp how a product and its enablers are intended to evolve.  

In order to create and use product roadmaps, there are several key concepts and components that need to be agreed upon.  

The first concept that needs to be agreed upon is the definition of a product. Mike Cohn, of Mountain Goat Software, defines a product as “a product is something (physical or not) that is created through a process and that provides benefits to a market.” This definition gets rid of the distinction between tangible products and services to focus the idea value delivery.  The most critical part of the definition is that the product must provide a benefit to a market.  Much of internal IT’s work is either as part of the larger business-driven product or as an enabler. For example, learning management is a product delivered by human resources (HR) to the individuals within an organization. The system (e.g. PeopleSoft or Workday) and the network enable the product. The business strategy will define the future of the product which will in turn influence the enablers.  

Some organizations make a major distinction between services and products.  The distinction is often made because services are intangible (can’t generate an inventory) while a product is tangible.  Making a distinction between a product and service may well impact how a strategy is delivered but is less useful when defining a  product roadmap or when determining whether a product owner should exist.  From a roadmap perspective, treating product and services the same is the simplest and best approach.

Many organizations create software-centric (or at least involved products) others use software to enable the delivery of value.  Software-centric software functions will be identified on the product roadmap. For example, an ATM product roadmap might include purely software driven multi-lingual or voice activation functions. When the organization’s products are less software-centric the roadmap requires some form of linkage between the product and the technology which may be on two separate roadmaps.  The potential for two very different paths is most obvious when leveraging commercial packages (COTS) or software as a service (SaaS).   In both cases, the software is serving multiple masters which may not match the business roadmap. Deciding on which part of the organization need to be covered by the roadmap is critical and can drive the need for a multilevel approach.

What ends up on a product roadmap depends on what you define as a product.  Internal IT organizations have a tendency to equate platforms to products and internal personnel as customers. This can lead to developing separate technology and business roadmaps.  While the best solution is to take a business first approach when separate roadmaps are generated, the organization will require a process to sync the two levels of roadmaps.