Have you ever wanted something, merely for the reason that it was in trend? And because it was in trend and everybody seemed to have it, you had to follow the trend? If you ask me, I would have to answer yes to this question. I have done things and bought things, just because everybody else was doing and buying them and not because I actually had a need for them. 

Now, let’s take this situation from our everyday life to the world of web development, do you think it’ll be applicable there? It would and I’ll tell you why. 

When a web project is underway, there are tens, if not hundreds of scenarios, that can turn out to be the outcome. It is up to the project managers to steer the project into the direction that is the most suitable for the goal that was decided in the planning stage. However, there are times when the project goes adrift.

How can that happen?

People, when developing a project, often aim to make it the best. Nobody aims for a substandard result. So, in the chase to become the best, they try to pack the project with as many features as possible and lose sight of the initial target. 

The client has asked for it, add that feature; 
A stakeholder vehemently disagrees with a valuable feature, leave it; 
The competition had added a specific feature, we have to add that too; 

Decisions like these are a major reason as to why projects do not achieve what they intended to. It is also why project managers have to take on the burden of choosing what to incorporate in a project and what to leave behind for now or for good. 

This practise of choosing the appropriate roadmap for a product and acting upon it throughout the development phase with the help of a well-defined strategy is often referred to as feature prioritisation. It essentially draws out the order of features that would find their way into the project and the time as to when they would. There is a lot that goes behind feature prioritisation and market research is the beginning of roadmap development. 

Upon asking a group of project managers about the biggest challenges pertinent to their workload, here is what they had to say. 

Feature prioritisation is by far one of the most challenging aspects of a project manager’s job profile. Today, we will find out why that is the case by understanding how this concept usually works, what are the flaws that accompany it and also the suitable strategies that work in the favour of feature prioritisation in project management. So, let’s begin.

The Everyday Feature Prioritising Process 

Feature prioritisation is a process that can be a tad strenuous to achieve. A major factor as to why I used that adjective is because it is a process involving people, their ideas and their feelings attached to those ideas. Building a web project requires work, but involving people and opinions and trying to reach a consensus for each development in the project would require work and give you a headache. Ask any project manager, an aspirin would be a common dietary supplement that comes with the job. It is, after all, a job where emotions perpetually run high. 

Let’s have a look at how feature prioritisation is done on an everyday basis. 

Focusing on the bigger goal 

Before the PM gathers evidence to back a feature and have all of the lengthy discussions based on the evidence trying to convince every person the team that it would work and is a must have, the PM has to make everybody see the bigger picture and focus on just that. 

The development team is going to be diverse, there are going to be people who are pros at what they do and these people are going to want to have their way because they think they know best. And maybe they, but being expert in one area does not give them a say in deciding what is right for the project, wherein several other aspects also play. 

Therefore, the understanding of the end goal by every person on the development team is crucial, if a sense of consensus has to be achieved. Of course, there aren’t always going to be unanimous decisions, and when that happens, team members shouldn’t resent the decision, they should be able to comprehend the reasoning behind it by focusing on the bigger goal. 

Prototyping for evidence 

Now, comes the part of accumulating evidence in support of a feature that should be implemented. And prototyping is the means to go here. 

For instance, you have a theory that you know is going to work in favour of the end goal. However, there is some apprehension about it. What do you do then? You prototype. You will try to develop a testable hypothesis, run it, get the results through the proper execution of the testing cycles and get your proof. 

This proof would help the team alleviate their doubts about an approach, even if it is you. The same can have negative results, meaning the test outcome could be unfavourable. In that case too, you would have the evidence to not seek a particular line of action.

Valuing the hierarchy or not?

When prioritising features, you will have a clear roadmap, you will most likely have a semblance of understanding as to what you want and what you don’t. However, all of that can go in vain, when a high level idea pops into your planned course of action. 

Denying an executive his request can be a problem for many. The perfectly curated project plan can land from a high chance of success to high chance of failure because a stakeholder decided to imbalance the project features with his request. 

Remember the prototyping we discussed in the previous point, put that to practise and save your project from being jeopardised. And that is how you must value hierarchy.

Seeing the future through the present

At the end of the day, feature prioritisation and even the entire development process is pursued for a goal that should be fulfilled in the future. And it would only be accomplished, if you put in the efforts today. 

Seeing the future means that you know how the dots will connect to make a perfectly straight line. This is done by thinking practically about the path to take and filtering out the meaningful from the meaningless.

