For something that’s in every PM’s job description, there’s still a real lack of clarity out there about what and who a product roadmap is for, and the best way to approach creating and managing one. I’ve worked in organisations where the roadmap was a very detailed spreadsheet with lots of rows – and consequently it was always out of date, which didn’t matter because nobody looked at it anyway. I’ve worked in places where each product team had its own roadmap – with as many formats as there were teams – and in places where one roadmap to rule them all was the order of the day. My own favourite was the one I created at Global, which was sticky notes on a wall which we could move around as things changed, and anytime one of my stakeholders wanted to know where something was on the roadmap, I could point at the wall and get them to work it out themselves. That also meant that the roadmap had to be intelligible to people outside the product team, which is my first rule of roadmapping. Your roadmap is your way of telling your organisation – and, if you’re brave, your users – what you’re working on and what’s coming up. In my view it’s not where all the technical detail or supporting data lives – that sits inside your team systems, where the people who need to get at it can do so, and nobody else needs to try to get their heads around it. The only detail I suggest adding to your public roadmap is the core objective or success measure for each item, so that in one place you can communicate the what, the when (approximately – I know it’s hard not to put dates on roadmaps, but don’t put dates on roadmaps, that is my second rule of roadmapping) and the why of your plan.
I’ve been using a Miro template called “Agile product roadmap”, which does 80% of the job on its own, and I’ve added the other 20% in the shape of the core business objectives, the metrics, and links to the relevant Jira epic, so that for those people who want the detail, it’s very easy to find. I’m using this format with a client who’s at a relatively early stage in the development of their product, so at the moment we’re having monthly roadmap reviews to keep us on track (or to rip everything up and start again, depending on what sort of a month it’s been). It’s light-touch, easy to understand and by including the overall objectives as well as the specific success measures, it makes sure we stay focused on the why, as well as the what and the how.
I’ve anonymised this, which is why it looks a bit generic – but you get the idea:
It’s not quite as much fun as moving bits of paper around on a wall, but on balance I think it’s more useful.
The Product Pathway 