The secret behind meaningful product roadmaps

I gave a talk recently about how I’ve been using data and analytics to guide my decisions in product management. I’ve edited the transcript a little and split it into bite-size parts for your entertainment. This final bit tells the secret behind meaningful product roadmaps. The previous bit was about the benefits of open and transparent data.

What is your roadmap focused on? #

I bet that most of your roadmaps – these are the plans you have for your product, what you’re going to do in the next quarter or next few quarters – I bet that at the moment your roadmaps probably have items along the lines of “we’re going to build this feature” or “we’re going to add this capability”.

Guess what? If you’re doing that, you’re still probably focused on outputs, not the user outcomes.

When you put anything on your product roadmap, or in your backlog of user stories, in particular product managers should always be able to say why that is in there, what purpose it serves, how you’ll know it’s been successful, and most importantly be able to point to the evidence that drove the decision to put that feature in or build that particular product.

Each roadmap item is an experiment #

So when you’re thinking about roadmaps, you really need to be thinking about what the user is trying to achieve (based on your user research, of course). Treat each roadmap item like an experiment. Remember:

data or user research suggest that this is the case …

so if we try this …

and measure that …

then we should see the following change …

Every roadmap item should follow that pattern. You should be able to know what success looks like from the user perspective as well as what finished looks like.

This is great for a few reasons.

Zero-benefit roadmap items #

If you’re the person looking after this product roadmap, it helps you remove items from your roadmap that don’t benefit anyone at all. If you can’t point to an item and say why it’s there, why it’s important, how it benefits people, take it off your roadmap – don’t do it.

There’s no problem with putting something in to make life easier for your product support teams, or to make it easier for you to instrument and provide analytics in your product. Those internal users are perfectly valid users as well. But the point is, whether it’s an external user, your customers, or internal users within your own organisation, everything on your roadmap needs to be there for a reason.

More learning and iteration #

The second reason why you need to be able to point to this more analytical way of running your roadmap is that it sets you up for learning and iteration. Because every time you run an experiment, if something comes back with a different result to the one you were expecting, the next thing you should do is find out why, and then use what you learn to do it better next time.

Avoid being sidetracked #

And then thirdly, and this is a really useful one, particularly for product managers, but also for people up and down the organisation. If you’re trying to align your team towards a common goal, it’s very easy for teams to get sidetracked and pull in different directions if all you’re bothered about is outputs – building widgets and features.

But if the discussion is centred around helping users to achieve their goals, then it’s much easier to judge whether something is worth doing.

Ask yourself “will this roadmap item get us closer or further away to what our users are trying to achieve?”

So on that basis, if you’re focusing on building things that provide a user outcome, your user stories should align with your roadmap, your roadmap should align with your team’s objectives for the quarter or year, and your team’s objectives should align with your organisation’s overall goals.

What that means is that from the very granular bit of what we’re going to build today, tomorrow, next week, it’s always aligned all the way up through to what the organisation is trying to achieve this year, next year, in five years’ time. And in particular, product managers are responsible for ensuring that alignment, from those user stories all the way up to the company objectives, is happening within that team.

Teams align to user goals #

So my last takeaway is that measuring user goals will help you to align your team much more easily, because they’ll care about what the users are trying to achieve. It’s a human thing rather than a feature or widget thing.

Summary of the talk #

Okay, so just to summarise the main takeaways again:

we talked at the beginning about how assumptions translate into risks for your product and that’s usually because you think you know what in fact you don’t actually know for real;

and we talked about the fast system of thinking that jumps to conclusions and the slower system of analytics we need to engage;

we talked about government, the old way and new way of doing things by putting user needs first before government or before organisational needs;

and we talked about focusing on human outcomes, what it is that users are trying to achieve, not outputs like building widgets or features or that kind of thing;

and lastly we talked about how measuring these outcomes, these user goals, can actually really help to align your development teams, your product teams, and your broader teams within your organisation, all the way up from those granular bits and pieces you’re creating all the way up to your organisation’s longer term goals.

So those are really the five key things I hope you’ll take away from this talk about data and analytics in product management.

That’s it! Thank you for listening.

Agree? Disagree? Join the conversation: