The Three Product Roadmaps

Your product is your strategy, so your product roadmap is one of the most important things you own. If you do it right, you’ll have three.

Your product is your strategy, so your product roadmap is the purest expression of your strategy. Countless hours of work goes into crafting the product roadmap to ensure all of the effort in product development yields the best results. 

And yet, the product roadmap is often a source of conflict and frustration. The sales & marketing teams don’t trust the roadmap, the engineering team is always behind and the roadmap becomes a joke instead of a tool. Everyone has seen this happen more than once.

At the core of this conflict is a broken process for building the product roadmap. If you do it well, you will end up with not one but three product roadmaps! Juggling three different roadmaps might seem like three times as much work as one, but in reality it’s all part of the same process. If you have a structured planning process, each roadmap is a natural artifact of one step of that process. Those steps follow a specific order:

Step 1. Strategic Roadmap

The strategic roadmap represents all of the critical goals of the company. That might include growing the business, increasing value for your customers and staying ahead of competitors.

The strategic roadmap reflects WHY you need to make changes, even if the details of those changes are not specific. For example, your strategic roadmap might include building specific partnerships to increase your growth rate even if the details of the partnership integration are not clear yet. Each of the items on a strategic roadmap are the bets you are making as a company, either on yourself or the market. Anyone should be able to read your strategic roadmap and know exactly how you plan to change and grow over the coming year(s). 

Even though the strategic roadmap will have very little detail, it’s where most of the planning effort is invested. That’s because everything on the strategic roadmap will be an enormous investment of time and money, so you cannot be too careful in how you spend it. Once your strategic roadmap is clear, you can figure out the details on the other roadmaps. The strategic roadmap is one of the most powerful tools for the CEO, who is the ultimate decision maker. 

The strategic roadmap is something you’d never share outside your company, and often lives in tools like Notion or Google Docs. Bonus points if you make it available to everyone on your team, that kind of transparency is always appreciated. 

Step 2. Public Roadmap

You’re certainly not going to tell your customers, partners and the public about all of your secret plans! The public roadmap is a version of the strategic roadmap that focuses on WHAT you’ll be doing, but not WHY. For example, you might roll out a new set of APIs which you’ll use to build a key partnership in the future, but your public roadmap will only include those APIs and not the announcement of the partnership. 

You might not share the public roadmap with the public, but it should be at a level where you would be comfortable doing so if needed. Why do we need a public roadmap if we’re not sharing it with the public? This is the level that most of your team, partners and customers will need to understand your product priorities. They care about what is changing in your product and when. 

The public roadmap can live in many places, some companies even publish them on their websites. Most companies have it live as a series of documents that are easily shared with everyone. 

Step 3. Engineering Roadmap

The engineering team needs to do the hard work of making your plans into reality. As a result, they deal with all of the details involved in the higher-level concepts of the other roadmaps. Your public roadmap might include releasing a new signup flow, but the engineering roadmap has to deal with all of the pieces that are required to make that work (new UI, new APIs, etc). 

It’s unlikely that anyone other than the product and engineering team will ever see the engineering roadmap, or even understand it, but that’s okay! Any changes that happen on the engineering roadmap can be reflected on the other roadmaps in a much easier to understand way. For example, if it is going to take twice as long to build the new signup flow than originally thought, that might shift the priorities on the public and strategic roadmaps. It’s much easier than trying to teach the sales team to understand your engineering process.

The engineering roadmap lives in the engineering process tools of choice for your teams, and is a mass of tickets and other tracking items. It might not stretch as far into the future as the other roadmaps, but it has more detail than all of the others combined. 

---

For each of these roadmaps, priorities flow downwards and updates flow upwards. 

If your strategic priorities change, those changes are reflected on the strategic roadmap which, in turn, changes the priorities on the public roadmap which changes the priorities on the engineering roadmap. Likewise, if implementation takes longer on the engineering roadmap than expected, it shifts the public roadmap and, in turn, the strategic roadmap. That integration shows that each of the three product roadmaps is just a different side of the same thing. The strategic roadmaps tells you WHY, the public roadmap tells you WHAT and the engineering roadmap tells you WHEN.

That might make sense, but I’m sure you have a few questions…

Who is in charge of ensuring the three roadmaps are all in sync? 

Product management. It’s a fundamental part of the product function to both manage priorities and communicate them clearly to everyone. Having these three different levels of product roadmap makes the job of product managers easier by having different levels of roadmap to communicate with different audiences. You don’t want your executives trying to interpret the engineering roadmap anymore than you want to advertise your secret strategic plans to the world. It takes surprisingly little effort to keep them updated, and pays dividends in clarity and alignment. 

How does this solve all of your problems with roadmap conflict? 

With clearer communication most of the conflicts about the roadmap are usually resolved. Each team can understand, and provide feedback on, the roadmap at the level most appropriate for them. The structure of the process also enforces good planning which means you’re less likely to have the roadmap change on a constant basis. 

Are there drawbacks to using this approach? 

Yes, many companies realize that they don’t have as clear a strategy as they thought. Their engineering roadmap might be impressive and detailed, but when you roll it up into a public and strategic roadmap it’s a mess, with fragmented efforts going in many directions. Or, the strategic roadmap is clear and inspiring but it turns out the engineering team is working on entirely different things. These realizations are hard to see, but it’s an important step in improving for the future. 

Remember, your product roadmap IS the company strategy. It’s a lot easier to change your roadmap than go back and rebuild your product in the future. As a result, you can’t spend too much time ensuring it represents the best path forward.