Building a product roadmap! Explained

I will start by clarifying a critical concept at the start of this post. The product roadmap is not a project plan. I cannot emphasize this enough. I have experienced enough situations where management approaches the product roadmap as a project plan, and I think this needs to change.

The product roadmap is instead a strategic plan on which the product manager should be spending most of his/her time on iterating, updating, elaborating. So what is this strategy map means?

Wikipedia.org defines it as;

“A strategy map is a diagram that is used to document the primary strategic goals being pursued by an organization or management team.”

In our case, the document defines the strategic goals of the product that aligns with company objectives and user needs. So given this statement, it is clear that this document should be time-bound. Which means we need to have this strategy maps for defined periods.

Timelines of product roadmaps

I find it most helpful to create three specific roadmaps.

1. Monthly product roadmap [detailed]
2. Quarterly product roadmap [fewer details]
3. An overview roadmap for a year.

I follow this approach because I need a more detailed strategy for the thing that I am going to do in the upcoming month while driving my product to success. For the quarterly one, I need a more loosely defined plan because I do not have much certainty or data. Similar to that, the yearly one, I only know my goals and several details that make it challenging to drive relevant detailed strategy maps. Here is an excellent example for you; during COVIT-19, how far can you plan and strategize? You do not have many accurate data, there is high uncertainty, and it is hard to make plans on the knowledge you have.

So, in this case, you avoid making detailed strategy maps (product roadmaps) because the situation might change within days, and the product roadmap you created might be void [long term ones]. Because of that reason, I strongly suggest you need to take an iterative approach and update your product roadmap based on data. I will describe what I mean by data in the following parts of this text in detail.

One notable highlight is: I am not saying you shouldn’t be creating a long term product roadmap, I am suggesting that detailing it nine months ahead is not a smart way to spend your time.

I will jump into the approaches that can be taken by the product manager to create a roadmap.

Selecting features and aligning with the goals

I will not go into the details of setting the longterm strategies because they are relatively different from industry to industry and not always set by the product manager. Instead, I will use some preset examples of corporate goals to define a process to set the bits and bolts of data-driven decision making on the product roadmap.

For the rest of the blog post, I will set our goal as follows;

— Increase signups by 15% year over year by December 31st.

Let’s assume that we are working in an OTA [online travel agency].

So, given the goal in our hands, how will we generate relevant ideas to support this goal? My general proposal is as listed below;

Step 1: Understand customer needs and differentiate the underserved ones.

Step 2: Reach-out the internal stakeholders and understand their goals and gather their input.

Step 3: Create a prototype, make pre-live testing and iterate

Step 4: Implement the product roadmap and align stakeholders.

Understanding the customer needs

In this phase, I employ several data points that I try to understand the user and creating different user segments.

First, I will start by benchmarking; in this case, I will check booking.com, Expedia.com, and any relevant competitor to understand their approach to this topic. I signup to their sites and start receiving mails also check the benefits of being a registered user.

In parallel to the above step, I work with copywriters to set up two kinds of user servers, one with pre-defined answers and one with open-ended questions where you can get more unstructured answers.

Besides, I reach out to customer service and listen to the customers’ recordings that reach our customer service. Also, gather the analytics data around it.

I combine findings from these three inputs into and spend enough time to understand, and document details then move on to the next step.

Finally, I set up a meeting with the relevant internal stakeholders to present the finding and driving a strategy together. One of the meeting’s critical goals is to create diversity among the attendees to have all the voices heard and also create dedication for the strategy. Here is how I generally approach to these meetings.

• Introduction: Definition of the goal

You make sure that everybody attending the meeting understands the goal and the relevancy to the company and user. Also, fact checks it with the team through achievability.

• Presentation of user research

You present the details of your finding and demonstrate the different approaches that competitors take and initiate ideas within the crowd.
I find it helpful to create a one-pager with the findings to share with the crowd, so they have a quick reference.

• Ideation session
• Prioritization session [I have a separate post where you can find different prioritization techniques to do this part. ]

I always consult with our engineering team to estimate the relative complexity of the concept based on story points. This estimation is rough; it is not a time to complete. The complexity of developing the idea is what matters.

In the end, you have to put it into a matrix that looks like below given one

Complexity — Benefit Matrix

I think this wraps up the meeting. To sum it up, you go into the meeting with;

• Competitive analysis and benchmarking of the strategies and features
• Direct customer feedback and surveys
• Analytics Data

Then combine the fact and ideate with a diverse team and end up with prioritizes ideas that are ready to elaborate. Now it is time to put this into a road map and start detailing the strategy.

Creating the actual roadmap

The meeting you held with the team yields two crucial outputs the customer benefit and the complexity to build the idea matrix. Now, it’s time to put these features on to an actual roadmap.

Step 1: List the ideas, epics, features in descending order by the customer benefit. You can easily lay down your strategy by prioritizing through customer benefits were the most significant impact at the top.

Step 2: List the epics, features in descending order by complexity build without changing the previous order. It would be best if you were ending up with a list, as I share below.

Looking at the table, I can see that my team can work on Epic 4 and fully finish it in 2 months period (given that the scrum team runs 2-week sprints). Based on this, I can build the roadmap and elaborate on the details of epic four and have a detailed strategy map.

To be able to create the details and deliver a functional MVP, I employ user story mapping. Which is mapping user actions to the user stories that you will create for this epic?

This is what Jeff Patton says about user story mapping in his web site.

“User Story Mapping is a dead simple idea. Talk about the user’s journey through your product by building a simple model that tells your user’s story as you do. It turns out this simple idea makes working with user stories in agile development a lot easier.

The above-given paragraph is how Jeff Patton defines user story mapping in his web site.

More importantly, it’ll keep your users and what they’re doing with your product front and center in your products. That’s better than getting lost in feature arguments — like what happens typically in software development.

I’m not making any promises here, but I believe your products will ultimately be better if you use Story Mapping.”

Once you have the user story mapping, you have the prioritization ready, share it with your team, and start testing.