You, as a Project Manager, have to make your team understand the reasonings of the present for the build that would get implemented in the future, If people know what they are doing today is going to serve a great or even a small purpose, like providing online education to the lower income households, they would most definitely put their best foot forwards; making feature prioritisation less of headache for the PM.

So, how would you define feature prioritisation? 

According to one of our Project Managers, Abhijeet Sinha, feature prioritisation cannot be put into a mould to have a rigid definition that would stick to every scenario. He considers the process to be purely contextual and thus, its meaning and implementation becomes quite dynamic. The only thing that persists in feature prioritisation is balance, a balance between the needs of the stakeholders and the feasibility of those needs. You can’t deliver the moon and stars on every occasion, the sky would lose its brilliance then. And I am 100% in accordance with him.

The only thing that persists in feature prioritisation is balance, a balance between the needs of the stakeholders and the feasibility of those needs.

During my discussion with Abhijeet, we talked about one particular project, wherein prioritisation was more difficult than others because priorities and feasibilities were clashing at massive proportions. 

This happened in the Thinkin Blue revamp project.

Thinkin Blue is one of OSL’s most prominent project; it involved the progressive revamp of its site. The client wanted the existing theme of the site to remain the same, the revamp would involve a change in the templates, all of this seemed feasible. The problem came in the homepage, wherein two themes had to be involved, the existing one along with the new one, which was essential for the revamp to look like a revamp. 

However, the developers were apprehensive about it, because building a homepage on two themes was going to be a massive challenge, and complicated would not even begin to describe it. 

The client wanted one thing and the developers thought it was too complicated, the project was in a deadlock. Abhijeet, being the PM, tried to reason with both the parties and in the end, the developers compromised and the home page was built on two themes. 

The same happened for the headers, the client wanted global headers, while the developers didn’t think that was the correct way to go for the home page because of the new theme. One of them had to give some leeway to Abhijeet to make the project roll forward and this time it was the client. 

Do you see what Abhijeet did? He didn’t let the stakeholders reign everywhere and neither did he allow the developers to issue all the commandments. He always listened to both sides, he thought rationally about the practicalities and wherever he thought he could push, he did. When he had to accept the client’s needs over the developers, he did and vice-versa. There was always a balance. And that is how projects succeed, Thinking Blue is a testament to that. Being stuck in a deadlock would only cost you money, time and efforts, and if compromising can avoid that, then you, as project managers, should start working on it.

So, What Should Be the Hard Hitting Prioritisation Questions To Ask?

In the previous section, we talked about feature prioritisation and how it usually goes around. The involvement of ideas, emotions and hierarchy is inevitable. Regardless you have to persist to get to the suitable features for your project without going on a crazy rampage of unwanted attributes that you will most definitely regret later. 

Here are some questions that will help you to avoid going astray.

Think about the users

Feature prioritisation starts with the users, it is them for them all of the efforts are being made. Therefore you must ask yourself; 

How many users would the proposed feature impact?
How many users would be able to use the feature without finding it complex or confusing?
How many times will the user be using that particular feature in a day?
How many users would feel as if they are empowered by the feature, would its value resonate with the users?

The higher the answers to these questions, the better the feature would turn out to be. For instance, adding various accessibility features that aid the use of a screen reader on your web project would benefit the visually impaired a great deal. With as many as 285 million users being visually, I’d say the odds of such a feature passing prioritisation are quite high.

Think about growth 

After the users comes the growth potential. Growth is a pretty broad term. It could mean bringing in new customers through an invite feature and it could also mean eliminating a feature that acted as a deterrent in luring the competitor’s market. You have to be familiar with all of your feature’s growth aspects and then ask yourself; 

Would the feature aid in your growth?

Think about efforts 

Building something that solves a problem is indeed going to require some effort from your effort. So, to ensure that your efforts get their rewards, ask yourself these three questions.

Does the feature require to be developed from scratch or does it just need some fine-tuning to perform better?
Does the feature require a lot of resources for its implementation, if so do you have a plan for delivering those resources?
Does the feature raise the level of building and using complexity for the developers and the end users and will it be worth it?

Then, think about yourself 

After all of that, you think about yourself, your goodwill and your market position. The kind of features you provide in a product speak to the kind of values you have as a brand. A brand prioritising accessibility would resonate as a brand aiming for social inclusion and that would be wordlessly spoken through the features it pumps into its products. And I do not have to tell what the value of a positive brand image is. 

