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.
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).
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.
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?
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.
Curious to hear further thoughts from you!