Alice: “Would you tell me, please, which way I ought to go from here?” 

Cat: “That depends a good deal on where you want to get to” Alice: “I don’t much care where –” 

Cat: “Then it doesn’t matter which way you go”

Alice in Wonderland, Lewis Carroll

 

Today we’ll discuss the basics of how to approach a product roadmap.

Now, if you read my post about the ‘Product Management Spheres of Responsibility’ then you know that the ‘sphere’ of the product roadmap lies between the product strategy and the quarterly planning. Hence, to start with – in order to have a product roadmap that makes sense for your business you need to have some product strategy in place, or otherwise the quote from ‘Alice in Wonderland’ will apply to you as well…

Wait, what is a product roadmap?

Right. Just so we’ll be aligned, let’s talk for a second about what is a product roadmap? Well… there are plenty of definitions out there on the web, but at the end of the day – the roadmap is a plan on how to execute the product strategy.

In its simplest form – it’s a list of high level features scattered over a timeline. But don’t be confused – although it may sound quite simplistic – it’s not. The features you choose to put on the roadmap and their timing matter a lot.

 

Ok… what type of features should be on the roadmap?

Because the product roadmap lies between the product strategy and the quarterly planning – the granularity of the features used is higher than the product strategy but lower than the quarterly roadmap.

Here is a short checklist that will help you classify which items belong:

1. First – put all the features that are directly correlated to accomplishing the strategy. Those are the key items.
2. Add infrastructure stuff that without it – you won’t be able to build the key items.
3. Add features that were mentioned in the past by your executives that they would like to see in the roadmap and you didn’t manage to convince them to do without (yes… those always exist whether they support the strategy or not)

 

And for the avoidance of doubt – the following items don’t belong (it doesn’t they mean shouldn’t be worked on though):

1. Tech debt items which are not ‘big’ or ‘fundamental’
2. Small features (that although needed, are not directly correlated to the strategy)
3. Infrastructure improvements that are nice to have

 

Now, this is important – the above is just a filter to classify which items belong and which don’t. There are some features that belong in the roadmap and are still unknown to you without further analyzing the strategy and the timeline.

 

Uncovering the hidden features

In order for you to understand what are the key items which are missing on your roadmap it’d be very useful to divide the planned roadmap to ‘chapters’ given the timeline. What do I mean?

 

Dividing the timeline to chapters

Have a look at what the company is trying to accomplish and where it wants to go. You need to pave the road.

Analyze the gaps. How far is the current state of the product from where it needs to be in the time frame defined by the strategy?

If the strategy was well defined then the gap is probably quite big. Therefore – try to break it down to virtual ‘stages’.

‘On stage 1 (probably the end of next quarter) we’ll need to have these capabilities.’ 

‘Right after – the main focus on the quarter should switch to provide ‘so and so’ capabilities’.

And so forth.

Don’t worry – I’ll provide a concrete example in a minute (or two).

But anyway – each of the stages you come up with can be described as a ‘chapter’ and you can provide it with a title, such as ‘Basic sellable product’, ‘Product market fit’, ‘Self service’ and so on.

If you are unsure when to start, then sometimes it makes sense to start from the end. Define the end goal in terms of the product very clearly and ask yourself – ‘Ok, if this is where we want to be in X years, then clearly a quarter or two before, we must be at this stage at least’. And work your way to the present from there.

It’s ok if what you come with has much more certainty for the next couple of quarters and become more vague after that. That’s normal, as no one has a crystal ball and reality is totally unpredictable. But at least you have a plan which has a consistent logic behind it and theoretically leads to the realization of the strategy.

 

Now, breaking the timeline to chapters should have helped you to uncover missing features and/or capabilities that will be required along the way.

Note that I used a lot of the term ‘capabilities’ and not necessarily features, because on product roadmap – it’s ok to include items which are described vaguely, especially as you are getting farther into the timeline.

 

Fine tuning your features list

To make sure you didn’t miss anything – run the following drill:

Go over all of the product aspects and see if it’s covered at all of the stages. For example – go over the UI/UX, infrastructure, backend logic, workflows, integrations and so forth. How each of those aspects will need to be evolved over the time to support the product, sales, automations and the overall ‘chapters’ you named?

 

Ok. So by now you should be fine in terms of features/capabilities completion.

Did you forget anything?

Of course. But no one can see the future so you’ll adjust as the time goes by.

 

Validating your roadmap

Validating the features/capabilities

How should you know the list of chosen features and capabilities is good enough?

The end result should items which are:

1. Easy to grasp to anyone from the executive team. If they don’t understand what the feature is about then either you need to phrase it better or it shouldn’t be there at all (probably too grained).
2. Explainable. You should have a strong case as to why the item is there, and why it would be hard to make progress on the strategy if the item is not there.

 

Validating the timeline

Show your peer from the R&D (the leader you are working with) your suggested roadmap before showing it to anyone else. What does he think about the timeline of the deliveries? Does it make sense? Does it sound reasonable to accomplish given the current workplace and planned hiring? Would he feel comfortable committing to such a roadmap if asked by one of the executives?

