This article proposes several alternatives to feature driven roadmaps.
But it ignores the main reason that roadmaps exist: as communication documents to the rest of the organization. This is what I used roadmaps for as a PM for a decade, but it was driven home after talking to hundreds of PMs after founding my fourth company[1] and coaching PMs and product/dev teams to level up for another decade[2].
The real roadmap trap in my experience is that the org takes a roadmap as a promise of when specific things will be delivered. The best approach to avoid this is to not do roadmaps. But that’s also unrealistic for most orgs. The next best approach is to show the org short-term work that will definitely get done, and caveat the heck out of anything longer term. I’ll happily commit to 6-8 weeks out, tentatively commit to 10-20 weeks, and add large asterisks to anything longer than that.
Thanks for sharing your thoughts Kareem! Author of the article here.
Your point on roadmap communication probably deserves another article in itself. “The real roadmap trap in my experience is that the org takes a roadmap as a promise of when specific things will be delivered.” That sentence brings home a point that I didn’t clarify well in the article.
Let me try to expand my view on the underlying problems faced by PMs that I think you’re touching upon: Product roadmaps are confused with release plans. And us Product Managers haven’t done a great job at distinguishing the two. This stems from a mismatch in expectations: While Product Managers try to create and communicate the mid-term product strategy, the ‘operational’ stakeholders (functions whose job is to conduct marketing campaigns, create sales collateral etc.) need to know about product releases.
The concept that Product Roadmaps ≠ Release Plans isn’t novel, and my motivation behind the article stems from exactly the problem you are describing. I think changing the format of the roadmap is a great way to start changing expectations and discussions around roadmaps. It’s not sufficient in itself, but necessary. As long as we show features mapped over time, our audience will take a roadmap “as a promise of when specific things will be delivered”, to borrow your phrasing.
I guess just one of the issues in separating the two formats is that somewhere between 1-6 months out, the line between a release plan and a roadmap blurries. That’s why I’m currently convinced that these two need to live in distinct documents.
With regards to the time horizon, I’m 100% with you in that I’m also hesitant to commit to anything further than 6-8 weeks/one dev cycle out. However I do think that it’s important to communicate product goals to the rest of the org beyond that time frame, though not in the form of features.
A final thought: This topic is highly dependent on company and product maturity. My experience comes mostly from fairly early-stage companies. In my mind, as the company matures, other functions have longer planning cycles, and the committed time horizon must increase. So I’d be curious to hear how later-stage product teams are handling this.
As a second data point, this describes almost the exact need addressed and approach we've taken to roadmaps when we've needed to produce them. We've actually gone a while now without producing one.
What I'd like us to substitute it with is a list of investment priorities over the course of the next year, a rough idea of how much investment each priority will receive relative to the others, and some indicative projects that investing in each of these priorities might result in. Again, all this with more certainly as the timeframe pulls back toward the present day.
Agree with this take 100%. It's one the reasons that I'm a big fan of the SAFe (Scaled Agile) approach here. Your only commitment is the next PI (8-12 weeks) and that's a commitment that comes from a plan made by developers from priorities provided to them by the org.
Anything after that is subject to change that the the organization can reserve the right to pivot to new opportunities if needed. Makes far more sense but it's enshrined in an official structure rather than a PM's preferences.
I'm really wondering in which world the product managers are living in.
What is the goal of a roadmap ? This article doesn't even touch a point on it.
The goal is : In any company there are people who want to have an answer to the question "what comes next on your product?". Those people can be any of: CSM to prepare a presentation for customers, bored customer who want to talk to CSM, Sales people who want to impress their prospect, Execs to tell the public and investors that things are moving. Do those people care that the roadmap is going to be respected ? Not really.
The roadmap is not a product management tool, it is a communication tool. So my advice to PM, you are asked to create a roadmap ? Put all the things in the roadmap that people want to hear, forget about it, and continue working on what you were working on.
This is directionally right but practically wrong.
You will be a disliked product manager if you continually tell people what they want to hear, but never deliver on it.
Rather, tell (read: persuade) people what they need to hear. Your job as a product manager is to negotiate and reconcile high-level plans and low-level execution.
Really interesting points, thanks. Your comment made me realise that I failed to point out an important underlying argument of the article: Product Roadmaps ≠ Release Plans.
Goal of a roadmap = Communicate the most important objectives for the product team (therefore should be based on and closely tied to the company’s strategy)
Goal of a release plan = Communicate what features are being release next and when, so that other functions can plan accordingly
Only both of them together provide a comprehensive view over what the product team is working on. What most stakeholders need to know is “What comes next” and “when”, so they can plan their work accordingly. So the mistake we (Product Managers) make is to start putting feature requests and due dates on our strategic roadmap. And this is exactly where the problems with roadmaps are created, as described in the first part of the article.
With regards to putting “all the things in the roadmap that people want to hear, forget about it, and continue working on what you were working on.”, I would strongly advise against that for three reasons:
(1) It encourages Design by Committee
(2) The other teams will have a hard time trusting a product team that puts their requests on the roadmap but consistently fails to deliver on them. It’s better to create a shared understanding of where their requests fit in the overall strategy.
(3) And, as redwood pointed it, it poses the risk that sales will sell roadmap commitments that you can never deliver on, which decreases trust with customers.
Curious to hear: How would you expect the product team to communicate their objectives and progress to the rest of the organisation?
You have to understand why the rest of the organization wants to know what the product team is working on. There is a different needs depending on the type of company you are working at:
- If you are working in a saas b2b smb or b2c, usually as a product team you don't want to commit on anything, so the rest of the organization (except leadership) wants to know if a feature, is on the list of things the product team is thinking of or if they don't plan at all to work on a feature. And if you are very good you can split features in 3 buckets : things you are working on, things you are thinking about, all others. And for leadership, basically they don't really have to know what the product team is working on, it is on them to decide the vision of the company. The product vision will just represent the company vision in another angle
- If you are working on saas b2b enterprise. Things are different. There need to be visibility on what the product team is going to work on during the next 3 years. That doesn't need to be really accurate, but needs to reflect more or less what customers want to hear. There is also a need to know for users facing teams (support, CSM, ...) if a bug is, being worked on, will be at some point, dont care.
In any way, one thing you never want to communicate is a date of release of anything.
A release plan is only needed internally between the close collaborators of the PM: eng lead, product marketing, knowledge managers so that they can plan beforehand things that they need to produce on top of your product
As much as I agree with you, it's better to put on the roadmap for things that you've done recently than what your employees want to hear... After all you don't want your employees telling customers something's coming promising a future that may not come. We all forget that our customers don't even know what we've already done and we can always sell we've already built
> After all you don't want your employees telling customers something's coming promising a future that may not come.
Every companies do that all the time. And there is no way to prevent that. It is impossible to predict 100% accurately things that you are going to build in 6 month
Interestingly there is no product on the markt to collect feature ideas and classify them. Kanban boards etc. Are nice, but if you store many ideas you will completely lose focus.
Ideas, which may or may not be implemented one day have so many dimensions: time required to build it, dependencies which must be built first, usefullness in several aspects, module the software needs to be implemented in and interacts with.
The best i have yet seen was a good crafted excel/airtable with a lot of columns. But deciding which one to build was again not easy as you could not see dependency chains etc.
A couple of solutions seem to try to address this: productboard, ProductPlan, airfocus... There are a couple of more tools to manage feature requests and communicate with customers around them.
I'm also curious to see how these tools will evolve. I haven't used any of them, but from an external POV Productboard seems to have the strongest focus on managing customer feedback and generating product insights, rather than just building and communicating a roadmap.
> Interestingly there is no product on the markt to collect feature ideas and classify them.
As a dev who's been on HN since 2008, I'd be remiss not to "market more" and plug what I've been working on here! I started Savio (https://www.savio.io) specifically to help B2B SaaS teams collect and classify customer feature requests to help inform prioritization.
It was a pain I've felt for over a decade. So after we sold our last company, one of my co-founders and I decided to solve this problem once and for all.
Here's a guide I wrote that lays out everything me and my co-founder know about tracking and using customer feature requests to drive prioritization (we have 40+ combined years of experience PMing and coding at co's like Microsoft, ESPN, 7 startups, and about a dozen consulting clients).
I listened to a podcast with the founder recently and it sounds like they are trying to go more into that direction, which would be a key differentiator if they manage to do it (rather than just providing a tool to manage feedback/build roadmaps). In terms of "deciding what to build", user research tools such as https://dovetailapp.com/ and https://consider.ly/ might be interesting as well. They are just not positioning themselves towards Product Managers (yet).
Ever since I worked in multi stage stochastic optimization I think of strategies in terms of decisions at each nodes of a tree of scenarios. Basically you want to optimize on the long term objective function, and take decisions at the optimal time based on the cost of indecision and the estimated benefits of having more information. Having probabilities associated to each branching in the tree of scenario also makes it have baked in risk management. This is not so easy to apply in practice but it is worth doing and allows having a much longer horizon: else how could you make a strategy with decisions in 6 months not being dependent on the results of the decisions you take now ?
As another comment pointed out, the main goal of product roadmap is communication, strategy is something else. In this case the roadmap could be the most likely path to take in the scenario/decision tree, with diminishing confidence over time based on the probabilities observed.
Multi stage stochastic optimization is often used in finance/trading (e.g. portfolio optimization), I highly recommend to check it out.
A lot of resources on product management are mixing what some commentators are pointing here: roadmap can mean:
1. Communication tool to tell others in the organization (or even outside) what you're planning to build.
2. A framework for your product and/or engineering team that helps you prioritize the work.
This article obviously focuses on the latter. One of the most common mistakes however is that PMs try to use a single deliverable for both.
Yes, there are interesting tools trying to address this but my advice is to study different frameworks to help you think about what your main challenges are - then stand up the process in a spreadsheet as you'll need a lot of flexibility to get to something that works in your specific case. Only then look for dedicated products and choose the one that works best for the process you ended up with.
>Explaining the objectives at a high level in terms everyone understands, then going incrementally deeper to tie these objectives to specific actions of the relevant people.
>Tying revenue to scalability to spinning up Kubernetes nodes to an open issue to a line in a particular file that should be changed is a journey across abstraction levels.
The ones that pop to mind expose what I call "fractal communication": communication that spans across several levels of abstraction that allows people to hook into at the level of abstraction that is relevant to them.
>*- Align everyone: through written communication accessible anytime by anyone. Communication should tie objectives to actions and penetrate several abstraction levels and be consumable by advisors, board members, non-technical people, technical people. Call it "fractal communication" that still makes sense from any abstration level you read it. This enables everyone on the team to chime in at the abstraction level they're comfortable with. You write an email that ties objectives on say, revenues, in a language that speaks to some, and then tie it back to specific activities, an issue in the issue tracker, and a line of code, so that everyone sees how things fit together and are intertwined. Everyone knows what to do and why they're doing what they're doing. They can come up with ideas or correct assumptions or mistakes.
But it ignores the main reason that roadmaps exist: as communication documents to the rest of the organization. This is what I used roadmaps for as a PM for a decade, but it was driven home after talking to hundreds of PMs after founding my fourth company[1] and coaching PMs and product/dev teams to level up for another decade[2].
The real roadmap trap in my experience is that the org takes a roadmap as a promise of when specific things will be delivered. The best approach to avoid this is to not do roadmaps. But that’s also unrealistic for most orgs. The next best approach is to show the org short-term work that will definitely get done, and caveat the heck out of anything longer term. I’ll happily commit to 6-8 weeks out, tentatively commit to 10-20 weeks, and add large asterisks to anything longer than that.
1- https://www.savio.io
2- https://www.Reemer.com