5 best practices for your agile product roadmap
No matter how you choose to represent your agile product roadmap, there are certain standards you just gotta follow.
1. Treat an agile product roadmap as a statement of intent
First thing’s first: approach your agile product roadmap as a statement of intent. (We’ve covered this already.) Treat your agile product roadmap as a living document that can (and 100% will) change.
“From just a mechanic standpoint, making sure you have a roadmap that can actually be updated is really important,” says Ahsan Nanji, Director of Product Management at Electronic Arts. “I’ve seen PMs struggle with creating a plan that doesn’t build any flexibility into it. So you want to — with either the software or whatever process you’re using — be very adaptable to change.”
If you’re too hung up on dates or milestones, you restrict your product roadmap and ultimately set yourself up for failure. Give yourself breathing room, so that way you can sync your product roadmap nicely with the flexibility and changes you’ll experience in an agile environment.
Download our ebook to see some real-world examples of agile product roadmaps.
2. Determine if time is right for your agile product roadmap
When we asked Casey McKinnon, VP of Product at ecobee, about his agile product roadmap best practices, the very first thing he brought up was evaluating the role of time for your roadmap.
“Well, first of all I would consider if time’s a factor,” he says. “If the idea is that you need to hit a specific date, you need to compare that to something where you can put your product out into the world and there are no consequences for when it’s launched.”
Determine how time plays a role (if at all) in your day-to-day function. If it doesn’t play a role: awesome, your product roadmap won’t incorporate time.
Maybe a timeline is for you. Maybe you’re not that concerned with dates, so you want to employ fuzzy time buckets. Or maybe you have a million sprints you need to show on your roadmap. Whichever way you approach time, knowing whether it applies and its particular role in your environment will lead to a more effective agile roadmap.
3. Remember who’s seeing your agile product roadmap and tailor to them
Creating a product roadmap without an audience in mind is pretty useless. The whole point of a roadmap is to communicate and align with your stakeholders. One of the very first questions you should be asking is: who’s going to see this?
“You want to understand your audience first, because they want to see different things,” says Latif Nanji (our CEO here at Roadmunk) when we asked him about his agile product roadmap best practices. “If you’re building this agile roadmap for engineers you can get a lot more granular about information, whereas sales and marketing are more concerned about the ‘what’ and ‘when.’”
Knowing your audiences means knowing what expectations to set; you know who you’re catering to. Imagine a mystery novelist showing up to a romance novel convention, expecting to sell out. It’s not going to happen. Romance novel fanatics are looking for very specific things (i.e. scandalous cover art and tales of unrequited love) that a mystery novelist (most likely) won’t offer.
The same goes for your product roadmap. If you’re expecting to get buy-in from C-level executives, but you’ve created an agile roadmap specifically for developers, don’t expect a very productive meeting.
“One of the worst things you can do is have everyone see the same roadmap,” says Latif.
If you know each stakeholder has individual goals and concerns, you can’t show up to each meeting with the same exact plan. Offer something relevant to them. The result: expectations are managed and stakeholders can feel assured that their needs are being addressed.
4. Know your product market. Like really know it.
This seems obvious. Of course a PM should know their product market! But we’re talking really knowing what upcoming features users want, beforehand. In agile this will change — and quickly. But a strong market knowledge makes your product roadmap much more adaptable to inevitable changes.
Sarah Pyo, Product Manager at Expedia, puts it this way:
“Understanding how your product works technically will help with prioritization, because you’ll know different levers to pull to drive your product. What new, futuristic features can we push out there and what is the demand?”
Recommending a user-centric method to collect market knowledge for your product roadmap, Rahul Kulkarni, Product Manager at Shopify, says:
“Validate low-fidelity mockups with customers as often as possible. Get real feedback and parse out what’s relevant.”
Chances are your market will be disrupted (many times), and as a result, so will your product roadmap. Keeping tabs on users’ wants and needs will prepare you to be just as agile; allowing you to update your roadmap swiftly to reflect any market shifts.
5. Check-in with your agile product roadmap (as a team)
This should be the easiest guideline to remember because it’s a natural outcome of agile. Working in short cycles, you’re immersed in a constant feedback loop. You’re regularly forced to stop and ask yourself, “So what worked and didn’t work this last cycle?”
This introspective (and zen) behavior pushes you to check in with your roadmap often. Your document should always be up-to-date with your product strategy and if you’ve created (and you should have) a living document that can change, it’ll be easy to update to reflect recent changes.
Casey McKinnon agrees with this practice, but emphasizes incorporating the whole team:
“You should continue to revisit your roadmap with your whole team. Don’t let it be an artifact of product, but an artifact of the whole company. This way we all agree, we all bought in, and everyone’s really excited about the roadmap.”
As a PM it’s your responsibility to ensure you’re sitting with your roadmap consistently, but also making sure you’re roping in your team. This way alignment is not only easier, but way more consistent.
Once your plan is planned, use our agile roadmap template to hit the ground runnng.