So ask yourself, how well is the feature suited to your brand’s vision and its market position?

The Flawed Kind of Feature Prioritisation 

Now that we have a fair understanding of the do’s of feature prioritisation, it’s only fair to peruse the don’ts as well. These certain things and aspects of selection that may seem totally fair to you, but in reality can hamper the entire process; so, you really have to be mindful of them.

Prioritising one opinion over getting diversified notions 

One consumer feedback, one analyst opinion, one ROI report on that one feature; what do all of these have in common, the adjective one. They are proposed by an isolated person or report, and because of that, you cannot pay too much heed to them. It’s like not voicing your opinion because one person told you to shut up. 

You have to look at diversified notions. 

• If a number of consumers are dissatisfied with a particular feature, then consider fixing it. 
• If an analyst is able to back his claim with up-to-date data and not antiquated reports, then consider implementing his opinions. 
• If the company ROI and consumer value is on the table along with the ROI of the feature in focus, only then consider any course of action.

Otherwise, you’ll end up wasting valuable time, efforts and resources and I’m pretty sure doing that has been in your don'ts list since such a list was conceptualised.

Prioritising gut over rationale 

There are features that we love and there are features that are necessary. Both of them could be the same and benefit the brand and the consumers alive, however, there is also a chance that they might not. 

If you or let’s say your boss thinks that a particular feature would add immense value to the project because she loves it and her gut tells her that this is what the project has been lacking, you can’t listen to that. She could be right, but following the gut is a big no-no in feature prioritisation. 

There has to be a proper rationale behind every selection, every addition and every decision made. 

You also need to know that you cannot always ensure that everybody on the team is making a rational decision, cognitive biases are a real thing and you can try to negate them, but being 100% free of them in the selection process is not a guarantee.

Prioritising an interpretable measurement system over a solid one 

In a group with a divided opinion, how do you come to consensus? The answer is through voting. And that is an important part of the selection process in feature prioritisation. These votes become the unit of measurement, based upon which a feature is selected or discarded. So, it has to be a solid system, right?

Yes, it should be full-proof without a shadow of doubt, however, it may not be and that happens when the units of measurement are open to interpretation. 

When the value of business is given a two star rating, can you be absolutely sure of what those two stars signify? 

Does that rating denote a sub-standard value? 
How does it translate to business profit? 
How do you reach five stars? 

For one person, the value may be clear, but for another it may be muddy; the reason being the difference between people’s perception and there are the cultural differences that also come to play while interpreting. 

Prioritising every vote at the same level 

Continuing on the voting discussion, it is often said that every vote is valued at the same. However, if the person voting is clueless about the feature he is voting on, should his vote have the same as that of a specialist in that area? Think about that for a minute.

Every team has a diversified skill set based on its members. There would be people with technical backgrounds like the developers and there would be people with a not-so-technical background like the marketers. Now you tell me, should a marketer be given the same voting rights as the developer, when the vote is about a technical feature? 

What About the Time and People Constraints?

Like it or not, many a time a feature is shelved not because it was ill-suited, but because the team did not have the time to build it or it did not have the right people to do it. Something like this has happened in every organisation at one point or another. 

Such an incident, when you do not have the right people to execute a feature that you know would do wonders for your project is going to be frustrating, which is understandable. You can’t do anything about it; you can hire a new person, but that could be a whole other task in itself. 

You can think of these constraints as negative or you can look at the silver lining and think of them as another filtering agent helping you prioritise further. Since I am the glass half-full kind, I’d say it is a good thing. 

If you plan out everything in an organised way and your process is full-proof, you have won half the battle. Carrying out its proper implementation would help you over the time and people constraints. If your team agrees to the plan and knows it, your chances of success increase immensely. This also means that the team is able to identify the priority tasks over the non-priority ones. 

The end goal of every project is improvement and it is research and prototyping that make it possible. So, if you have a process to implement those two, no amount of constraints will be able to hold you back. And just maybe, these two constraints help you in avoiding over-reaching?

What are the Ideal Strategies for Feature Prioritisation?

We have learnt everything we can about this concept, now it is time to learn some about the strategies that help project managers implement it. There are a few feature prioritisation frameworks that deserve mention. 

The KANO Model 

The KANO model helps you in understanding the consumer’s needs and wants and base your features on them. This is done through questionnaires and consumer feedback. Although it is a time-consuming process, it does give you a clear picture of where the consumer stands in terms of product features by classifying them. 

