8 steps on how to build a solid product roadmap

“ Plans are worthless, but planning is everything.” — Dwight D. Eisenhower

There are different schools of thought on the importance and foresight of a product roadmap. Should it be 3 months, 6 months, 12 months? Should we even have one? If so, why?

Personally, I do believe that there’s great value in having a roadmap. It allows for your team (and the company) to have a guiding light as to the direction you’re all going towards. It helps the Sales team to know what’s in the pipeline, the engineering team to know what they should have in mind when building the different blocks of the overall product and the marketing team to know how to adjust their messaging.

Not only is there value in having a general guiding light, but more importantly the actual process of building (read: planning) the roadmap will surface many questions and challenge many assumptions that in the end will prove very useful to the product itself.

However, when working in a startup, planning anything specific for more than 3 months in the future can be very… ambitious. The playing field and market info will probably change in 60–90 days so you’ll need to stay agile and flexible enough to adapt.

So let’s dive a bit deeper into the process itself.

Different product managers have different ways of building their roadmap and I’m sure their methods work well for them. However, I thought I’d share what I found, after many attempts, the steps that worked best for me.

(I’m assuming a lot of user feedback/research has already been done at this point)

1. Continuously track your “wishlist of features”. Feature requests will come from many stakeholders, both internal and external, so it’s important to keep track of all these features, where they came from, how many people have asked for it, what’s their urgency, etc… Personally, I like to use Prodpad as my tool to keep track of feature requests and ideas.
2. Do a first pass yourself. Before engaging more people into the process go over your wishlist and weed out the features/ideas that are clearly not viable. Tip: Don't forget to always ask yourself: “What's in it for the user?"
3. Do a high-level pass. The first audience I like to start my process with are colleagues like a Head of Engineering and Head of UI/UX. Go over your list and get their input. Ask each other some tough questions and draw up some sketches of what the features could look like. Ideally, by the end of this meeting the three of you should have a slightly shorter, yet more defined list of features.
4. Make some mid-fidelity mockups. It’s crazy the power that visuals have when explaining something to others. It really anchors everyone around a more tangible understanding of what a feature is and more importantly what it isn’t. Before proceeding with a larger audience I strongly suggest to engage with the UI/UX team to make some mid-fidelity sketches of what the feature could look like and how the user might consume it.
5. Do a mid-level pass. At this point, you can involve different team leads to get their input in ranking the relative cost and impact of every feature. An exercise that someone introduced me to that I really liked for this purpose was “poker planning”. In a nutshell, everybody has a deck of cards (e.g. XS, S, M, L, XL) and once the feature has been explained and debated (make sure to “timebox” this!). Everyone picks what they feel is the relative size of cost to build this feature and shows the respective card at the same time. You then go around the table and discuss any large deviations. You’d be surprised how many times one person might sway the rest just because they thought of something that others haven’t thought of. The same is then done for the Impact (i.e. benefit) of the feature and both results need to tracked. Again, I like to use Prodpad as a tool to track this (you’ll see why in the next step). Tip: make sure you correlate each size (e.g. XS) to an anchor that everyone can relate to. For example, Feature X that we developed last month was a XS and Feature Y was a M.
6. Review and prune. Now’s a good time to review all the features by looking at the Impact vs Effort graph provided by Prodpad and removing all the ones that are clearly “Time sinks”.

Prodpad graph of Impact vs Effort

7. Do a low-level pass. I would recommend doing one more poker planning review of the pruned list of features by engaging most, if not all, of the engineers involved in developing these features. This meeting can be very… heavy, but I do believe that the product will profit in the long run because not only will everyone have a good understanding of what’s coming but they will also feel accountable for its success because they were part of the process of deciding what to work on and why! :)

Tips: 
This part can be quite long so make sure to timebox your discussions and maybe even break this section part into 2–3 separate meetings just to keep everyone fresh.
Don’t forget to take into consideration the time it takes to QA/test when estimating the cost so it’s good to involve the QA team here as well.

8. Prioritize. This isn’t the longest but is probably the hardest part. The unfortunate reality is that you cannot do everything at once so you need to prioritize the features and put them in a timeline, that you will then have to defend with all your stakeholders. I find it useful to work at least with the Head of Engineering on this one to make sure that Product and Engineering are on the same page. Tip: For the actual gantt chart of the roadmap I do end up just using Google sheets. To my surprise, I haven't found a better alternative yet.

And there you go!

This process might be a tad time-consuming but it should yield a solid roadmap that everyone feels accountable for. Now it’s time to execute, adapt and iterate! :)

I’d love to hear about other methods, tools, approaches that have worked well for you! Feel free to comment or ask a question :)