The right way to prioritize the features in your product
I’ve always loved creating products that solve problems and an important part of developing a product is deciding what features to include. Sometimes, these decisions are made based on competition analysis and sometimes from user research. Either way, when you have a bunch of features design and develop, you must prioritize the features to know where to start and how to go about implementing the features.
Typically, feature prioritization is done on a two dimensional chart like the one below.
By using this chart, you can chart out features that are high priority, features that can be included if time or resources permit and features that need not be or should not be included. When I followed this chart, I had no direction as to where to go from here. I had questions that needed answers.
Do I start with the simpler ones? What is the simpler ones are in the Maybe section?
Is the feature easy to design and develop?
If features are interdependent, is there a way to ensure that they are designed together?
All these questions got me thinking, why not assign a number to them? That way I can rank the features by importance and estimate the work involved in each feature. Here’s how I ended up doing it.
If you can’t measure it, you can’t improve it. — Peter Druker
The Equation
When prioritizing features, I needed to make sure that the effort of and effect on all the people involved are taken into account. For all my UX projects, I’ve always encountered three major stakeholders. The users, obviously, the designers and finally the developers responsible for creating the application.
Now with that in mind, I came up with the following general equation.
In short, this means that the score of a feature is the assigned weight multiplied by the attribute chosen.
Weightage
This is the weightage or importance that we assign to the stakeholder. For this example, I assign the following weightages.
User Demand (U) is how many users wanted the feature, hence the impact of feature.
Design Complexity (D) is the effort that a designer, me, has to put in.
Similarly, Technical Complexity (T) is the effort the development team has to put in.
Keep in mind, that I have taken account only the effect on Users and effort by Design and Tech team since the User has to put in no effort to create the feature and the Design & Tech team has no direct impact from the feature (user satisfaction and higher sales aside :P ).
For the sake of this article and my project I assigned User Demand higher weightage (As we all should), then my (Designer’s) effort and the least weightage to Technical Complexity. Ideally, Technical Complexity should be given more weightage.
From this I derive the following equation:
Design and technical complexity reduce the score because of the effort required.
Effort of/Effect on the stakeholder
I first decide the three levels of Effort/Effect:
High = 3
Medium = 2
Low = 1
For this example, we have already decided that Users will be Affected and design & tech team will put in the effort, so let’s define the levels w.r.t. each stakeholder.
User Demand
How important the feature is to the users
You can further add granularity to this by assigning different levels of importance to different types of users, i.e. expert users etc.
Design Complexity
Determines the cost of designing the feature including time required, design system creation, UI design, visuals etc.
High — Feature requires several custom design elements
Medium — Feature require some custom design elements and some standard kit elements
Low — Feature requires no custom design elements and only standard kit elements
You can add additional criteria like number of team members involved, availability of team and so on.
Technical Complexity
Determines the cost of implementing the feature in an actual application including time required, 3rd party integrations, real-time features, payment gateways etc.
High — Feature involves high cost 3rd party services and high development time
Medium — Feature may involve either high cost 3rd party services or high development time
Low — Features are either shipped with the OS/device or are an extension of it. Ex: Emojis, etc.
Can be included?
For my project I added another criteria to decide the fate of the features. For my project, Can be included? relates to whether the feature can be showcased in the prototype.
Yes — The feature can be showcased in this project
Partially — Only some elements of the feature can be showcased in this project. Ex: voice commands, AR etc.
No — The feature cannot be showcased in this project
Legend
where;
This is a chart from my project where I consolidated the features based on user interview and competition analysis for an application that allows Deaf and Hard of Hearing (DHH) users to communicate with hearing users.
Overall priority is the simple average of the sub-features.
P.S: Although Transcription has higher priority, it should be noted that it is a dependent on Real Time Communication. Read my project for more details.
Conclusion
Using this method I not only know where to start, i.e. Video Chat feature but I also know which components of that feature are critical and which are not.
This is how I visualize prioritizing the feature I want to include. Let me know if you have any questions or comments. :)