According to the KANO Model, the sure thinks in four ways. 

• For one, he wants excitement. These features add no value of the product or service, but their presence is enough to excite the consumer and lure him in.
• Second, he wants an elevated performance. The better the performance of the feature, the better the consumer satisfaction and vice-versa. 
• At number three, he wants the basics. There are certain that have to be there, despite them not providing any excitement to the user, you could refer to them as the threshold.
• Finally, he becomes indifferent. This indifference is towards features, the presence or absence of which does not affect the consumer.

All four of them, with their different satisfaction and functionality levels help the project managers know the strengths and weaknesses of the project.

The MoSCoW Model 

Must-haves; 
Should-haves; 
Could-haves; 
Won’t-haves;  

These four sum up the meaning and the reasoning behind the MoSCoW model. All of them categorise features based upon their importance to the project. Going from the top; 

• Features that have to be in a project to make it complete are the must-haves and should be prioritised over anything else. 
• Features that should be included in the project, but can be delayed for the time being are should-haves, much like green vegetables; you should eat them, but you can survive without them for some time. 
• Features that could be included in the project or could not be included in the project without having any impact on the overall functionality are the could haves. It’s good to have them for higher consumer satisfaction, but their absence won’t be blatant to the consumer.
• Features that are won’t have are the ones that are not at all crucial for the project at the moment and would only cause additional stress on the resources at hand. 

The thing about the MoSCoW model is that it lets you know what kind of features you can bring to the table in the feature. This is because priorities never remain the same, a feature that was shelved for requiring too much work and having too little impact could become a Must-have in the future.

According to OSL's project managers, the success of any given project is primarily determined by the intelligent prioritisation of various tasks. Choosing the right high-priority feature may seem to be daunting, but for successful and timely delivery of the project, this is a must. Neha Grover, one of our Project Managers, feels that during instances in projects when you have the list of work packages, which need to be prioritised and moulded into a work breakdown structure(WBS), the PM has to play a key role in getting the stakeholder's and dev team's expectations and priorities to be on the same page.

"I follow the MoSCoW prioritisation technique in my projects, as this is quite simple and less time-consuming and it focuses on both customers and stakeholders."

The Cost of Delay Model 

It is often said that you can't put a price on time, it is indeed priceless; never to come back again once it is gone. Saying that, if you happen to have the right matrix to work with you can actually value the cost of time or more like the cost of delaying. And that is what this feature prioritisation framework is all about. 

The COD model calculates your losses for delaying the development and implementation of a particular feature. Based upon that cost, you will get an idea as to the importance of that feature and prioritise its build accordingly. 

For instance, 

Say there is a feature that would take 30 days to build and every day it’ll cost the organisation $1000. Then there is a feature that would take the same amount of time to develop, however, it is costing the organisation more than double in comparison every.

In such a scenario, which feature would you prioritise? The answer is simple, the one that is making you lose more money. Building that first would stabilise your losses more than the other as the cost of delaying that was more than the other. 

Prioritise what saves you more money by reducing the cost of delay.

The Value Model 

Businesses develop features because they think the said features would prove to be valuable for them. To get that value, they endeavour to build something good. What if that value isn’t as impressive as the business, the project managers and the developers had thought to be. This is why the value model becomes an important strategy to implement during feature prioritisation. 

The purpose of the value model is to reap the highest value of a feature for the business through its two facets.

Value based on cost 

Cost doesn’t necessarily mean money, it could be interpreted as efforts as well or even complexity. The model states to simply prioritise the tasks with high value and low cost first, then move onto the features with high business value and high cost. If you wish, you can take on the low value-low cost features, but most definitely avoid low value and high cost features. 

Value based on risk

From cost, we come to risk, which is another metric to be mindful of while prioritising features. It more or less works in a similar fashion to the value and cost model, it's just instead of the cost, you’d be focusing on the risk. 

The higher value and low risk features would be prioritised over everything else, while the low value and high risk features would be avoided altogether. This helps in enduring that you are not going to end up building something that is unnecessary or even something that is too simple by playing it safe.

The Financial Model 

An income is what everyone is after and feature prioritisation operates in the same notion as well. The purpose of increasing revenue and reducing costs is omnipresent in all the business decisions and choosing features for a particular project falls under that umbrella. 

So, thinking about the financial side of the features is what the essence of this model is. 

