Slow Teams and Failing Features: Tackling Roadmap Challenges
Roadmaps work. If you can estimate impact and work well.
Roadmaps are often criticized as “more dream than plan.”
The issue usually is one of two types:
- Type 1 — Slow Teams
- Type 2 — Failing Features
Let’s break down each:
Type 1 — Slow Teams
↳ “We won’t be able to achieve any of our plans”
↳ “Most of our items will take longer than expected”
Type 2 — Failing Features
↳ “The majority of our A/B tests will fail”
↳ “We’re won’t get close to the impact we assumed”
Both of these types of Roadmap Risks can’t be eliminated.
But they can be reduced.
Here’s how:
Type 1 — Slow Teams
- Invest in reducing your tech debt
- Get engineering to care about product release velocity
- Improve review processes to reduce all complexity in the code base
Type 2 — Failing Features
- Become better at impact sizing
- Invest in rigorous user research invalidation of designs
- Empower teams to react to new learnings on the fly without approval
“But impact sizing accurately is impossible”
→ Perhaps for some products.
→ But not for more mature products.
→ I wrote more about impact sizing here.
“But roadmaps are going to be inaccurate.”
→ Roadmaps shouldn’t be commitments.
→ Instead, they should be communication tools.
→ I wrote about advanced roadmaps and how to develop them here.
The biggest driver of roadmap use is leadership and cross-functional communication.
It shows that you, as a PM and product team, have a POV. That you have done your homework.
I’d love to hear from you.
Do you not use a roadmap?
I’d love to hear from you in the comments.
