Roadmapping at FutureLearn Part 7: Roadmaps for Product Leaders

FutureLearn
FutureLearn
Published in
9 min readMar 7, 2018

In this final post in our series ‘Roadmapping at FutureLearn’ Matt Walton, our Chief Product Officer, talks about the role of the product leader in creating product roadmaps. But before you read on you might want to read the previous four 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.

Post #4 Collaboratively developing roadmaps is about ensuring the expertise and energy of the people in your team is channeled towards solving the right problems.

Post #5 Maintaining focus and momentum with OKRs is about keeping your focus after you have your roadmap

Post #6 Communicating roadmaps is about how we communicate roadmaps to our learners, partners and internally.

There’s much written about the process of creating product roadmaps, not least the six great articles written by my own team in this series. But there’s surprisingly little written about your role in the process as a product leader.

I believe the actions of a product leader are all too often the root cause of a “bad” roadmap. Without thoughtful leadership around them, it may not be in product manager’s gift to achieve a “good” roadmap. This is because product leadership is genuinely a hard thing to do and quite distinct from the job of a product manager, something that is often misunderstood.

I would define a good roadmap as one that the team understand and feel ownership over, includes the right problems that are driving the company strategy and is useful to both those in and outside of the team.

This article captures my reflections on your role in ensuring that your team is empowered to create good roadmaps.

1. Ownership

Perhaps the biggest mistake you can make as a product leader is believing that you should ultimately own the roadmap(s). Is can easily happen if your role is changing and you’re becoming less hands on in a rapidly growing startup or simply if you’re new to a leadership role.

And it’s not just a mistake made by those in product leadership role, it can equally apply to founders, CEOs and other members of the leadership team. Their ideas about ownership can add complexity to how you perform your role as not only do you need to avoid falling into the trap yourself but you need to make sure others are not doing so or pushing you into acting in this way.

Here’s why you should avoid getting hands on in the process of creating the roadmaps, beyond the important job of inspiring, coaching and challenging your team.

In order to deliver the right solutions to problems, your team needs to understand them and feel motivated to solve them.

The collaborative process your product managers and their teams go through to define the problem space and prioritise the opportunities is as valuable as the roadmap that emerges from the process.

The team also has more time than you to understand the potential impact of different candidates. They are typically closer to the users in order to properly understand the nuances of potential problems and solutions.

A roadmap that is either handed to them or where they only feel like a contributor and not the owner will inevitably lead to less good solutions. They’ll have a more limited understanding of the problem and might be less motivated because they may not be convinced they are spending their time on the right problems.

Not getting hands on is really hard, particularly where you see roadmaps being created that are very different from what you would do yourself or you are under pressure to make sure something specific is included. But direct intervention should be avoided wherever possible for the reasons above.

So as a product leader, if you’re hands off in the creation of a roadmap, what is your role and how do you make sure that your teams are creating good ones?

The ‘agile onion’ and which layers you as a product leader should be in.

2. Purpose, Vision, Mission and strategy

In order for your team to create effective roadmaps that drive the business forward, they need to understand the context it exists within. It’s your job to interpret the company’s strategy into something useful for product people and make sure they understand it.

As a product leader, you may be involved in defining the purpose of your company or responsible for the vision for the product, or it may be something that is already set. Whichever it is, your job is to make sure that some kind of “north star” exists, is supported by the rest of the leadership team and that your team understands it. This is important to ensure that any plans they create are ultimately driving towards the same shared goal. You need to keep telling the story of the product and showing how what people work on every day is driving towards this goal.

At FutureLearn we have a purpose (why we exist), a vision (what we’re aiming to create) and a mission (how we’re going to do it over the next few years).

Our purpose and mission at FutureLearn

Under this mission sits our company strategy, which we typically revisit every twelve months. The strategy sets out the things we need to do over the next year to move us closer to achieving our mission. This year, we have six strategic objectives.

An example of one of our strategic objectives is “Grow the number of Advancers (learners whose motivation is to advance their career) who will pay for an aspect of a course or qualification”.

There’s lots of approaches to vision and strategy that you can take but the important thing is to make sure that these things exist and are understood.

3. Team organisation, missions and metrics

As a product leader, the biggest impact you have on product roadmaps is how you organise your teams and define their missions.

From very early on at FutureLearn, we started to organise our product teams around our strategic objectives, with a cross functional team working towards each objective, rather than on a specific set of features or part of the product. We have found this successful as it focuses the team on the impact that they are creating rather than the features they build and maintain.

Each team’s mission mirrors the strategic objective. In addition to this, each team has a metric that is their key measure of success. For the growth example above, we measure the number of course enrolments and have a monthly target to drive towards.