Whether you will be able to generate new income; 
Whether you will be able to enhance your operational efficiency and reduce costs; 
Whether you will be able to lessen the amount of consumer turnover;
Whether you will be able to gain an additional income from the consumers you already have; 

All these are important scenarios to consider in the financial model for feature prioritisation. 

Then there is the actual money metrics to pay heed to in the selection process, which includes three important dimensions. 

• One is the focus on the Present Value of money. What you have invested today and the return you will get from it five years down the line would not be in the same value of currency as it keeps changing. So, making a projection based on the Net Present Value formula is a wise choice. 
• Second is to calculate the Internal Rate of Return, which is essentially a percentage value of returns for a project and how quickly they might increase.
• Third is to focus on the running total of the discounted cash flows to get an overview of the time it would take to get the investment back. This is also referred to as ‘the Discounted Payback Period.’

The Opportunity Scoring Model

For every feature in every product, there are two attributes that usually stand out apart from the financial aspects of that feature. And these are; 

How important the feature or its outcome is to the consumer?
And how satisfied is the consumer with the provided feature?

Take the answers to these questions and start pointing them out in a graph and you will end up with something looking like this. 

So, the scoring makes it easy to prioritise by using visuals and categories simultaneously. The features that are important to the consumer, but aren’t very satisfactory would be priotises more than the features that are satisfactory for the consumer, but not very important. 

The RICE Model  

The RICE Model gives you an in-depth understanding of each feature you wish to implement based upon four parameters that some of the other strategies are unable to. 

Reach 

Reach refers to the number of people the feature would reach and affect. These numbers are calculated on real matrices like ‘customers per quarter’ and ‘transactions per month,’ thereby removing all forms of personal bias from the equation. The higher the resultant number, the further the feature’s reach.

Impact 

The I is for impact, meaning the kind of impact the feature would have on individual users as well as the goals and     objectives of the business as a whole. This is ranked from minimal to medium to high to massive impact based on points from 0.25 to 3.

Confidence 

Now that you have the numbers for the reach and impact of the features, comes the moment to test your confidence in them, that is what the C denotes. Using a scale with 100, 80 and 50 points referring to a high, medium and low confidence level, you will start scoring. Remember to always provide evidence in the form of data for every score you give.

Effort

In the end, the E is for Effort in terms of time and people. Questions like how much time would it take to build the feature. How many people would be required to make it, how much time would one person have to shell out in a day for the build are to be asked and answered in this parameter. 

Once you have the results for all the parameters, you will use this formula and will be left with a number that would denote the total impact of time worked. This number is what would help you prioritise. 

The Voting Model 

This is not a well-established model, but it has a lot of merit in its implementation. Based on two different aspects of feature selection, here is how it is used. 

Annotation 

When you are voting for a feature’s implementation, you would be stating whether that feature should be high on priority or even low, you can’t just say those two simple words; there won’t be any clarity in that. If you are saying that a feature is high impact, then you must state why? It could be any reason, an admin panel with a particular feature could have a massive impact because it would help the stakeholders in completing their primary tasks with ease. A comment can truly make a difference in the perception of a feature and thus, aid the selection process.

Diversification

The second part of the model is to diversify the voting team as much as possible. Include experts in the domain as well as non-experts. This would give you a more concise picture as to the popularity of the feature amongst a wider range of people. However, do remember that you separate the experts' votes from the non-experts clearly, because even though diversified voting helps get a better perception on the proposed features, the expert opinions would weigh more. You can even segregate the votes based on departments, like votes from the finance department’s votes could be one category and marketing people could have a different category. 

Now that you have explored various approaches of prioritising features in a project, read about the right way to start a Drupal project, standard development workflow for a Drupal project, best project management techniques for complex Drupal projects, difference between product mindset vs project mindset and human factor in project management for effective project management.

The Bottom Line 

There are numerous other techniques and strategies that can be implemented for feature prioritisation. You can use all of them or just a couple, that is totally up to you. However, you have to remember that a feature is not just for the consumer and not solely for the business. 

Both the consumer and the business have different reasons for using and building a particular feature. The consumer wants the feature to fulfil a need, while the business wants the feature to bring an increased revenue. So, you have to endeavour to strike a balance between the two. This can be done through choosing strategies that are both business-centric and consumer centric, like the Cost of Delay model or RICE. 

In the end, I just want to say that feature prioritisation is a never ending process much like development. As long as you will keep developing, you would have to choose certain features over others to prioritise. So, mastering the prioritisation technique would serve your interests well.