A Discussion of Roadmap Planning

In a recent survey of product managers, the biggest challenge they faced was that of “Roadmap planning and commitment”. Figuring out where your products should be headed, in what timeframe and getting corporate support to commit resources to the plan can be daunting and frustrating. This article explores methods for improving the process of developing your plan and in getting organizational support. For reference, also see the article Your Product Management Poll Results.

What is a Product Roadmap?

The product roadmap provides a vision of where you think your product or product portfolio is heading beyond the next few releases. It attempts to define product enhancements that may be developed to achieve business or market goals, given a current set of assumptions. Depending on your market and product, it can be looking out 1-2 years for typical software applications to as long as 5-10 years for software platforms and hardware products.

The purpose for developing the plan can be two-fold: 1) as an internal plan for aligning stakeholders and in developing a companion technology development plan, and 2) as an external communication to key customers, especially in a B2B market, to align their budgeting cycles and demonstrate thought leadership. The external plan is typically a sanitized and limited version of the internal plan. The overall intent is to provide a general direction of where you’re heading.

The product roadmap often has 2-3 timeframes that it focuses on. In the short-term, it can document the expected Release Plan(s) of the next 1-2 releases. These plans typically have relatively high confidence in capabilities and release dates and may have a great deal of detail available. In the mid-term, it can define capabilities that have at least some amount of investigation accomplished and possibly even development has begun. These timeframes for release are likely less accurate and the feature sets may still be in flux. In the long-term, the plan may be completely speculative, with only cursory assessment of the capabilities and a broad brush at the timeframes. This portion may be more aspiration than reality or can be setting a major goal to achieve for the organization. Figure 1 shows a conceptual roadmap with increasing vagueness as the timeline goes out.

Figure 1 - Conceptual roadmap with increasing vagueness

The important feature of a product roadmap, especially when communicating to customers, is that is just a vision, not a commitment, especially in the long-term. The reality is it is wrong in some aspect and will change as business conditions and markets change. For this reason, it needs to be revisited on a regular basis, such as quarterly, and be updated to reflect current thinking. However, it should not be completely changing every review or it will not provide any real value or credibility from a planning perspective. This often happens when the roadmap is reactively revised to chase the next big sales deal. As an early startup, this may be required, but as the company matures this behavior will begin to wreak havoc.

Why Roadmap Planning is challenging

“Prediction is very difficult, especially if it’s about the future” - Neils Bohr

Besides the fact that a roadmap is about the future and is likely to change, it can also be a highly political process in some companies. The reality of resource constraints in all companies requires that prioritization occurs and not everything that is desired can be delivered. The major reason for developing a roadmap is to define where you want to be in the market at some specific point in the future and begin activities that drive the deliverables. This requires making resource allocation trade-offs and bets. It means not investing 100% of your resources in the next short term release, but having a portfolio of short and long term projects going in parallel.

The following lists some of the major reasons that roadmap planning is so challenging in many companies:

1. There is no formal process. The roadmap is either non-existent or is developed in an ad-hoc fashion in response to customer, sales or executive requests. There is no good process for developing a roadmap and in aligning the organization around it. The roadmap in this instance is probably not effective for planning purposes.

2. It’s only a short term release plan. The “roadmap” only documents the feature list of the next 1-2 releases and does not show any vision or direction as to where the company is going in the longer term. It is not effective in making progress towards major new functionality that has a longer lead time because there is no plan to get there. Major new innovative capabilities will be difficult.

3. It’s too focused on specific features. You’ll see this in roadmaps that look like a laundry-list of low level features with no apparent rhyme or reason. The focus is too low level and missing alignment to major corporate objectives, market and technology trends, and major new value propositions to customers. It could also indicate a shotgun approach to addressing individual customer feature requests without developing the big picture.

4. It’s only a wish-list. While it may have well-thought-out capabilities and even buy-in from major stakeholders, resources are not allocated to make it happen in the timelines indicated. These can include upfront technical analysis, prototyping and market validation, requirements development, and project planning and tracking. This also occurs when there is no technology development plan created to support the deliverables on the roadmap. Without a plan, you’re guaranteed NOT to get there.

5. It’s not perceived as needed. “We’re Agile and can quickly respond to customer needs as they arise”. The beauty of Agile software development is that it provides a means of getting smaller releases to market quickly to validate the product concept. However, once a viable solution emerges with real paying customers, a bigger plan should be put in place to capitalize on the opportunity and mature the solution. This can include expansion to new geographies, new platforms, new users, addressing known operational issues etc. Some form of roadmap will help guide the overall business planning and prioritization of the release planning efforts.

Suggestions for Roadmap Planning

There are 3 specific activities that need to occur in order to create a product roadmap plan that will get some traction. These are:

· Determining where to go

· Getting internal alignment

· Creating the Technology Plan and committing resources

Determining where to go

“A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” – Wayne Getzky.

It’s a complex matter assessing where you should be “skating to” with your product or product portfolio, however, there are some specific areas of focus that can help.
For existing products, a key question is where are they in the product lifecycle (Figure 2)? If early in the introduction stage, make sure you have all of the necessary capabilities in place to deliver the core value proposition to the end user. Is the user experience as good as you can make it, both in using the product and in buying/installing/getting support, etc? Or maybe it’s time to add additional functionality to be attractive to adjacent target market users.	Figure 2 - Product Lifecycle Stages
If you’re in the growth stage, being able to scale and meet growth demands may require a significant overhaul in architecture or tools for managing the system. Or making the product plug-and-play with existing systems or expanding internationally is important. If you’re in maturity stage, reducing product and support costs are key, in addition to finding add-ons or extensions to offer to the installed base. And if in the decline stage, is there something you can do to extend the life or perhaps your roadmap is an explicit end-of-life date and the retirement or replacement plan.

For new products, do you actually have them in the pipeline, especially as your existing products are hitting maturity or beyond? Do your existing customers have similar jobs to accomplish that you can do better than current solutions? Are there segments of potential customers who are not using your products that might be attracted to simpler, lower cost versions or more robust, feature rich versions?

The key to building a solid plan is to paint the big picture of new value that you will be creating for customers. The value piece comes from defining your roadmap in terms of solving specific market problems, not in a detailed list of features.

For example, imagine you are Intuit and recognize an opportunity to improve the online banking experience currently offered from banks by providing to them online capabilities found in your Quicken product. The list of value-added solutions you could provide over time could include “Manage and pay bills”, “Know where my money went”, “Know how much I can spend”, “Pay off my debt”, “Save for my life goals”, “Grow my investment portfolio”, etc. Within these broad value categories can be numerous features delivered in time-spaced bundles that are attractive to some segment of users as complete core value propositions. These bundles help to prioritize functionality and avoid random-looking laundry lists of features that are highly diluted in their value proposition. See Figure 3.

Figure 3 - Sample goal-oriented roadmap

Getting Internal Alignment

The act of creating a product roadmap plan ultimately requires alignment and approval within the organization. The creation of the roadmap should not be done in a vacuum, such as exclusively within a product management organization. It needs to have input from other functions and customers. Once input is received, it also needs to be prioritized. This is where understanding corporate and product objectives will provide an important role.

Is product revenue growth expected with a clear understanding of where it’s coming from? Is there a gap in what current products can deliver necessitating new products? Are there new markets or geographies expansions in the plan? Is increased profitability the main goal, with reductions in product and support costs the expectation or opportunity?

The closer you can align your product roadmap plan to stated corporate and product goals, the easier it will be to prioritize and gain internal alignment. If your company is weak at providing these goals, then indeed the alignment job will be more difficult, but a roadmap discussion could actually help the organization develop some objectives.

Another way to get alignment is to identify specific weaknesses and threats in your product portfolio and focus on filling those gaps as the top priority. It’s always easier to rally a group around meeting a threat than attempting to take advantage of potential opportunities. While opportunities are interesting, threats are worrisome and initiate action.

From a process perspective, one means of orchestrating formal conversations is the creation of a Product Council or Product Steering Committee. It is best if the voting members of this group comprise only a handful of top execs – for example: CEO, CTO, VP Marketing, VP Sales, and VP Ops, with the actual proposals driven from representatives from the next tier down. The proposals are developed offline from the approval meetings and will have better success if socialized around the organization.

As indicated above, this group should meet on a periodic basis and adjust the plan as market and business conditions change. The formal owner of the product roadmap and the process should be the head of Product Management.

Creating the Technology Plan

Once you have a target direction and alignment within the organization towards it, you’ve only accomplished half the battle. Without a solid implementation plan with committed resources, your roadmap is just a mirage off in the distance with capabilities that will always be out of reach.

A key companion plan to the product roadmap is the technology roadmap or technology plan. This highlights specific high level technical initiatives and deliverables required to satisfy the milestones on the product roadmap. It can highlight major technology pieces that need to be developed or acquired in a specific timeframe. It can highlight major platform additions or changes required. Or it can highlight what feasibility research or prototyping is required to validate requirements or the concept.

Whatever is required, it is the technology plan that will begin to point out what work needs to occur at specific points to drive the desired future implementations. Figure 4 depicts a simple version of a combined product and technology roadmaps. Typical internal plans will have more detail.

Figure 4 - Simplified combined Product & Technology Roadmaps

Of special importance is who needs to be assigned in the short term to deliver what, such that resource trade-offs are made against current projects. Either way, there’s no free lunch if you want to deliver significant value capabilities to the marketplace in the future. As indicated in Figure 4, some capabilities have an especially long lead time that need to be developed in parallel with near-term projects. Or perhaps staff augmentation is required to implement the roadmap plan.

Formal projects need to be created to jumpstart the early planning and feasibility analysis, and are unlikely to get traction if assigned “in your spare time against current commitments”. The resource commitments and effects on other projects need to have the full endorsement from the senior executives. If this does not occur, the roadmap process will be toothless and eventually die from lack of credibility.

Summary

Planning your future product capabilities is one of the most challenging activities in any organization. The key to success is an active engagement of executives and key functions within the organization to align the product roadmap with market and business needs. It isn’t enough, however, to just create the vision of where you want to go. There also needs to be an identification of the technology pieces required to implement it and commitment of resources far enough in advance to hit the target milestones. This comes at a cost to current planning and development activities but is necessary if you are to achieve a culture of continuous innovation and market leadership.

Related Articles:

Attachments:

File	Description	File size
Guiding_Your_Product_Future.pdf		726 kB