Stakeholder 101: Why priortise requirements when everything is a priority?

First things first. This article is not directed at our usual audience of Digital Product, UX or Agency teams. Product natives will be very familiar with the concepts here. 
 
When working with broader stakeholders within organisations, I sometimes get push back. As a result I felt that they sometimes do need refreshing on some of the premises. For businesses it is now more important than ever to ensure that what you are delivering adds value. Value for the customer, and value for the business. 
 
Some of the basic premises. 
 
Our task is to create business benefit through digital channels. Jeff Bezos outlined how this is best achieved when he said ‘We see our customers as invited guests to the party and we are the hosts. It’s our job every day to make every important aspect of the customer experience a little bit better!’.
 
A party is a once only event. We are there to make everything perfect, to provide the guests with an experience that they will enjoy, and I feel that sometimes here is the tension. How can we prioritise when, for the party, everything is a priority!
 
The unfortunate fact is resources are finite. We balance our requirements across a group of broad variables. 

• Features. For the project team, this is the agreed functionality that is expected to make the customers overjoyed.
• Time. The available window of opportunity to get things done.
• Cost. This can manifest in many things, it is the budget available for resources software, assets and man hours to execute. 

 
The final measure is quality. To explain this, a feature could be executed quickly by few resources and with minimal manual effort to deliver, functionality that could also be delivered to a high degree of polish. Here is where the Prius/Rolls Royce analogy works but unfortunately also fails. They are both cars that can get four people from A-B. It’s just that the time that goes into the production of both products is completely different.  Ask any business owner and they will always want the Rolls Royce. But of course if you want a real Rolls Royce you have to join the waiting list and those wanting the Rolls Royce Phantom Drophead Coupe will have to wait five years.
 
This is in essence the requirement for prioritisation. There is a need to get from A-B. we all want an extemporary experience for our customers but we don’t want to wait 5 years for it. 
 
To build the experience that perfectly suits the needs of your customers. The goal should be to follow the deploy, measure and learn approach building feature by feature until you get from your Prius to your Rolls Royce ensuring that you are building in the right components along the way. 
 
I rarely get projects with unlimited resources. However, quality and functionality are always required in abundance. In the worst scenarios time is also short. 
 
It’s a short explanation but ultimately as a product manager, I am looking to ascertain a rounded picture of the real requirements across all pillars. It is only when I have this that I can manage your product to make every important aspect of the customer experience a little bit better!
 
In this scenario its important to gain an understanding of the organisational priorities. 
 
To understand this I use the following lens. 
 
Defining a prioritisation framework – Setting the prioritisation criteria  
 
Work out: 

• What will add most value to your business? 
• Company value: How valuable is this opportunity for the company?
• Customer value: How valuable is this opportunity to our customer? 
• How is this measured?
• What will it cost? 

 
Or think about this question. What will be the cost of delay if you delivered a certain feature 3 months down the road or within the next couple of sprints! 
 
When considering the cost of delay. Think about the following. 

• Expedite - For every minute in time that I lose, the impact increases. For example, it would cost me xx per day not to have this feature.
• Fixed date. There is a fixed date in which I need to get my task completed. There is not a lot of value in getting it done before that date, however if we miss it, there will be exponential cost.  
• Standard – There is greater value at the start that flattens out. Initially benefit to customer, then value disappears. This is the most typical type.
• Intangible – Mostly relates to removal of Technical debt.
• Ensure that everyone agrees, or clearly understand the delta.

So when we get a prioritised list we are not moving things out of scope, we are understanding their relevance to scope. We then use agile methodologies to develop, test, learn and iterate. 
 
Fail fast, excel quicker, iterate 
 
Even in our best efforts we don’t always get it right first time. 
 
That P1 priority item so painstakingly thought through doesn’t really deliver the expected results.  That’s also okay if you are working with the Agile framework, because you test , measure and learn.  The agile methods iterative nature also means the end product is ready for market much faster, staying ahead of the competition and quickly meeting the benefits. 
 
If you are live to market and the P1 enhancements are effective you are capitalising on that investment. Creating revenue in the short term to reinvest in further resources. 
 
To conclude, this article is not intended as rocket science or a definitive work. I’ve been in the industry so long that prioritisation is part and parcel of what I do. I do get a little surprised when people not from the same background ask, ‘But I want everything, why do I need a prioritisation exercise?’ 
 
I now have a little link, when I am asked that question again, I will send people here. 
 
And don’t forget. There is always another party. It’s not a one-time event! 

Mona Ranjan

Copyright JumpRock 2021