Building your Product Roadmap

Image: Unsplash Will Langenberg

One of your most important tasks as a Product Manager (PM) is the construction and prioritising of the Roadmap. The Product Roadmap is your company’s future direction: get it right and you deliver something that sets you apart from your competitors, get it wrong and you have wasted a years worth of time and effort.

Common issue with roadmaps;

1. They are simply a wishlist of features.
2. They have ridiculously specific deadlines (seriously how can you commit to a delivery date 18 months away on an item that hasn’t yet been scoped),
3. Leaders feel very comfortable with gantt chart planning (waterfall) which in theory is great but doesn’t work for roadmap planning.
4. They don’t reflect any value to the user — features do not equal user value.
5. They do not allow periods for iteration so are therefore not agile.
6. No one really knows what the right thing to build is.

So why does this happen? To start, outside of product development no one really understands what agile means. Also, you find leadership teams are programmed on fixed things, like how much revenue was generated this quarter, and find it hard to digest abstract concepts required for delivering a roadmap.

Fact finding

Before you can even think about a single user story hitting your backlog, let’s get the basics sorted.

• What problem are we solving?
• Who are our key users?
• Where is the product today, where do we need to be (this is both product market fit but also technical fit i.e. technical debt — this will have a big impact on future decision making).
• Business purpose — who we are where we want to be, how we want to be viewed in the industry (this needs to come from the founder or the leader of the business).
• Identify problems customers face doing their job (not necessarily just with your software)
• Understand your User Journeys
• Personas (if you still use these)

I like the ‘Jobs To Be Done’ framework for this fact-finding work. If you have not used it I would highly recommend it.

Alignment

Once you have completed the Fact Find you need to set your stool. Start with your Product Vision, this is really useful as your guiding principle. It allows you to ask

“Does the next great feature request help us achieve our Product Vision?”

Working in Product you have many important metrics that you track and report on. The roadmap is no exception. Your roadmaps is what you will be judged on and how you will succeed in achieving your key numbers. Furthermore, each deliverable item on your roadmap will come with its own set of metrics which will help you understand if it has been successful or not.

I’m a big fan of having a North Star Metric although this is not easy in large businesses. This is the most important number for your product. The reason I like this is that it provides clarity when you potentially have a lot of conflicting requests. If it is clear what number drives the product, it’s easier to decide what you choose to focus on.

Themes

The purpose of the Fact Find is to uncover problems that you can solve. These problems will be the cornerstone of the themes of work that you will adopt. A theme-based roadmap is much more powerful than a feature-based roadmap, as feature-based roadmaps are very rigid and have often come from stakeholders coming up with quick solutions.

A theme-based roadmap is problem centric, allowing for creativity on solutions. Let me give you an example. If I had a feature “Export data” as a roadmap item, then when it comes to discovery and scoping, I would only ever create a mechanism to export data. The problem may actually be ‘users cannot get the reports they need from the data they have’. This problem may be part of a theme called Insights. You may well end up exporting data but you might decide to build an Insights suite into your software which adds real value to your users.

Note, the Product Manager’s role isn’t to come up with all the solutions. The Product Manager needs to deeply understand the problem/challenges and work with a team to come up with solutions which can be validated and tested. When a solution is added to the roadmap that hasn’t been through this rigor it is most likely either a customer request, i.e. a solution they think will solve their problem, or it has been dictated by a senior manager. Both instances would be cause for concern.

Duel track roadmap

I mentioned earlier that you cannot accurately plan long term deliverables. Why is this? Firstly the item is unlikely to be scoped and secondly business priorities frequently change. I use a tool called Prodpad and love the 3 buckets that they have for roadmaps: Now, Next, Future.

Now: currently being developed — items currently in development rarely change.

Next: the next project that will enter into development, these are unlikely to change. Next items should be currently in the discovery phase — this is why we dual track, a delivery track and discovery track both of which happen at the same time (but obviously for different things!).

Future: — all your themes/projects listed in order of priority as of today. You cannot commit to any of these because they are highly susceptible to business change.

Communication

Although the Roadmap is owned by Product it’s the direction of your entire organisations and requires substantial stakeholder buy-in. When we went through the fact find earlier it’s key to ensure that you have engaged with both the right people and enough people.

I like to start with the founder. The founder will give unique insight to the initial problem that the software/company was trying to solve. Next is your current business leader, CEO, President etc. This person will tell you where they see the company going in the near and mid term. After the CEO I engage with the users (see fact find above) and finally other internal stakeholders, Sales, Marketing, Customer Success etc.

Through the fact find and themes you will have a clear idea of what is and isn’t important.Like selecting a sports team you will have some disappointed stakeholders. Managing expectations and prioritising is probably a topic for another blog.

Final thoughts

Ensure each large piece of work has follow-up time booked in for iteration. In startup world you can often iterate all the time however, in established companies, when you have more varied deliverables this isn’t always considered, many still have the waterfall mindset of ‘that end of project means that the job is done’. To compensate this book in specific follow up time into your roadmap — (for the agile purists this is definitely an anti-pattern, however, pragmatism will often take you a long way in organisation that don’t yet have the agile mindset.

It’s important to have very clear communication. If something is delayed, call it out. If your roadmap changes, flag it, people may not always like it, but they appreciate being in the know.

Manage expectation accordingly, when a theme is in the discovery phase it doesn’t guarantee that it will move into the construction phase. You may rule it out, or it may be much bigger than you first thought meaning that it will take longer. Customer Success or Sales find it hard not to shout about the next big thing — make sure you are controlling that conversation!

Finally, be passionate about your roadmap, as this is how you communicate all the problems you are going to be solving.