Product Roadmap: List out Epics or User Stories?

Or should we be asking ourselves a different question?

I received a question about the level of detail in the Product Roadmap and whether user stories should really be used in a roadmap; and if so, would this not contradict the Teresa Torres quote of:

We need to let go of the idea that we can enumerate a list of features that represents what we’ll do in the future. This idea is absurd. Rather than sharing feature lists with the rest of the company, we should be communicating how we will make decisions. — Teresa Torres

This is a great question, so I’ll do my best to address this in a short post.

Response: It depends… #sorrynotsorry

Like all product answers: it depends. It depends on how much product scope you have in your Area of Responsibility, how complex your product area is, and how your roadmap is being used in relation to other roadmaps perhaps at a wider organisational level.

In the end, you'll need some sort of articulation of the value you are delivering, and what it translates to in some usable feature. My point in my previous article is that you describe your value increments in a way that suits your audience; not just to list out all the feature requests received without proper prioritisation and evaluation of whether those features are aligned to your strategic objectives

For us in Littlepay, our external-facing Product Roadmap is higher level, composed of Epics across multiple teams (squads, units, vertical teams, whichever term you'd like to use). Individual teams have their own detailed roadmaps and release plans at the user story level that drive the wider Product Roadmap accessible to customers and partners.

We have this external-facing higher-level presentation view that is different to our more detailed view that contains themes, objectives, what and why. The reason for this is due to the complexity of the product increments that we need to build for our stakeholders and the sheer size of the product portfolio. We didn’t want to bombard external stakeholders with too much text given the width of the product portfolio.

You could take this same approach, or simply take the approach of presenting your roadmap as a list of user stories (focussing on the outcome and value delivered) as part of a roadmap. Up to you, your team, and the audience that you’re building the roadmap for.

While I can’t give you a sample of the roadmap, here’s an example from ProdPad that we’ve based our format on, which presumably has a Product Manager or Leader as their end-customer:

ProdPad’s Public Roadmap as per this link

Hope this helps clarify! Happy to discuss further on Twitter too.

Head of Product @ Littlepay | Writing memos on Product, Leadership, Startups, and the Mind |

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store