Roadmapping 101 - What is a "Roadmap" Anyway
As someone new to product, I want to know what the hell this roadmap thing actually is, so I can succeed in my role.
Epic: Mastering Product
We can boil down all of product management into one document. The Roadmap
It’s the be-all-end-all of how you’ll be perceived as a product manager and acts as the main oversight of your day-to-day work.
So - what the hell is a roadmap?
Product School defines a roadmap as the following:
A product roadmap is a visualization of the life of your product. It’s the essential strategy document for all product managers, as it lays out your vision, and the stages between where you are now and the realization of that vision.
So… it’s a map! 😝
Simplistically, it is a document highlighting where we plan to go, given the backdrop of where we are today. That’s what you can read endless articles on the internet about. It’s also only half the battle.
I view the roadmap as a tool for strategic prioritization, consensus building, and organizational oversight. Your judgment is evaluated by the company you work for by the contents of the roadmap - does everyone agree you're focusing on the right features? Your ability to deliver is evaluated by how effectively you execute on the approved roadmap.
The focus on the roadmap is what makes product management an output-focused role of what you actually get done versus an input focused role where some balding middle-aged midwit manager is tracking how many hours you work, and how many calls you take.
It’s the focus on execution and performance that Product Management ideal white-collar careers to fund going sovereign - as recommended by @bowtiedbull
Roadmapping as a Team Sport
With so much focus on the roadmap by your superiors, it means the document is innately a political tool. As with anything political, this means it will be used against you by those who mean you no well. It’s with great care you should think about your roadmap as a PM. If someone decides to gun for your head, it will begin with scrutiny of your roadmap. Scrutinizing a PM’s roadmap is in essence saying “We question your judgment of what’s important and don’t agree with your Strategic decision making”.
A product manager does not create their roadmap in a vacuum - they simply are the owners of the process. Because of this fact, a way around protect against potential threats is to intentionally solicit input on your roadmap from anyone you need to have your back. I’ve generally found people are actually quite grateful and excited that you approached them for their thoughts.
Typically, you’ll with business SME1 and executive team stakeholders to figure out what’s most important to get done, and what the potential upside of that work could entail. You can fully expect at times to have executives completely dictate what should be in the doc. The more junior you are, the more often this will be the case. With experience comes the gravitas to persuade others about what you believe the priorities are.
Once you have an idea of what you’ll be focusing on, you’ll then collaborate with your engineering leads to try to - at a super general level - quantify how much effort it will take to execute all new features and architectures proposed in your roadmap. The goal of this is to ultimately propose a realistic amount of work to commit to in the roadmap.
The general rule of thumb, the more effectively you collaborate and utilize the expertise of your development team on product decisions, the better a product manager you’ll ultimately be.
What’s at Stake with your Roadmap
The roadmap will also be the basis for how everyone will perceive you at the company. As your performance against the roadmap is how you’ll be judged, the what and how of execution will determine if you get promoted, get a raise, and get a seat a the big boy’s table dictating where the company goes.
Ask any hiring manager how you’ll be judged when you take the role, 99% will use the word “Roadmap” in their answer.
The most important decision that comes out of the roadmapping process is resourcing and organizational commitment to what you and your team are working on. This can vary drastically from company to company, even from team to team. It all depends on the governance of your company.
You can tell a lot about a company - and its product org - by how they run its roadmapping process. The general rule of thumb - the younger and more startup-like the company, the more frequency and tighter timeframe to which they participate in the roadmap development and approval.
This makes sense intuitively. When you are a young and not yet established business, you have to be more flexible to get traction and gain market share in your industry. Conversely, as a giant monopoly, the roadmap process can be run once a year to outline corporate focus and to make hiring asks/allocate capital across different parts of the company.
Roadmapping and Governance
Roadmap oversight is a form of governance over the product organization. The more bureaucratic and annoying the governance structure of a company, the more complicated / drawn out / giant pain in the ass a roadmap process will be. The less work/amount of approvers on the document, the more frequency you’ll be expected to deliver it with.
.
At a small startup, you may not even have a formal roadmap process! If you’ve yet to achieve product-market fit, you’ll quite literally change what you are working on week over week. It does not make sense to forecast a quarter’s worth of work if by week 3 it’s all thrown out the window. Here, it’s the founders making the call.
At a startup where you’ve found some traction, dare I say even profitable, you may not yet have investors. That means a roadmap is a tool for the executive team to approve of what direction you're taking their precious engineering resources. I see this happening at a quarterly level, or half-year level. You’re likely getting guidance from the exec team on what should be making its way into the roadmap, even before you bring it to them for approval.
When a startup takes on investors, that means you get a board of directors (Yay!) That board of directors (should) be people who have a strategic insight into your business, and as such will certainly have a say in the what and how your company builds. You can expect roadmap presentations to the board. Hopefully, they are acting in a more advisory role and not heavy-handed, but depending on where they fall on the scale, there will be hoops to jump through for approval.
As the company matures, the roadmap process will get more complicated, extending into a company-wide exercise. The roadmap presentations can evolve into an annual event, with 16 hours of presentations over the course of a week for the board, with leads extending well beyond product getting in on the action.
For example, the product org may have to interface with the sales org to measure the upside of the roadmap. For every product team, the addressable market needs to be measured will need to be. For that addressable market, you’ll have to quantify your current market share. Within current market share, you’ll have to quantify how you could up-sell on those clients elsewhere.
The level of detail you may be forced to go into could be nauseating.
You may have to work with the leadership / executive team to start projecting out where you’ll be 3-5 years from now, so your board is confident you have an “Eye to the future”.
At enough scale, roadmap time of year is where you as a technology org could make the request to invest in resources to deliver on what you propose as the work to do. This can be for both engineers and product managers. Particularly if your board is filled with Private Equity types, there will be some degree of negotiation of how many people you actually need to deliver what the board wants to see.
The governance doesn’t stop there! At its most extreme you can get governance via a roadmap from, well, the US Government itself!
When Microsoft got put under investigation for monopolistic practices in the 90s, part of the settlement included them having to LITERALLY, loop big daddy government into their roadmap practices for documentation.
Plaintiffs, after consulting with the TC and Craig Hunt, the California Group's technical expert,(3) were impressed by Mr. Muglia's analysis of the current predicament and share his view that a rewrite of the documentation may well prove more successful in resolving Plaintiffs' concerns with the documentation than the current approach.(4) Plaintiffs and Microsoft have agreed to proceed with a project for rewriting the technical documentation that involves four key steps: (1) the parties must agree on a specification for the new documentation; (2) the parties must agree on a project schedule for all the protocols; (3) Microsoft must rewrite the documentation for each protocol according to this schedule; and (4) the resulting new documentation must be tested and validated to ensure its completeness and accuracy. As it is clear that this project to rewrite the technical documentation will require a significant amount of time to complete, and as explained more fully below, Plaintiffs have informed Microsoft that an extension of portions of the Final Judgments will be necessary, and Microsoft has consented to such an extension.
How this Affects Your Day-to-Day as a PM
I’ve done both the quarterly startup roadmap and the annual extravaganza of a long-established unicorn. There are pros and cons to each.
For a startup/ younger company, you’re more likely to the roadmap on a quarterly level, as the feedback loop is more frequent. The business change more often, innately requiring updates with more regularity. I know there’s gonna be a week or two every quarter where I’m rushing to get my roadmap together so that the execs can sign off before the following quarter actually starts.
For a more mature company, the annual process could win out. It basically comes out to one month a year being absolutely miserable. That said, After that heavy lifting, I have a clear forecast for what the rest of the year will look like. It’s nice that I do not have to prepare my most important documentation every 3 months.
As for which is better - at both an individual and company-wide level, I’ll try and answer in a future paid subscriber article where I’ll walk you through, step by step, the various ways I’ve specifically roadmapped in my career.
If you’ve liked what you’ve read and want to make the Pivot to Product in you own life, you should strongly consider my services.
Got a product resume you need to up-level? I’ll review your resume, then talk tactics on a call.
Are you struggling with a product problem today? I’ll hop on a call and help you put forth the game plan to solve your issues.
Make 6 figures, work remote, and build the future while at it. It’s not a bad gig.
SME - Subject Matter Expert - Someone who knows the details of how something happens in practice.