|
|
|
|
|
|
by kareemm
1972 days ago
|
|
|
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. 1- https://www.savio.io 2- https://www.Reemer.com |
|
|
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!