If there is a lot of infrastructure work involved – it might be worth showing also to someone from the dev-ops or the QA.

 

Validating the completeness of the roadmap

By now you should have the confidence that all items belong in the roadmap and that timeline makes sense. You also got general feedback from R&D and maybe someone else.

The next step is to show it to your superior and you’ll need to prepare the story as to how working along this roadmap will fulfill the vision the strategy has outlined.

If you are still feeling a bit insecure – consult someone you trust. Maybe another product peer who is experienced with working on roadmaps. Get their feedback and make changes if needed.

It’s important to show it to your superior when you are confident enough so you’ll get their buy-in.

Present it to your superior. Get their feedback. Make adjustments.

Feels good?

It’s time to present it to a broader crowd and get the full buy-ins and then commitments. Good luck!

 

A concrete example

Let’s say you are working in a company which produces mobile games. At some point the competition in the app stores becomes too severe and the company decides to shift some resources to a new product – digitization of board games!

Congrats – you are assigned as the head of product!

The VP product asks you to come up with a roadmap. You ask about the product strategy and the VP product replies:

“Within two years we’d like to be in a position where we can transform any board game to a digital mobile app within a couple of months. By then we should have several such games in the market so we can test the waters, process the feedback and adjust if necessary.”

 

Ok. That’s a strategy. Nobody knows if it will work, but let’s assume that your VP product has done proper market research. Obviously, they managed to convince the executives to approve allocating resources to this project. 

Of course you should do your own research and be even more knowledgeable than your VP about this since you are the head of product – but this is not what this post is about. So let’s focus on the roadmap:

Here is what I was hearing:

1. The timeline is for two years
2. The roadmap must include a validation phase
3. By the end of the process we should have some kind of platform that helps facilitating the process of transforming board games to mobile apps
4. I always recommend before rushing to implement a platform to implement one or two single cases that the platform should have handled if it existed. It will help you design a platform which is more generic. Therefore, I’m hearing here that we’ll need to release a couple of games before working on the actual platform.

 

I interpret this as two very busy years.

 

Let’s make chapters out of it and I’d like to start from the end:

1. The last quarter must be about finalizing the platform including all the testing. In order to properly meet the goals we need to be able to actually produce a game within a couple of months. Hence – the platform must be ready in the quarter before and merely be tested at the beginning of next quarter and immediately utilized to produce the first game using it. We’ll therefore can come up with two chapters:
   1. Last chapter – ‘releasing the first game using the platform’
   2. The chapter before – ‘completing the platform’
2. The couple of quarters before would be devoted to building the platform with all the knowledge we acquired. Therefore we’ll call it ‘Building the platform’.
3. So far we spent one year. It means the second year is devoted to building the platform and releasing its first game and the first year would be about creating a couple of games and getting the feedback from the market. Hence I’d go with these 4 chapters (ordered in backward calendar order):
   1. Chapter 4 – ‘Applying learnings and designing the platform’
   2. Chapter 3 – ‘Working on the second game’
   3. Chapter 2 – ‘Releasing first game and gathering feedback’
   4. Chapter 1 – ‘Working on the first game’

 

Hence, we have 7 chapters spanning over 8 quarters. This is an ambitious plan as there is not enough room for mistakes and iterations. This is something I’d certainly take to the VP product to discuss, but you have your skeleton.

As you can see – you know how you start (picking an easy to digitize board game and build it) and a lot of certainty comes later down the road. The first game may actually be a total failure and in that case you’ll need to figure out whether the choice was wrong, the marketing plan sucked or there is no market (there could be other reasons, of course). It could be in that case that the whole project will be scrapped. 

But let’s be success oriented – 

Your next step is to write down the high level features that will be needed for each chapter.

Since you still haven’t chosen your first game then there are many unknowns even in the first quarter. I’d work to minimize those by doing research and making a decision about the first game and making it known to your superior (we are going to come first with this game because A,B and C). Get their buy-in and then you can work your way into the details of the coming quarter.

The last chapters about the platform can stay as titles as very little is known about that at this point. You’ll have to fix this during the first quarter.

The second and third quarters are the tricky ones since it’s just down the road but there are still too many unknowns. 

The good news is that in reality – you’ll probably have much more knowledge to fill the gaps. Recall that in our example we’re talking about a company which already has a concrete experience in releasing mobile games – so in reality – if that was your job – you could probably set up a better framework for these chapters.

But sometimes there are indeed a lot of unknowns and so the roadmap will be – with a lot of fog of war. That’s acceptable as long as you keep updating it when new insights are poured in.

So here it is – a basic skeleton that you can iterate on from.

 

Well… I think that would be a good spot to call it a day. I can talk about it much more – but it’s already become much longer than anticipated, so we’ll stop here 🙂

If you found this post/series useful – feel free to let me know in the comments. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