Which feature prioritisation framework do you recommend?

Andre Muscat -

As a Business Leader, you continually deal with aligning the flow of work requests and the consequences of delaying any action on them.

As we mature our processes, we work to better the structures that help us:

  • Prioritise the delivery of work
  • Gain cross-functional support for our direction that balances the value we seek to deliver with what looks most reasonable to complete first
  • Maximise returns of investment and efforts

We explored these across a series of posts:

You can, of course, rely on your gut; however, as your business scales, you quickly learn that such an approach puts your project/delivery at higher risk of failure due to assumptions, miscommunications and lack of support from the rest of the organisation.

The world has developed various frameworks that you can use to prioritise work requests:

Shoutout to Jordan Lamborn

Jordan Lamborn identified over 140 Feature Prioritisation Ideas for Product Managers.

Check them out here and drop him a message as he pulled one heck of a job to consolidate this list!

Observations around Prioritisation Frameworks

Each has its merits, strengths and weaknesses.  Of the ones tabulated above (namely MoSCoW, KANO, RICE and WSJF), all are heavily qualitative (i.e. they are analysed based on a personalised, subjective understanding) of their assessments, with many being pure outright guesstimates.

The more sophisticated ones like WJSF and RICE try to approximate a reasonable quantitative value across elements considered in their equation. These guestimated values pass through an equation that spits out a value used to prioritise work.

The dangers of going all-in?

All of these frameworks have a particular and quasi-common weakness.

As I point out in the section "Significant risks of your current order of work" of the article "How to align work and releases for continuous flow of value that matters", these prioritisation frameworks function to purpose as long as you have a mechanism to re-allocate work according to:

  • New information imparted by the business around its priorities and opportunities (Check out "How to determine what product opportunity to pursue next")
  • The available capacity/skills available in the team to deliver the necessary work on time, to scope and timeframes expected.
  • The strategy of grouping work according to release schedules enables delivery to staff up, train up, and align work to predictable roadmaps that will allow higher productivity and employee satisfaction within the organisation.

I emphasise this because the source of information, i.e. the lists that need prioritising using these frameworks, tend to become simple feature requests lists. This means that the methodologies become great at prioritising features, but not necessarily the business problems that need to be addressed or opportunities within reach. People need to focus on the latter ability, i.e. the application of business context, to ensure the outcoming prioritisations align with the purpose at hand.

An excellent observation by Saeed

In a comment I came across by Saeed Khan, I noticed a great suggestion I will be taking upon myself.

Saeed commented how these frameworks typically lack a parameter for meaningful margin of error (e.g. +/- 20%). He argued that the results are still likely erroneous even with these corrections if the focus was on prioritising features lacking the appropriate context of business objectives and business problems to solve.

Which one do you recommend?

What I learned is that there is no one size fits all.

When working with smaller organisations / or deliverables in discussion as part of a Professional Service, MoSCoW and Impact Value Mapping seem to work with most characters around the table. These projects tend to be bespoke and focused on reaping short-term value to gather support within the business. They also tend to be very much in the land of PROJECTS with a fixed outcome and near-scope in mind. Once complete, it is common to use Walking Skeleton / Proof-of-concept work as a next step before entering the broader investment needed to develop the entire solution.

In Product land, you typically find more mature processes. Here, I tend to use RICE, SWJF and KANO variants. In lack of an established structure,  MoSCoW would be my starting guide. I would then iterate to expand and transform the template into a personalised version taking what inspiration I need from WSJF, RICE etc.

Using an example, I would use principles from the MoSCoW and Impact Value Mapping when prioritising a Proof-of-Concept or Proof-of-Value piece of work.

Alternatively, I would use principles from RICE and WSJF when engaging in larger pieces of work where more in-depth business engagement can benefit.

No matter what I do, I ALWAYS end up however with a personalised framework for the customer I am working with.

It is essential to take the principles of these frameworks and personalise them to the needs and biases of the company in question.

By starting with the complete understanding of the business purpose and direction as I outline in  "How to determine what product opportunity to pursue next", feature prioritisation and next steps tend to be simpler when done within a context of understood vision, direction and cross-functional collaborative engagement.

One last thing....

Do not forget tooling.

You can start with spreadsheets (Google Sheets / Excel) both are great starting points to set a baseline workflow.

Once you have a strong workflow, invest to upgrade your tooling to support your work:

Use them to:

  • Be consistent in the way your teams capture, merge, annotate, promote and review work.
  • Avoid shiny objects syndrome.
  • Have consistent work to request work for prioritisation.
  • Have access to an always updated prioritised work request list.
  • Guide customers and partners on where their requests lie in the latest order of works
  • Centralise notes and justifications for moving forward or stopping work