Table of Contents
Introduction
Product roadmaps are the primary output of a product strategy. They describe the products you will introduce as you implement your product strategy. You use them to guide and synchronize your company’s efforts. For your roadmaps to be effective, you must:
- Set your roadmap in the context of your customers’ and competitors’ roadmaps.
- Express your roadmaps in terms of product value and performance capability, not features.
- Reconcile your product roadmap with engineering’s development strategy.
To do this, you need a suite of eight roadmaps. Each roadmap creates a link in the chain that connects your external environment to your product plans. For a summary of each roadmap and when to create it in your product strategy, see Table 16.
| Roadmap Name | Contents | When |
| Industry | Your target market’s product roadmap | Phase 1 |
| Application requirements | The requirements to operate on the customer’s workpiece | Phase 1 |
| Situation vs. application requirements | Current product’s ability to meet the application requirements over time | Phase 2 |
| Competitor performance | Forecast of your competitors’ ability to serve your target market | Phase 2 |
| Value | Value model that projects your value proposition over time | Phase 3 |
| Product performance | Capability requirements for each product on your roadmap | Phase 3 |
| Product architecture | Development strategy to implement the product performance roadmap | Phase 3 |
| Top-level product | Easy-to-communicate summary of performance and architecture roadmap | Phase 3 |
Phase I Roadmaps
Industry
The word “industry” in the industry roadmap refers to the industry that will buy your equipment. Think of it as your target customers’ product requirements roadmap. It includes technology changes and performance targets over time for your customers’ products.
Some industries publish a standard roadmap that you can use as a starting point. The semiconductor industry’s International Technology Roadmap for Semiconductors (ITRS) and the International Technology Roadmap for Photovoltaics (IRPV) are examples. However, it would be a mistake to assume that a published industry roadmap is your customers’ roadmap. It is not. It is a watered-down, pre-competitive version of what industry consortium members are doing and thinking. They pad the dates and leave out a lot of the specifics. While a published industry roadmap is a good place to start, it is not enough for high-resolution, product strategy development.
You will also encounter industries that do not publish a consensus roadmap. As an equipment supplier, you may need to survey industry participants about their plans and synthesize the results to create your own composite industry roadmap.
For example, say you were assembling an industry roadmap for photovoltaic solar cell manufacturers. Solar cell manufacturers make their living by turning polysilicon feedstock into solar modules that produce electricity from sunlight. Cell manufacturers sell these modules to homeowners, businesses, and electric utilities as an alternative energy source.
To create the solar cell manufacturers’ industry roadmap, organize your work in a table. Put key technical, economic, and performance attributes in the first column. Then add columns for each year in your strategy period. Finally, populate it with the annual targets for each attribute listed in the first column. See Figures 42 and 43.
Remember, you are creating your customers’ roadmap. So, express it in terms of your customers’ business, not yours. Not sure if you have it right? Ask yourself, “Does this look like a roadmap that my customers would present to their management, customers, investors, and partners?” If the answer is yes, you are on the right track.
Application Requirements
As part of your strategy development, you will choose a problem you intend to solve for your target customers. That problem is the equipment’s application. The application requirements roadmap describes the minimum equipment capability needed to address the application and support the industry roadmap. You will populate it with the process parameters that describe what is necessary to operate on the customer’s workpiece.
To create an applications roadmap, create a table with the most important application attributes in the first column. Then specify how the requirements for each of these will change over the strategy period. See the example in Figure 44.
Phase II Roadmaps
Situation vs. Application Requirements
You developed the application requirements roadmap in phase one of your strategy development. You will use it again in phase two to assess your situation versus the application requirements. Here is how:
- Start with the application requirements roadmap from phase one.
- Insert a column between the first and second columns.
- Label the column with the name of your current product.
- For each of the attributes listed in your roadmap, enter your current product’s current capability.
- Score your current product against the application requirements for each attribute for each year on your roadmap.
See the ingot growth furnace, Mr. Melty example in Figure 45.
Note that you are assessing the do-nothing scenario. You are answering the question, “What is my current product’s ability to meet the application requirements over time if I do not make any improvements?” In a market where application requirements change, you would expect your current product’s ability to meet requirements to worsen as time progresses.
Referring again to the example in Figure 43, you can see that the ingot growth furnace, Mr. Melty, will not meet the application requirements for material type and impurities performance attributes starting in year three. If you intend to continue participating in this market, you need to address these deficiencies in your product strategy.
Competitor Performance
In your competitors’ roadmaps, you will determine your current situation versus your competitors’ current and expected future capability. First, you need to determine which product performance factors to include. These factors fall into two categories: application and buying decision driver specifications.
From the application requirements roadmap, select the critical few attributes that define the application and represent your target customers’ most important buying criteria. Your mission is to analyze the competition on the most important application capabilities, not fully define the product as you would in your market requirements document. Buying decision drivers are the subset of value drivers that matter to capital equipment buying decisions. (For how to select buying decision drivers, refer to Part II: Value-Based Strategy.)
Next, assemble the most important application requirements and buying decision drivers into a product roadmap forecast for each of your competitors in each market segment of interest. Finally, compare your competitors’ roadmaps with your current capability.
As with the position versus application requirements roadmap, you are assessing the do-nothing scenario. The do-nothing scenario highlights the specifications on which you expect your competitors to gain an advantage if you do nothing and, therefore, you must address in your product strategy.
See Figure 46 for an example of a competitor’s roadmap as compared to your current product, Mr. Melty.
Phase III Roadmaps
Value
The value roadmap uses a value model to project your value proposition over the strategy period. It contains buying decision driver performance targets and expected purchase prices for each product on your roadmap. It will also contain your forecast for your competitor’s capability and prices at the time you plan to introduce each new product. Finally, it compares each product’s value to the competition at the time of its market introduction.
See the example in Figure 47, where the product manager:
- Identified throughput and yield as buying decision drivers.
- Determined that the product lines’ market share goals require a 15% value advantage over the strategy period.
- Expects to introduce two new products — N+1 in two years and N+2 in five years.
(For how to build a value model, see the Value-Based Strategy guide.)
Product Performance
The product performance roadmap captures the essence of your product strategy. It communicates the most important aspects of how you intend to address the customers’ application, create a competitive advantage, and achieve your profitability targets. A product performance roadmap contains:
- Planned release dates for your new products
- The same application specifications you used in your competitor performance roadmap
- The same buying decision drivers you used in your competitor performance and value roadmaps
- Performance levels against application requirements for your and your competitor’s current and planned products
- Buying decision driver performance and equipment prices for your and your competitor’s current and planned products
- Shading that shows where you have a disadvantaged, advantaged, or neutral position
- Product gross margin and cost targets for your current and planned products
See the example in Figure 48.
Architecture
The product manager owns the product performance roadmap. Engineering owns the architecture roadmap. Together, these two roadmaps describe what you must do and how you plan to do it. During strategy development, product management and engineering must iterate on these roadmaps until they align on:
- The number of products planned
- Product introduction dates
- Expectations that planned architecture changes will produce products that meet performance requirements
The architecture roadmap looks like the performance roadmap, except it has subsystems and subsystem architecture descriptions instead of performance specifications and targets. An architecture roadmap contains:
- The name of each of the equipment’s major subsystems
- Planned release dates for your new products
- A description of each subsystem for each of the products on the roadmap
- Shading to show whether each subsystem in each product is a reused existing design, modified version of existing designs, or a new design
See the example in Figure 49.
Unlike the performance requirements roadmap, the shading on the architecture roadmap says nothing about the competitiveness of the architecture selections. That is not the intent. The shading only shows the rough scope of the work required to implement each subsystem generation. It helps to communicate the design risk, plus the time and money needed for development. For example, if most of a new product’s subsystems require new designs, it typically means that you need more money and time than if you mostly reused and modified existing designs.
Top-Level
The top-level product roadmap summarizes your performance and architecture roadmaps into a graphical, easy-to-communicate format. At a glance, you can see how you compare to the competition on product release timing and key attribute performance.
See the example in Figure 50.
