Building a Product Roadmap That Will Help Your Team Stay On Target
Setting off on a journey without a map is fine, if you’re not bothered about where you’ll end up. If you’re trying to destroy a Death Star, though, then you’ve got to stay on target. The same is true if you’re trying to build world class products.
The problem with traditional product roadmaps is they’re obsolete as soon as they’re written. Agile technology projects are, by their nature, extremely fluid; old-fashioned project management techniques just won’t work.
Why waste hours building complicated Gantt charts if you’re just going to have to rip them up every time your requirements change?
The trick is to bring that Agile mindset to bear during your planning process as well.
Dates Are A Waste of Time
No new product is delivered on time. Ever. If anyone tells you otherwise they’re a liar.
How can you possibly forecast every roadblock, hiccup and product scope change ahead of time and predict, with accuracy, when your product will be ready to go in front of customers?
Deadline dates are always missed, so do yourself a favour; don’t set them.
That doesn’t mean giving your development team free rein to finish whenever they’re ready, though. You’re not painting The Sistine Chapel or building St Paul’s Cathedral. No product means no income for your business, after all.
Instead of setting arbitrary deadline dates that keep on moving, agree a time frame for delivery instead. Flex scope, not time, and make sure you’re getting new product features and improvements in front of people as quickly as possible.
Noah Weiss, Head of Search, Learning & Intelligence at Slack, advocates a Now, Next, Later approach for prioritising deliverables. I’ve tweaked it a bit to meet the needs of my business and now work to the following:
- Current: to be delivered within the next four to six weeks
- Near term: to be delivered in the next three to six months
- Future: to be delivered more than six months over the horizon
This approach makes it really easy for your team to focus on their immediate priorities (Current), what’s coming up in the pipeline (Near term) and their longer term goals (Future).
Link Your Deliverables to Business Strategy
The items on your roadmap need to have purpose; they’ve got to carry you closer to your vision, mission and goals. There’s no room for boring, platform-specific tags here.
I use ProdPad for my roadmaps (I used to use Trello, but ProdPad is awesome) and label my items with one of the following objectives:
- Growth: New products and features aimed at growing our business and/or pivoting into new markets
- Retention: New products and features aimed at increasing the retention of our existing customer base
- Engagement: Improvements to existing features/functionality to increase engagement
- Usability: UX/UI improvements to existing products and features to make them more usable for our customers
- Integrations: Integrations with some of the 3rd party systems our customers use
- Support: Improvements to the way we’re able to deliver support and make that part of our offering more efficient
- Resilience: Architecture and infrastructure improvements aimed at improving the reliability of our existing products and systems
- Other: Anything we’re working on that doesn’t fit into one of the other buckets but still needs to be tracked on our roadmap
It means I can see, at a glance, what the areas of focus are for Product and how my team is contributing to the business. If my roadmap is full of green “Growth” cards for example, then it’s all about building the customer base.
Stick to Themes, Not Tasks or Stories
Stories are for Product Requirement Documents, not roadmaps. Leave the “as a user, I can” stuff for the next layer down.
Your roadmap should be about articulating value.
You already know the strategic impact of what you’re working on; the next step is to think about the value that each item on your roadmap brings to your business and, most importantly, your customer.
Here’s a recent example from our roadmap:
Implement Automated Campaigns (Usability)
- Automate the Email Campaign process and make it really easy for schools to share their projects and ask for donations, volunteers and general support.
Make sense? It’s clear where the value is straight away; implementing automated campaigns will make sharing really easy. Easier than it is at the moment, anyway.
Don’t go overboard with detail here. All you need to cover is the idea and the value it’s adding. You can flesh out the rest with your team.
Keep It Simple, Stupid
Technical jargon has no place in your Roadmap. It should be so straightforward that a brand new user of your software can understand what you’re trying to achieve.
ProdPad and Slack (to name two) have clear, concise public-facing roadmaps so their customers know what they’re up to:
You don’t need to go that far, but it’s worth writing your Roadmap as if you are.
Keep It Up-to-Date
Your product roadmap should be a living, breathing document that you use to steer your team in the right direction. It should be the focus of your weekly meetings and you should review it, in depth, at least once a month.
As a product manager, I’d advocate updating your Roadmap every day with notes / updates on anything that’s moved.
A well thought-out product roadmap will help guide you and your team to their destination, but you’ve got to use it. Don’t just create it and think that’s the job done.