As a product leader, the definition of the mission and agreement with the team about how you will measure success is one of the biggest levers you have to guide what the team will work on. Getting this right is worth time and effort and it will make things more straightforward later on if you want to challenge what the team are deciding to work on.

This approach has been successful enough for us to adopt it beyond the product part of the organisation. Now the majority of the company, including people from marketing, business development and content disciplines come together into cross functional teams alongside product managers, software engineers and designers to work on a shared strategic goal.

A cross functional team at FutureLearn.

This highly collaborative and matrix approach has its own challenges — as a product leader you need to work closely with others in the leadership team to arrive at ways of organising and defining missions that work not only for product people but the rest of the business too. This may require some compromises and certainly requires you to be empathetic, diplomatic and tenacious.

4. Creating alignment and encouraging communication

At FutureLearn, we organise to optimise for speed by giving cross functional teams autonomy. Once the team has a mission and a metric, they are broadly free and empowered to achieve this in whatever way they see fit.

This means that another key leadership role I play is ensuring alignment between teams, encouraging communication and looking out for the coherence of the overall product portfolio.

When we first moved to ensure that the product managers owned the roadmaps (rather than me), this autonomy extended to when the roadmaps were reviewed and how they were presented.

This led to a situation where they were extremely useful to the teams themselves but with every team taking a similar but different approach, became quite confusing and less useful to others across the business. It was hard for others to plan and coordinate the impact of changes across teams. This resulted in ultimately, the roadmaps not achieving two of their key purposes: clear communication of what we’re working on and stakeholder buy in.

How did we fix this? By aligning the roadmap review process for all teams with our quarterly business planning process and enforcing a standard approach to to what we meant by “now”, “next” and “later”. We also agreed a consistent way to manage and present them.

This also gives the product management team the opportunity to share their developing plans with each other for me to provide some high level direction as context for planning.

Other important ways we achieve alignment is by encouraging teams to attend each others sprint reviews, running a fortnightly product management team meeting and making sure that key things are presented to the company at our monthly all hands meeting.

5. Coaching your team

One of the other big impacts you can have on roadmaps is through how you coach your team. Wherever possible, it’s best to resist the urge to tell members of your team what should be on their roadmap. It’s unlikely to be productive for the same reasons outlined above.

However, it is your role to keep asking them good questions, push them in the direction of key pieces of insight or research, highlight relevant things other teams are working on, help them think about the bigger picture, give them the benefit of your fresh pair of eyes and challenge any woolly thinking where their plans are unlikely to deliver on the agreed mission or are in conflict with the company purpose/vision.

There’s lots of ways to do this, via 1:1s, sharing documents, encouraging them to connect with others etc. And this should be a constant process not just when they are reviewing their roadmap.

6. Creating a product-friendly culture

Finally, to successfully achieve much of what I have talked about above requires the company to have a “product-friendly” culture. Your other key role in helping ensure good roadmaps is cultivating this. What you will need to do here will depend on the organisation, who the people in senior positions are and how they are used to working.

Typically this involves establishing buy-in of the principles of a roadmap driven approach, encouraging everyone to focus on the results we want to see, rather than the things we think should be built, working with others in the leadership team to agree a clear set of strategic priorities and providing the teams with protection from leftfield requests. To do this, Business Development is an area you may need to get more involved in.

Knowing what questions to ask to understand what’s in your CEO’s and other key stakeholders heads is also a valuable set of skills to focus on developing. In general being honest with them that this is what you’re trying to do is probably the best approach and this gives them the opportunity to talk about their expectations.

Encouraging your team to relate successes and achievements to what was planned on the roadmap will also help to establish, reinforce and maintain trust in the process. Essentially, constant communication and celebrating success is often the key.

Your role, in summary

In practice, every company will be different and will present someone in a leadership role with a very different set of challenges around how you help your team develop roadmaps.

However, wherever you are, remember that your role is to:

  1. Make sure your team owns their roadmaps.
  2. Ensure that there is a clear strategic context to inform their work and that the missions and success measures of the teams are clear.
  3. The process, framework and cadence for roadmapping is consistent, understood by your team and bought into across the organisation.
  4. There are processes in place to encourage communication and collaboration across teams.
  5. Your team is inspired, supported and challenged appropriately.
  6. Cultivating and maintaining a “product-friendly” culture.

If you’re able to do all of that, you should find that your teams naturally create good roadmaps and, equally as important, are passionate about delivering them. Ultimately, it’s what ends up in the hands of the end user that matters.

We’d love to hear how other companies approach their roadmaps, so please do share your thoughts and own experiences in the comments below.

--

--

FutureLearn
FutureLearn

Changing millions of lives with online learning at futurelearn.com. On here talking about building digital products, coding, education and more.