My first steps in creating a product roadmap

The question you get asked the most as a product owner is "when is it done?". The question comes from a place of uncertainty. In reality, whatever the answer was, in 99.9% of the cases you will not deliver on the mentioned data. People change, processes change, money changes and thus the date changes or the item is no longer relevant and thus canceled.

Roadmaps

People expect a powerpoint or gantt chart or another visual which tells them when you want to deliver what. Again, I understand where it is coming from but again, in reality you never deliver according to that roadmap.

If you want to maximize the value of the product for your stakeholders you should be able to always change what you want to work on. The only thing that is important to know is what you will be working on next.

I struggeled for months coming up with a format that would help me be transparent in what I wanted to work on but not based on gut feeling.

As a Product Owner I have a range of stakeholders that want to influence what I work on and I want to make sure they all know what I will be working on and how they can influence that.

1. Users of the product (duh!)
2. Security
3. Architecture
4. Vendors
5. Engineers in my team
6. The company

Product Pipeline

Inspired by a post on LinkedIn where someone mentioned the concept of product pipeline I knew I was on to something useful. A product pipeline is a table with a list of items you want to work on and a method of scoring each item and then sorting the items based on the score. By applying a scoring method you determine what needs to be worked on next.

Scoring

It is important that you find a scoring method that works for you. If you have find your scoring method make sure you be consistent in how you score. Don't make it a big discussion but use the number that comes to mind first. If you have scored a few items it will be easier because you can compare.

Weighted Shortest Job First

Within my company we use WSJF, which stands for Weighted Shortest Job First. It's a concept from SAFe (Scaled Agile Framework) and while I resend SAFe, if everybody uses the same scoring method this adds value. WSJF has 3 parameters which, in total, add up to the Cost of Delay.

• Business Value - what is the relative value for the business?
• Time Criticality - how does the value decay over time?
• Risk Reduction and/or Opportunity Enablement - does this reduce our risk and/or does it provide additional opportunities?

If you divide that with a job size you get a score. Job size can can be the number of person-months or a T-shirt size (S = 1, M = 3, L = 4,...)

I think I prefer the RICE method more.

RICE scoring

It stands for:

1. Reach - the estimated number of people the item you want to work on impacts on a given timerange
2. Impact - a quantative or qualitive number (below an example of a range you can use)
   1. 3 = massive impact
   2. 2 = high impact
   3. 1 = medium impact
   4. .5 = low impact
   5. .25 = minimal impact
3. Confidence - an indication of how confident you are about your Reach and Impact numbers (below an example of a range you can use)
   1. 100% = high confidence
   2. 80% = medium confidence
   3. 50% = low confidence
   4. < 50% = moonshot
4. Effort - the total number of resources (product, design, engineering, testing, etc.) needed to complete the initiative over a given period of time, typically “person-months”.

The score is calculated as (Reach * Impact * Confidence) / Effort.

The final result

Who's scoring?

An interesting question. As mentioned earlier there are a lot of stakeholders which want to influence your roadmap. You need a way for them to influence the score.

You can start scoring as a PO and do that together with your team. Then you can organize sessions with your other stakeholders and show them the pipeline. Based on their input you can determine if you need to change some of the parameters and so change the score. You don't want to change a parameter if one stakeholder has a certain opinion so you need to take into account all the opinions and then decide if you need to change it.

Closing thoughts

If your product is in being used this is a good process to use. If you are working towards an MVP you can use this as well to determine what the scope for your MVP is and what you need to work on first.

What I like about this is that you can share your roadmap easily and change it when you need to. You can be transparant to your stakeholder so they always know what you are working on next. It also helps that they now understand that you are not making priority decisions on gut feeling.

In a later blogpost I want to explain how I use Jobs To Be Done in the context of roadmaps.