Most companies need help implementing a product development roadmap prioritization technique to decide which feature/project should be given the highest priority and the most resources.

When the Product manager is tired of determining the feature request priority by the level of voice or noise one stakeholder makes or amount of meetings/emails/reminders another stakeholder creates, one starts dreaming of a magical prioritization formula that will make this cacophony to go away (you recognized those stakeholders, correct:)?)

Luckily, several such helpful frameworks exist. An excellent summary of them is written here https://roadmunk.com/guides/product-prioritization-techniques-product-managers/.

Unfortunately, a lot of companies fail to use these systems continuously and with any meaningful impact for several reasons:

• a lot of projects/features get the identical high scores
• scoring/ranking exercise is done once and never gets updated according to changing circumstances
• people get fixated on formula, and no exceptions are allowed
• too many exceptions are allowed (“the CEO asked to do this” paradigm)

In the following article, I will describe my favourite prioritization framework — Weighted Shortest Job First, from SAF, with a slight secret twist. I will also give guidelines on how to make it work on a continuous level, as well as how to combine it with Product roadmaps.

I recommend applying the prioritization technique on Product Roadmap items. It can be a monthly or quarterly roadmap according to your company cycle. (I am not a fan of longer roadmaps for practical reasons — they change too much over time).

WSJF

Weighted Shortest Job First (WSJF) is a Scaled Agile Framework (SAFe) prioritization model used to sequence jobs (for example, Features, Capabilities, and Epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by the job duration.

Product managers provide the cost of Delay estimates. Dev teams provide complexity/Job Duration estimates.

Business value. Scale: 0 min, 10 max. 1 point — x in revenue per month

• How much income do we plan to get via increased sales, increased MAU, higher conversion rates, etc.?
• How many costs do we plan to save due to more effective processes, or due to switching to the new cheaper service provider, etc.?

User value. Scale: 1 min, 10 max.

• How much our client will love the change, how user-friendly it will be for him.
• How much will our internal users (customer support employees) feel about the change in our back-office software?

Opportunity/risk reduction. Scale: 1 min, 10 max.

• Are we opening a new market? New product? New client group opportunity? Will it help us to discover a new segment?
• Are we reducing regulatory risk? Fraud risk? Compliance risk?

Time criticality. Scale: 1 min, 10 max.

• Is there any hard deadline? Set by the regulator? By Supervisory Board? Have we promised our clients something to be delivered on a specific date?
• Do not count deadlines that we have set ourselves as internal ones!

Complexity (Job Duration). Scale: 1 min, 5 max.

• 1 — one sprint. 5 — much-much more.

Secret coefficient. Not everything in life can fit into the equation. For example, you cannot fit Love. Or cat.

So for exceptional 3–5% of cases, the Leadership team (or CPO) can add special points to some projects to boost their score.

Pros of using this prioritization framework

• It allows you to quantify your product backlog in terms of money.
• It helps product managers make better decisions based on the value that matters the most to the company.
• It changes the team’s mindset around features from cost and efficiency metrics to speed and value.

Cons of using this prioritization framework

• The parameters for determining the monetary value of a feature are based on gut feel and intuition. This can lead to internal disagreements regarding the arbitrary value of any given feature.
• As the feature still needs to be thoroughly analyzed, it can take time to estimate the complexity of implementation.

Practicalities — were to do the calculations

You can go nice and fancy with various useful tools to support the calculations, but the most straightforward is old-school Excel :) I have been using a shared cloud-based Excel sheet with the following format:

If you work for a more prominent organization, calculate a score for Projects /features requiring more than one sprint of dev effort and not for smaller ones. Otherwise, your roadmap will get too crowded.

I recommend including Jira links to all projects for more straightforward navigation into “drill down into details.”

Practicalities — roadmap maintenance

When a new project appears in the pipeline and has to be added to the running quarter, it should be added to the roadmap, and the score should be calculated.

If the score is higher than the existing projects in the team, then a decision has to be taken on whether the team can add an extra project into a quarter plan.

In most cases, there is no excess capacity; thus, a project with a lower score must be moved into the next quarter. The leadership Team and the Stakeholders must be informed about the change in a team’s plan.