November 3rd, 2003
Product Roadmaps - a practical guide for product managers
Speaker: Barbara Nelson, Pragmatic Marketing

Download Presentation

The SVPMA was glad to welcome back Barbara Nelson of Pragmatic Marketing to speak at the November event on Product Roadmaps. Product roadmaps are a topic at the core of product management and often poorly understood. Pulling from her 21 years of software industry experience as a Pragmatic Marketing Instructor, Barbara covered everything from why product management should build roadmaps to how to design one.

Building the roadmap serves multiple purposes. It gives internal and external audiences a product vision of the future. It reduces short-term mistakes, and it helps customers integrate your product plan into their long-term strategy. Even without these benefits, the actual process of building the roadmap serves to focus a product manager's and organization's thinking. Barbara shared a quote from educator and writer, Laurence J. Peter: “If you don't know where you are going, you will probably end up some place else.” A roadmap can help ensure you end up where you want to go.

The product manager is the owner of the roadmap. Sometimes this can be a challenge when the executive doesn't want to give up control. But the product manager must take the responsibility. She brings the market expertise to the process from time spent outside the office with customers. She leads the cross-functional team to formulate what goes in the roadmap: a necessary step in developing organizational buy-in. Once these steps are completed, the product manager owns documenting the roadmap and defining what gets communicated to external groups such as partners and customers. Finally, the product manager is responsible for updating the roadmap when market conditions inevitably change.

Barbara offered a few cautions: if there is a large customer requiring custom work. The services group should handle this. You do not want to limit future growth through endless cycles of customization. The roadmap is a plan not a commitment. Therefore, do not accept any contracts with the roadmap attached. Also, assume your competition will see your roadmap.

Even with a roadmap, the sales channel can still be a source of problems. They will often sell futures as features. Even worse, they may do this in the wrong target market. The product manager must get sales refocused on the right target market. Development offers a different but equal challenge because the delivery dates and content have a high level of uncertainty. If the development cycle far exceeds the sales cycle, it might be preferable to break the releases into smaller chunks.

The roadmap process starts with getting out of the office and understanding the market. The product manager needs to speak with customers, evaluators, and potential customers. The next steps are to quantify the problem and assess whether it is urgent and pervasive, because these are the best problems to solve. Finally, determine what the whole solution looks like and whether this will require partnering or working with third party products? The product manager is the messenger of the market and can take this information to share with others in the company. Barbara advises that it is best to be very deliberate with the segments of the market you are pursuing and focus whole releases around a segment rather than dribbling out a few features for each segment on every release.

There are two other important elements of building a roadmap: establishing your competitive strategy and researching the technology landscape. To establish your competitive strategy, identify segments that you can dominate and that leverage your organizations “distinctive competence.” Add to this, interviews you have conducted of technology reviewers to gauge adoption of standards and look at emerging technologies and how these could be applied to your market.

Synthesize all this market research. Review it with an internal cross-functional team. Then validate it with trusted partners, followed by trusted customers and potential customers.

The roadmap itself should communicate five basic facts:

• Who - market segments
• Why - business problem
• What - product requirements
• How - technology
• When - time

The communication should be at a high level. The features should be tied to the problem being addressed. The dates should be conservative, represented by quarter and half year. Although there are not many examples available, figure 1 shows a sample template.

Ultimately, it is the roadmap process that makes the roadmap valuable. All the work that goes into researching and collaborating on the roadmap gets product management, development, and the executives on the same page. This makes the roadmap a critical planning tool for product management.

Product Roadmap (fig. 1)

	Year 1				Year 2		Year 3	Beyond
	Q1	Q2	Q3	Q4	1h	2h
Project
Market Forces
Market Segment
Major Feature
Client
Server/Architecture
Platform

This document contains forward-looking statements based on current expectations, forecasts and assumptions of the Company that involve risks and uncertainties. Forward looking statements are subject to risks and uncertainties associated with the Company's business that could cause actual results to vary materially from those stated or implied by such forward-looking statements. Figure 1: Product Roadmap Template