Roadmapping at FutureLearn Pt 4: Collaboratively developing Roadmaps

In the fourth post in our series ‘Roadmapping at FutureLearn’, Senior Product Manager Laura Kirsop shares how to ensure the expertise and energy of the people in your team is channeled towards solving the right problems.


Before you read this you might want to read the previous three posts:

Post #1 Introduction to Roadmapping looks at the basics of roadmapping, how we use them at FutureLearn and how we’re organised as a company.

Post #2 Defining the Problem Space is about getting to know your users and turning their problems into opportunities.

Post #3 How we prioritise at FutureLearn is about making decisions through collaboration.


In any company there are dozens of things that you could work on, having a roadmap ensures you are working on the right things, in the right order. I think of it primarily as a way of ensuring the expertise and energy of the people in my team is channeled towards solving the right problems for our users and business.

A team that feel ownership of the roadmap and fully get behind it is usually a happy and productive team. Working in a team where this has been achieved is a pleasure — there’s enthusiasm for what you’re working on, a good understanding of the problems you’re trying to solve and challenges are made based on research and evidence rather than reckons. In short, a good roadmap can equal good progress and a good impact on the world.

The company environment

In order to reach this product management nirvana, the environment of the wider company has to be right. For me, the ideal environment to work in as Product Manager has four key characteristics:

  1. You are trusted and encouraged by the Head of Product and other senior members of the company to develop and own a roadmap for the business or an area of it
  2. Senior staff understand that product development focussed on meeting real user needs ascertained through research and analysis will be most effective for the business
  3. You are working with a team that buy into the product vision and are motivated to meet KPIs
  4. Everyone trusts that your prioritisation process will mean you are focussing on the right things for your users and the business

Creating your roadmap

If you’re working in this sort of supportive environment then the collaborative process to develop a roadmap can be relatively simple. You could, for example, follow this set of steps:

  1. Ensure people in your team are leading or involved in ongoing exploratory user research, insight gathering and data analysis so they have an up-to-date understanding of what your users are doing and what they need from your business
  2. Hold a workshop to decide your team mission and metrics to measure your impact — come up with something that everyone gets behind
  3. Run an ‘opportunity mapping’ session, as detailed by my colleague Reema earlier in this series
  4. Decide the approximate importance of opportunities through a prioritisation workshop with the team, as detailed by my colleagues Polly and Harriet in the previous post
  5. List the opportunities, in order, to create the roadmap (using your tool of choice — we use Trello). Then give your team the chance to discuss it, critique it and then adjust it based on what they say
  6. Regularly review the roadmap with your team — does this still feel right? Have we learnt anything that changes our prioritisation? How are you feeling about the next piece of work?

What can go wrong?

When creating and working with roadmaps, things go wrong all the time but this is okay! Here are three common issues I have experienced and what I did to overcome them.

One: Your boss is getting in the way of you creating and managing a roadmap

There are many reasons that this happens. In my experience, it’s happened when a company is growing quickly and someone who is used to being very hands-on is struggling with relinquishing control. At best you have someone to work with very closely on your roadmap, at worst you don’t feel you have the power to make a decision without asking for their permission. When there’s a bit of a power play going on it’s really hard to involve your team in the way you should because you’re too concerned with what one specific person thinks. Your team may also be confused about who is calling the shots.

I think the easiest way to tackle this is head on by articulating clearly what you expect to be able to do and how you expect to be able to do it to…. Involve your boss as a stakeholder in your process along with everyone else and make sure they feel heard. You will earn their trust and eventually they should back off.

Two: There is a culture of people pushing for (or working on) their pet projects

If people aren’t behind the concept of making decisions based on opportunities identified through user research and other insights then ideas and solutions reign! In most places ideas and solutions are abundant and one of the jobs of a product manager is to manage ideas (and the expectations of the people who have them).

If you don’t listen to people’s ideas and give them time to explore them then the risk is they feel unheard and unmotivated. If you listen to them too much then your collective energies might not be channeled in the most effective way towards your mission and metric. A conundrum for sure, so what’s the right balance?

Some companies have ‘off roadmap’ time to encourage innovation. For example, Strava have ‘Jams’ and many companies have ‘firebreak’ sprints outside of the usual cycle where employees can work other projects (that still match with the overall product vision). We’ve experimented with these at FutureLearn but I, personally, think that innovation should take place every day, as part of your regular ‘on roadmap’ work.

I think the simple way to do this is to ensure that every time you start working on a new roadmap item the whole team is involved in coming up with ideas and experiments to explore this opportunity. You can use simple ways to prioritise ideas and experiments (dot voting is my favourite) that ensure you are working on things the majority of the team agree with — this means you’re pulling together on ideas rather than apart.

The team dot voting.

Three: You don’t have the resources needed to do exploratory user research or data analysis

This is something I am currently struggling with. My team is a client facing team and so we often have work to deliver to a deadline. This doesn’t afford us much space to step back and think about what our users really need. When we did our first session to map out the problem and possible opportunities, we largely relied on insight relayed to us by our business development team about client needs rather than actually speaking to them or their end users.

This pained me at the time because I felt like not having primary data undermined the credibility of the roadmap we were creating. How could we be sure we were doing the right thing? Would people get behind it? Now I’m a little more chilled about it as I realised it was the best we could do at that moment, given the constraints we had on our time and the expertise available to us.

In order to resolve this I have ensured that I take any chance I get to speak directly to our clients and have added anything I discovered as a result to the opportunity map. We have also made a bid for some data scientist and user researcher time to do some exploratory research which will ensure our opportunity map gets further refined and more accurate in the near future.

In conclusion

Collaboratively developing roadmaps with your team isn’t as simple as a set of steps to take — it relies on having the right product culture and company environment but as a Product Manager you can influence and help to create this culture.

Your best tool as a Product Manager is always information about your users and what they need. Make the time to find out what your users need, ensure everyone in the team understands this and the rest will follow.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.