Dear Strategy:
“How do I align my product strategy and product roadmap with our technology roadmap, in the face of a strong engineering organization?”
Ahh, the product roadmap… such an overused yet somehow still elusive term! Before I even touch the last part of this question about the role that engineering should or shouldn’t play with respect to roadmaps, I first want to straighten out a few definitions that, hopefully, will put this question into a much clearer light.
At its core, a roadmap is nothing more than a specified timeline of actions. Much like the strategic plans that they typically support, most roadmaps cover a 3 to 5-year time horizon, and provide a high-level outline of key actions, time frames, owners, and costs.
Sounds simple enough on the surface.
However, it is from this simplicity that chaos often arises because, as you might have already guessed, any tool with so broad a definition could probably be utilized in any number of different applications. And that’s exactly why the multitudes of different roadmaps that might exist within any given organization at any given time could very easily become confused. So, let’s see if we can clear that part up just a bit.
In relation to most product organizations, there will typically be three different types of roadmaps that could exist. They are:
Strategy Roadmaps – These are the highest level of roadmaps that exist within a product organization and will typically be completed as part of an overall product or portfolio strategy. The purpose of this type of roadmap is to outline the high-level investments that will need to be made in conjunction with executing a strategic plan. As such, these roadmaps are used to 1) ensure that investors understand the general magnitude of investments that will need to be made in order to execute a strategy and achieve a set of strategic goals, and; 2) help business leaders prioritize investments between different product groups and provide feedback as to which investments will likely be supported and which ones will not. This last part is really important, by the way, because any changes made to your investment plan will invariably lead to changes in your overall strategy, and possibly even your over-arching strategic goals.
Product Roadmaps – These roadmaps sit one level below your strategy roadmaps, both in terms of overall hierarchy and level of detail (meaning that your product roadmaps will be more detailed than your strategy roadmaps). Whereas strategy roadmaps are meant to outline only the highest level of investment that will be required to execute upon a strategic plan, product roadmaps exist for the purpose of outlining the specific actions that must be taken on a given product over some period of time. Typically, product roadmaps are developed based on already approved strategy roadmaps and add details to those roadmaps with respect to every part of a product’s overall marketing mix (i.e. product, price, promotion, and place). Using this definition, it follows that not every action specified on a product roadmap will have specific investment dollars tied to it and, in this way, product roadmaps usually serve less as tools for planning investments and more as tools for helping product managers keep track of their portfolio-level actions over time.
Technology Roadmaps – The third level that exists in our hierarchy is reserved for technology roadmaps. Of course, this place in the order of things is not meant to diminish the importance of technology roadmaps, but, rather, to reflect the more limited (and, therefore, more detailed) scope of what these tools are designed to cover. Essentially, a technology roadmap expands upon just the product development portion of a product roadmap, thereby providing clear guidance to technology and/or engineering teams as to what types of development projects they can expect to see in the future. In this capacity, technology roadmaps will typically include a greater amount of detail about these projects than you might see on a product roadmap; including information about specific development costs, project dependencies, required resources, and even individual task owners.
It should be noted, despite their differences, that all of these roadmaps are meant to be used as mid-to-long-range planning and scheduling tools. It’s just the scope and accuracy that sets them apart from one another – with strategy roadmaps generally covering the broadest scope and containing the lowest level of accuracy, and technology roadmaps covering the narrowest scope and containing the highest level of accuracy.
Another important thing to keep in mind is that all of these roadmaps should definitively build upon one another – meaning that they must all exist together, and that they must all ultimately be in alignment. So, if a product roadmap exists without a strategy roadmap, you run the risk of having product actions that aren’t aligned to an overall strategy; which will also result in having to do a lot more convincing when it comes time to ask for the actual investments. Similarly (and perhaps even more dangerous), if a technology roadmap exists without the other roadmaps above it, by definition, you’ll be running your business based on bottoms-up feature-building rather than top-down strategic management. And this is likely to result in your company building a bunch of “cool” new products or enhancements that your customers may or may not ever want to buy.
“If a technology roadmap exists without the other roadmaps above it, you’ll be running your business based on bottoms-up feature-building rather than top-down strategic management.”
With all of this said, if, as is implied in this question, you have the impression that your engineering organization is overly strong (i.e. the technology roadmap is taking the lead), it is likely because your other roadmaps are either weak or non-existent. Whenever I see a technology roadmap being used as the dominant planning tool in an organization, it’s usually not because the engineering team is trying to take over; but it usually is because they’re not getting strong enough direction from anywhere else. Every company needs a plan; and if it isn’t being created from the top down, organizations will inevitably find another way to fill in the gaps. In this case, that “other way” is the technology roadmap.
So, the short answer to all of this is to make sure you have all three roadmaps working together in your organization. In other words, make sure they all exist, make sure they are all clearly owned, and make sure there is a solid understanding of the hierarchy that I outlined above (i.e. the strategy roadmap rules the product roadmap, and the product roadmap rules the technology roadmap).
That’s how you gain roadmap alignment. And if you follow that formula, you should have a pretty good roadmap for achieving roadmap success!
Listen to the podcast episode
Dear Strategy: Episode 091
###
Are you interested in strategy workshops for your product, marketing, or business managers? If so, please be sure to visit Strategy Generation Company by clicking the link below:
Bob Caporale is the founder of Strategy Generation Company, the author of Creative Strategy Generation and the host of the Dear Strategy podcast. You can learn more about his work by visiting bobcaporale.com.
