Rocky mountains vector created by vectorpocket —

Hint: Make sure you have the power of data behind you

This article explains high-level steps for setting up a data-driven roadmapping process.

Many of us have worked in organisations where we’re hired as Product Managers only to find the CEO/Founder/Management team is, in reality, driving the product roadmap.

Senior management driving roadmaps is common in small-medium sized businesses, especially those still led by Founders or long standing CEOs. Why? Because that Founder/CEO probably successfully built the company from scratch, at a time when there was likely no budget for the data, infrastructure and product expertise needed for data-driven roadmaps.

The Founder was the product team – and what’s more, it worked well! The Founder probably spoke to customers, monitored the market, shaped the offering, and took it to first level success. And now we’re asking them to change what’s worked for them and entrust us to bring up their ‘baby’.

Why do we want to drive the roadmap? Because we want to scale the product. The Founder will unlikely have the capacity to be the entire product team as the business grows. Secondly, as more competitors come into the market and we have to fight harder for business, we need the power of data-driven product decisions.

We have to show them the alternative and prove to them why it works. For this we need our old friend, data. We need to show C-Suite that by turbo-charging our product decisions with data, we can scale the product and the business faster.

Here are 4 key steps for setting up data-driven roadmapping and getting management buy in which we’ll elaborate on next:

  1. Implement infrastructure for continuously gathering user needs data
  2. Create an opportunity validation process
  3. Implement infrastructure for continuously gathering usage data
  4. Get C-Suite involved in the process [critical final step]

Why? Because without the means to continuously gather user needs research, we don’t have a data-driven roadmap. Understanding the heartbeat of what users want, and don’t want, is mission critical.

“User needs data”: Data on what users want and desire. I.e., What are their paint points; what are they trying to achieve on daily basis; what metrics are they striving to hit?

If you already have continuous user needs research infrastructure in place, you can skip to Step 2. If not, implement it! Here are 5 simple steps to do this:

a) Establish a place to gather, store and analyse user needs data.

Firstly we need somewhere to store all the user needs research — a mothership repository of user needs data if you like. This will hold not only data from user research calls, but also from anyone in the business who interacts with users (the Sales and Customer Success teams for example). For this I would recommend Product Board — this allows anyone in your organisation, across any team, to easily add quotes and excerpts from their conversations with customers (using an extremely easy to use Chrome Extension). You as a PM can then theme and synthesise these data into product opportunities for validation and roadmapping, then track them right through to build and deployment.

The next step is to source the user needs data. For a quick win, tap into the user needs data from sources that already exist in your company:

b) Ask your Sales team to contribute to your User needs data repository

The sales, customer support, senior management and many other teams in your company speak with users every day. They hear user feedback on a daily basis, and are an absolute gold mine for product management. This data can easily be captured — for example the Sales team can add user anecdotes/feedback to Product Board after sales calls, and the Customer Success team after customer onboarding sessions. To do this, the teams will need to be (1) Set up on Product Board so they can add data, (2) Motivated to actually do it! A key for motivating people is to make sure you continuously let the teams know what happened to the feedback they added — i.e., if a feature they suggested goes into the roadmap, let the contributor know so they can see they’re being listened to.

Example repository of user feedback. (Image taken from

c) Get a bank of users to talk to.

Next we want to gather new user needs data via highly focused user research interviews. The benefit of this over the above is that we can have very focused, deep-dive user research calls (in addition to the anecdotes from step 2) carried out by Product/UI/ user researchers who’s job it is to mine user needs.

Options for building this bank of users include (in order of low to high budget): Finding and contacting users yourself on Linkedin, using an online user testing site such as and hiring an agency to find users and schedule interviews.

d) Ensure you have people trained and deployed in interviewing users.

As well as the users, we need people who really know how to listen to them.

This can be either yourself as PM, or a dedicated user researcher. Getting this part right is key! User researchers need to know not just how to ask the right questions, but how to probe and dig below the surface to find out what the core of the problem is (which often isn’t apparent at first). More than anything, we need to seek out user goals and problems; not feature ideas. There are many ways to solve a problem, but we can only do so when we truly understand the heartbeat of what the user is trying to achieve.

e) Theme the data and identify user problems you could solve with your products/s (i.e., ‘opportunities’). To do this, you’ll analyse data in the user needs repository and draw out themes (this can be done in Product Board). The goal here is to end up with a list of problems/ feature ideas to take to the next step.

At this stage, the process looks like this:

Infrastructure for continuously gathering user research data. (Image created by author).

Once this infrastructure is up and running, you’ll have a lovely big repo full of user needs data which is being continually added to by your internal customer-facing teams and the user researchers, and a list of opportunities to validate.

We then need to decide which of these opportunities to put into the roadmap — i.e., we need to validate each one. This can be done in a few simple steps. To illustrate, we’ll use the following example:

  • Product: a remote patient monitoring cuff which measures various biometrics such as heart rate and blood pressure in hospital patients.
  • Opportunity (as identified in the user needs data): clinicians want to be able to use data from the cuff to predict heart attack risk in patients.

Steps to validate opportunity:

  1. Write use cases for the opportunity — Which aspects of the user’s work does the problem affect / what problem does it solve / which goals does it help the user reach? In the example above, the use case could be: “As a [hospital], I want [to predict which patients are likely to suffer heart attacks in the near future], So that [I can intervene earlier to prevent heart attacks] and [reduce the % of patients suffering from heart attacks in my hospital].
  2. Quantify impact [critical] — Would solving this problem help the user save time (how much?) or money (how much?)? In the example above, the impact could be an estimated 10% reduction in patients suffering heart attacks, as well as a 15% reduction in yearly hospital costs associated with heart attacks.
  3. Initial check of internal resources and costs — The goal of this stage is to discount any features which are obviously out of scope or feasibility and not worth pursuing. I.e., when we look at the opportunity; is there an obvious technical, legal or strategic barrier which would prevent us from solving it? In the example above, if we knew that predicting heart attacks required us to expose patient identification numbers in a way that would compromise patient data protection, we can discount it immediately. (Although note, if the feature is valuable enough, we may want to put together a business case to persuade other parts of the business to create a data infrastructure that would remove this data protection risk. Noa Ganot writes a great article about the importance of figuring out the ideal in the initial stages of a product, ignoring constraints).
  4. Competitive check—You may have a PhD worth of evidence that users want a set of features. But out of those features, which are going to help make the product more competitive or otherwise help us meet business objectives? In the example above, would providing heart attack predictions put us ahead of our competitors and lead to more sales? Show the CEO you’ve thought about this and provide evidence to show how the feature will make people want the product even more.

At this stage, the process looks like this:

Infrastructure for continuously gathering user research data and validation process. (Image created by author).

Usage data”: Once users are on your software, how are they interacting with it? I.e., How often do they log in; where do they click, where do they drop off the site?

App analytics show how users move around and interact with your software (usage data) and are a key way of measuring whether your features are achieving the outcomes desired. For example:

  1. Did the “multi-buy” feature lead to an increase in average value per order as expected?
  2. Did refactoring the database enquiries reduce page loading time as expected?
  3. Did adding a navigation bar reduce the the time taken by users to complete certain tasks on the app?
  4. Which features are being used most and least? (If some features are rarely used, we can then find out why – then make improve or cut decisions based on this data).

This kind of quantitative data is key when making big product decisions and will go a long way in showing the C-Suite (1) You’ve thought analytically about the recommendation you’re making, and (2) Post-hoc, that you made good feature decisions.

If you don’t already have a tool in place to gather this data, get it in place! Countly, Hotjar and Google Analytics are example tools that allow this.

Example usage analytics dashboard. (Image taken from

This is the part where we bring together all the data above and make a data-driven business case.

This stage serves two purposes. The first is to show C-Suite your data-driven process for roadmapping so they can build trust in it and eventually start to delegate roadmap decisions to their team. The second is to get feedback and input from the person who is potentially the best product thinker in the business — the founder/ C-Suite — and who is also the person who sets the business goals which the product needs to serve at all times.

The aim here is to succinctly present:

  • Your recommendation for the product roadmap
  • Why doing this will help meet business objectives
  • The user needs data to back it up
  • Any relevant quantitative usage data
Roadmapping process including C-Suite involvement. (Image created by author).

And voila — after a few sessions like this, the C-Suite/Founder/Management team will see you’re taking product development seriously, and hopefully start to step away and focus on other things like securing investment, setting the overall vision and being a general Boss.

I hope that’s useful! Feel free to direct message me on LinkedIn if you have any questions. You can also email subscribe to my posts here.

Lastly, if you’d like to further support the writers on Medium you can sign up for membership here.

Note: This article mainly applies to small to medium companies where a Product function is still being established. There are many ways to help make your product roadmap data-driven, this is just one example. It would be great to hear how other people have done it and what tools have been used.

Source link

Leave a Reply

Your email address will not be published.