I’ve worked in Agile for 6 years now, having worked in waterfall at Accenture for 5 years prior to that. I’ve presented dozens of roadmaps. But now I’m on a mission to kill the phrase “roadmap”, at least internally, at work. Why? Because roadmaps and Agile don’t mix. Allow me to explain.
Ever presented a roadmap that looks like this?
Of course you have. And when you do, your stakeholders see a Gantt chart/project plan. If you’re using agile, you probably used some rough estimation to come up with the timeline. Yet the visualization makes it hard to convey the uncertainty around the timeline. No matter how many asterisks you put on the slide, they will see this as a project plan.
So your stakeholders see this “project plan.” What do they expect? For you to deliver on it! They judge you, your squad, your parents, your value to the company on your ability to “stick to the plan”. But is delivering features “on schedule” really success? No way. High fives for delivering software features on time/on budget should be left in 2002 with waterfall.
What happens when you’re delayed? When great business opportunities present themselves? When you realize you want to iterate more on something based on feedback? You have to update your “project plan”. Bummer. Everyone was really excited about that thing at the end of your roadmap. Clients were expecting it. Senior execs built revenue projections off it. Someone from customer service Tweeted that it’s coming. Now they’re all scrambling to save face. And they hate you, product manager, for not doing your job!
And you thought it’d be OK to update the roadmap because that’s the point of Agile right?
There are a few alternatives I prefer to the Gantt chart roadmap:
1. Gantt Chart with Buffer
This is a minor tweak to the "project plan" view but at least have some buffer depicted on the roadmap. Perhaps some empty months with a dotted box outline and a "?" suggesting that the teams need to reserve time for things like responding to customer feedback, production bugs, and new opportunities.
2. Kanban Style
Kanban boards are used to show the status of different work items (in the roadmap context, those would be research/validation work, design, or development). You don't have to lose the timeline context on these boards - you can still indicate an ETA for each item so people have a general sense of when it'll be available (I'd use quarters instead of a specific month to provide flexibility). Here's an example Trello board for Chuckwagon, an imaginary app that saves you time in picking recipes to make at home, grocery shopping and cooking:
A couple things to note:
- Ideas are being validated before they go into the design/build queue. In this case, the Group Meal Plan ideas was scrapped because users didn't think their friends and family would want to make the same recipes as them.
- Once released, there's analysis being done to identify whether a change is improving the KPI it was intended to improve. In this case, the Waitlist Landing Page improved the acquisition KPI because it's collecting email addresses of potential users but the social sharing feature didn't, because few people ended up sharing the landing page link via Facebook, Twitter or LinkedIn. By doing this analysis we're able to constantly learn and make sure the focus of the product development squads is on outcomes, not just output.
Microsoft also uses this concept for their public Office365 roadmap, although they don't use the same visual layout:
3. Time Horizons
Here's an example from Slack's platform team that shows items bucketed by near term, mid term and long term, with no specific mention of what those "terms" mean.
I like the Kanban style roadmap myself, because it provides a quick view of what's happening in product development but doesn't lose sight of outcomes and learnings.