How to Prioritize the Feature Development after You’ve Built an MVP
Every company realizes the necessity to prioritize future development after the first steps are done. Moreover, it is one of the top concerns for most CEOs, CTOs and Product Managers at the post-MVP stage.
Many companies make the huge mistake of neglecting this process and trying to put every feature they come up with into the app. Finally, it seems that they have a great multi-functional app, but the reality is totally opposite. Prioritization is a big concern for all Product Managers (image by Saba Talat)
They’re just inventing a bike no one wants to ride. Potential users leave the app without any understanding of how to use it, DAU drops and Investors stop being happy.
But you won’t this to be your case, right? So what is to be done?
🤔 Why Do You Need Prioritization?
Young startups often don’t notice the benefits of app development prioritization despite they are obvious. First, it helps you to achieve your business goals in a shorter time and with fewer efforts. Depending on the segment in which your company works (B2C, B2B or B2G), the right approach to prioritizing will let you increase:
retention;
MAU and DAU rates;
session length;
user LTV;
number of paying users or customers.
So, basically, the project prioritization process looks as follows:
Define the most important strategic goals which you want to achieve with your next release. What are your KPI’s and which of them do you need to increase first?
What tactics are you going to use? Come up with the list of features/improvements that will help you to increase the chosen KPIs most effectively.
Think how to implement these enhancements with the least effort and cost.
It's always important to define your strategy and tactics (image by Kaitlyn Irvine)
Let’s imagine that you’re an owner of a retail cosmetics app. Then:
Your strategic goal may be to improve the UX and increase the user LTV by 20%.
Your tactics, in this case, will include implementing features that can contribute to your strategic goal. For example, you may consider a few options:
to add a special “sales” screen and encourage people to make spontaneous purchases;
to enhance the search feature by adding the possibility to sort and filter results (it will increase chances that your customers will find what they were looking for and buy it);
to implement AR technologies so that users can try products using their front-facing camera.
Finally, you should estimate which feature from the list above will contribute the most to your goal and require the least resources for implementation.
But you may say, this is too obvious and a simplistic view which lacks many important details, right?
Read on, because now we’re going to share some tips on building your software development prioritization strategy.
Yet, if you want to jump to our 8 practical methods on building your prioritization plan correctly, just click here.
📖 How to Prioritize Development: Basic Rules
Rule # 1: Know Your Business Well
If you want to prioritize product development, you should be an expert in the field of your business. Here are a few tips that will help you to get maximum out of your post-MVP development.
First things first. Define your aims.
So as to arrange your future app improvement, you should clearly understand what goals you pursue. Usually, they are based on the KPIs of your app (we’ll talk about it a bit later). Yet, as a rule of thumb:
The ultimate goal for free apps (for example, chatting ones) that make the revenue from targeted ads is to increase the number of active users, retention rates and session length.
Apps in the B2B/B2C segments are usually aimed at getting first paying customers (or increasing their number if you already have some) + getting higher average revenue per user.
Of course, each case should be treated individually, cause everything depends on your business aims and the current state of your mobile application. That’s why it’s important to define which goals are most important to you at this exact moment.
Learn from the best.
Back in 1996, Steve Jobs said: “Picasso had a saying — “good artists copy; great artists steal” — and we have always been shameless about stealing great ideas”. We don’t encourage you to steal, but we see nothing wrong in learning from the best. There is nothing bad in learning from the best (image by Zaib Ali)
Take a look at startups and companies that have already done a great success in your industry. If you can - carefully study their way, notice how they scaled, added new features and deleted the unpopular ones, changed interface elements and improved UX. Sometimes it may be very useful to follow their example without making their mistakes.
But never forget, that each growth way is unique - and so will be yours.
Rule # 2: Analyze the Most Important KPIs and User Feedbacks
If you are looking for objective indicators of the success of your Mobile Project, pay attention to KPIs (which are also known as key performance indicators). These are the most important metrics that can tell you how your app is doing and what is to be improved:
Number of downloads.
Retention Rate that shows whether people are coming back to your app again and again or no.
DAU and MAU — daily and monthly active users.
Session Length.
LTV or Average Revenue Per User.
App UX Heatmap - which screens users usually spend time on, what buttons they press the most often and so on).
Your app development prioritization will greatly depend on the KPIs that you want to improve. Moreover, we recommend you to set clear and measurable aims. Instead of “increase the number of DAU” in general, set something like “increase the number of DAU by 65% in 3 months” or “attract 10,000 users through FB Ads Retargeting”. Always pay attention to the most important KPIs (image by 3magine)
Pro tip: it’s known that young startups are constantly looking for new sources of financing. Thus, the attraction of investors is one of the top goals for them. That’s why it may be reasonable to pay more attention to the metrics that mean the most for investors - ARPU (Average Revenue per User), Retention Rate, New User Acquisition, Churn Rate and others.
Thus, consider them as the most priority ones to show growth at the next pitch in front of your investors.
Yet, while KPIs allow you to work with rough numbers, you should pay attention to another important “metric” — user feedbacks. There are plenty ways to collect them — read the feedback section in Apple App Store and Google Play, get them on your email or extract right from the app after using special tools.
In their feedbacks, users often highlight:
bugs which they’ve noticed;
what they like about the application;
what they don’t like about it;
what they’d like to see in the next releases.
Also, using such tools as Flurry Analytics or Google Analytics you can add event triggers to your app and discover how your users progress through specific paths within your app. Sometimes you will get the understanding that people not always know how to use the app correctly. Don’t panic. By analyzing this data, you will be able to fix this and make your application more comprehensive.
Since you’re developing your app exactly for your users, their feedback may be the most trustworthy and vital source of ideas for the post-MVP development.
Rule # 3: Consider Opinions of All Participants of the Project Prioritization Process (and learn to write User Stories)
Despite the project task prioritization is usually done by a specific person (Product Manager, CEO or CTO), this should always be a result of teamwork. Who are the members of such a team? Here they are:
Product Manager (or/and CEO) who clearly understands your business goals and the main idea behind your app.
CTO and your development team that can estimate how much time and effort development of each feature will take.
Users and customers since they’re your main consumers.
Investors who fund your project and are interested in the maximum ROI coefficient.
It’s also important to mention user stories at this stage. What is it?
User stories are simple and brief descriptions of features from the perspective of the person who may be using your app. Any team member can write them, but usually it’s a product manager and product owner who do this. The common templates look as follows:
As a [type of user], I want [a goal] so that [a reason].
As a [type of user], I can [a goal].
Few more examples of user stories (image by Miguel Solorio)
For example, imagine that you are building a food delivery app. Here are a few examples of users stories that will be relevant in this case:
As a user with specific preferences (vegetarian, for example), I want to filter restaurants so that I can narrow down the search results according to my preferences.
As a courier, I want to use live directions so that I can get to the drop location without using any additional apps.
As a restaurant manager, I can upload the photos of our dishes.
As a user, I can pay right in the app.
User stories help you to look at the development from the perspective of your target audience. Thus, it’s better to include them in your project prioritization process.
Rule # 4: Create a Backlog
The Project Backlog is a concept from Agile development methodologies that is used to capture all the tasks before assigning priorities. The backlog is the source defining the scope of work.
It’s usually organized as a list (a text file, an Excel document, a list in Trello or even a set of Post-It notes) of tasks and features for the further development. Sometimes backlogs consist of users stories, like in this example. (image by Janko Jovanovic)
This list should be flexible. Feel free to remove items that don’t contribute to the goal and add new ones which at one point become more important. Moreover, sometimes you will have to shift priorities due to unforeseen changes.
Rule # 5: Prioritize at a High-level and Then Concretize Your Aims
Generally, you can split your software development prioritization into two parts.
Firstly, prioritize your general aims. Do you expect to increase the retention rate or the session length? What KPIs are more important to you and your team at the current stage? Of course, you would like to improve all the metrics but as they say “if you run after two hares, you will catch neither”.
After you have defined your ultimate goals, move on to the tactics. Which features and tech improvements will help you to achieve the planned result?
For example, if you need to increase retention rates, it’s an obvious solution to implement push notifications. Yet, they won’t help you much if you need to increase session length.
So just remember this simple rule for feature prioritization: first you set high-level goals and then come up with smaller solutions to achieve them. That would be the project task prioritization in a nutshell.
8️⃣ Practical Ways To Prioritize Product Development
We promised to provide you with 8 methods that will help you to define which tasks deserve your attention right now and which ones can wait a bit more. As a rule of thumb, they can be split into 2 groups:
Quantitative — the ones that operate with numbers and figures, and can be calculated using special formulas.
Qualitative — the ones that rely on opinions from your team, experts, users and don’t involve any metrics and calculations.
Let’s take a closer look!
Quantitative Methods
The 100-Dollar Test (Cumulative Voting)
This is one of the most straightforward and simple methods to prioritize product development that won’t take much time or effort. So what is the workflow here?
Create the list of features for prioritization (a Backlog, in other words).
Define who your main stakeholders are.
Ask them to vote and gather the results.
The voting system is simple as that: each participant is given the equal amount of units (points, dollars whatever). So, basically, they just have to distribute them between all the possible options. Then you have to sum up the answers of all stakeholders and you will have a formed list of features to develop for the next update. Look at the example below:
As you can see, after applying this method (in the very simplified form, though) we discovered that it’s most rational to develop features in the following order: 3 ➡️ 4 ➡️ 1 ➡️ 2.
Semi-quantitative Analytical Approach (or Value-Cost-Risk Prioritization)
This method is more difficult than the previous one but it can also provide you with a more detailed analysis considering such characteristics as value, cost and possible risks.
For the best result, it’s also recommended to involve 2 different groups of participants: one from the customer side which will estimate “value” characteristics, and development representatives.
After you created the backlog and organized the team that will do the estimation, these are the steps you should follow:
Value (the business side)
Ask your customer representatives to estimate the relative benefit of each feature on the list. Benefit indicates alignment with the business requirements of your product. In other words, it shows how much the feature can contribute to improving the chosen metrics.
Determine the relative penalty for each item from your backlog. To do this, answer the question “How much will my product lose without this feature?”. For example, if you’re building a doctor app, you should be sure that it complies with privacy and security standards. This isn’t going to improve any of your metrics, so the relative benefit of this feature may be pretty low, but the penalty for not implementing it is extremely high since your app may be banned.
So the total Value of the feature is calculated by summing the relative benefit and penalty. It’s also possible to get the percentage of the product value by dividing the value of a particular function by the total score and multiplying it by 100.
Relative Benefit 📈
Relative Penalty 📉
Value 📊
Value %
Feature 1
7
2
9
19.1
Feature 2
3
2
5
10.7
Feature 3
6
6
12
25.5
Feature 4
2
8
10
21.3
Feature 5
8
3
11
23.4
Totals
26
21
47
100%
Cost-Risk (the development side)
Ask your development representatives to estimate the cost of implementing each feature. In other words, they should define how difficult, time- and effort-consuming it is to include the feature into the app. This may depend on factors like complexity, ability to reuse existing code, levels of testing needed and so on.
When estimating the risk of implementation, ask your team to consider concerns about the availability of the needed expertise, feasibility, the use of unfamiliar or unproven technologies and tools.
After all the points are distributed, you will be able to calculate the percentage as in the previous table.
Relative Cost 💵
Cost %
Relative Risk ⚠️
Risk %
Feature 1
3
15.7
2
13.4
Feature 2
2
10.6
1
6.6
Feature 3
7
36.8
8
53.4
Feature 4
2
10.6
1
6.6
Feature 5
5
26.3
3
20
Totals
19
100%
15
100%
Priority
The final step in this software development prioritization approach is rearranging features according to the level of their priority. The formula is simple as that:
Value % / (Cost % + Risk %)
Let’s briefly check how it works with our previous tables.
📊 Value %
💵 Cost %
⚠️ Risk %
Priority
Feature 1
19.1
15.7
13.4
0.656
Feature 2
10.7
10.6
6.6
0.622
Feature 3
25.5
36.8
53.4
0.282
Feature 4
21.3
10.6
6.6
1.238
Feature 5
23.4
26.3
20
0.505
For example, calculations for the feature 1 are: 19.1 / (15.7 + 13.4) = 0.656
Finally, you have to consider the result from the last column. It will help you to define the most valuable features that require least efforts to implement. In our case, it’s obvious that you should continue your app development with the features # 4, # 1 and # 2 first.
Despite this model is based on rough mathematical calculations, it’s also limited by the ability of your teams (customer and development ones) to correctly and fairly estimate the penalty, benefit, risk and cost for each feature on the backlog.
Scorecards
If you want to pay more attention to different KPI metrics, the most preferable way to prioritize product development is by using scorecards.
First of all, you should with the main stakeholders agree on criteria and their weights (how important it is to improve the following metric by the next release).
Category
User Experience 😎
Session Length ⏱️
Retention Rate 🔄
Operational Efficiency 📊
Total
Weight
20%
40%
25%
15%
100%
After that you should decide how strong the impact on each category after the implementation features from your backlog will be and assign points accordingly (the higher impact is, the more points you should give).
Category
User Experience 😎
Session Length ⏱️
Retention Rate 🔄
Operational Efficiency 📊
Total
Weight
20%
40%
25%
15%
100%
Features
Score
Priority 🥇
Feature 1
4
3
4
1
3.15
Feature 2
3
6
5
2
4.55
Feature 3
2
3
3
7
3.4
Feature 4
7
4
4
2
4.3
The formula for calculations is pretty comprehensive:
score * % of the category + score * % of the category +... = priority
For example, for the Feature # 1 it looks as follows: 4x20% + 3x40% + 4x25% + 1x15% = 3.15
This app development prioritization model is interesting for us because it pays more attention to different KPI metrics than other methods. It allows you to prioritize your feature development according to the business goals that you want to achieve with the next app update.
Qualitative methods
Classification Ranking
The most simple, straightforward but, frankly speaking, not very accurate method to manage your development queue. It’s based completely on personal opinions and suits only small internal projects.
The main idea is to classify the features into different categories (for example, High/Medium/Low Priority) without any calculations but according to the views of the Product Manager, CEO or CTO.
High Priority 🥇
Medium Priority 🥈
Low Priority 🥉
Feature 2
Feature 1
Feature 4
Feature 6
Feature 5
Feature 3
The Kano Model
The question “how to prioritize development?” was a matter of concern back in the XX century as well. Japanese researcher and consultant Noriaki Kano presented his model of prioritization that was deeply based on the customer feedback.
For this purpose, he proposed to use 2 dimensions:
satisfaction — goes from frustration to total excitement about the feature;
functionality/investment — indicates how much efforts and time we have to spend to build it or how well the features are implemented.
Main dimensions in the Kano model
Depending on how much the feature affects these both dimensions, it can be classified into 1 out of 4 categories:
Performance — the more of the feature you have (or the better it is), the higher the satisfaction is. Think about your smartphone battery life, internet connection speed, storage space on the device — these are vivid real-life examples of a Performance attribute.
Must-Be — the group of features that are expected by users. Their presence in the application won’t increase the satisfaction of your users, but their absence will definitely make users dissatisfied. For example, if you’re building a hotel booking app, your must-be features are searching, the ability to browse more detailed info about the hotel, the support of the photo gallery and others.
Delighters — unexpected features that greatly increase satisfaction. Think of Stories in the Instagram app or Lenses in the Snapchat app.
Indifferent — features that have no impact on satisfaction. Their presence doesn’t make users happier as well as their absence doesn’t make them feel worse about your app. These are the features that you should avoid working on.
The Kano model as it is
To decide which category fits the feature the best, you should use the Kano questionnaire. You should ask your customer how they’d feel if they had the feature and if they didn’t have it.
Possible answers are:
Like it
Expect it
Don’t Care
Tolerate it
Dislike it
For each answer-pair, you can use the following table to determine the most appropriate category for the each feature:
Opinion
Like it
Expect it
Don’t Care
Tolerate it
Dislike it
Like it
Q
D
D
D
P
Expect it
R
Q
I
I
M
Don’t Care
R
I
I
I
M
Tolerate it
R
I
I
Q
M
Dislike it
R
R
R
R
Q
Q - Questionable. P - Performance. M - Must-Be. D - Delighters. I - Indifferent. R - Reversal: reactions are either to like not having the feature or to dislike having it.
The general rule for feature prioritization here is simple as that: Must-Be features ➡️ Performance ➡️ Delighters ➡️ Indifferent.
MoSCoW analysis
The MoSCoW method is another pretty straightforward way to decide which things should go first. The term is an acronym with each capital letter standing for the possible category.
So the main app development prioritization categories in this model are:
Must be — the most essential and critical features of your product. Without them, the whole release may be considered as a failure.
Should be — important “nice-to-have” features that definitely should be in your app. If you don’t implement them now, they will become “must be” for the next releases.
Could be — not necessary but still desirable enhancements to the product. They are usually implemented if there are some resources left after implementing all the “must be” and “should be” improvements.
Won’t be — the least important enhancements that should be dropped or reconsidered for the future releases.
This model offers you a simple and quick solution, yet, it’s strongly built on personal opinions of your Product Manager and other stakeholders or team members.
AARRR Approach (Pirate Metrics)
These metrics were first introduced by Dave McClure especially for startups. In the center of it, 5 main stages in the customer lifecycle lay:
Acquisition: users explore your app for the first time.
Activation: after they enjoyed the first visit, they sign up.
Retention: people come back to your app multiple times and start using it regularly.
Revenue: users turn into paying customers, their activity leads to the revenue.
Referral: people like your app enough to recommend it to others.
When thinking how to prioritize development, associate the features with one of the stages. For this purpose, it’s enough to answer 2 questions:
What are the business goals that you want to achieve with the next release?
Which features will possibly have the greatest impact on that goals?
This project task prioritization model is good for early-stage products, so it suits MVPs pretty well. Its advantage (and, in some cases, disadvantage) is that it brings business-aligned and single-minded focus to your software development prioritization.
Story Mapping
Finally, we want to share with you the approach introduced by Jeff Patton in his article. The main idea behind it is to replace the standard single-list backlogs with the ones which have a richer structure. Let’s review the essential points of this model.
Story Map is usually organized as the field, delimited by the two axises:
The horizontal one represents the usage sequence. In other words, the tasks (or users stories that we’ve mentioned earlier) are put along the horizontal axis in the order in which they are performed.
The vertical axis indicates importance, criticality. The higher task is placed, the higher priority it has. If some tasks have an equal priority, they can be placed in one line.
You can also divide tasks by vertical lines into special sets — Activities. They just compose the major attributes of your app and help to connect smaller tasks into one group. For example, an activity may be “hotel search” with “price filter” and “search by keywords” being more specific tasks.
The structure of a story map
Story map is a great visual tool that helps to share a common understanding of app’s whole structure. You can divide the field using horizontal lines to define releases. Eventually, you’ll get the end-to-end version and vision of your product. This will lead to faster market validation and delivery, what is especially crucial at the MVP stage. Release planning with story maps
📚 So Which One Should I Choose?
None of the methods that we described can be called as a bad or a good one. The same approach may work perfect under the certain circumstances and be ineffective in another environment. Yet, here are some recommendations by the Stormotion team that may help you to make the right choice:
Method
The size of the project (the number of features in the backlog)
The size of team participating in the prioritization
Additional details
Classification Ranking, MoSCoW Analysis
Small or Medium (up to 6-10)
Single Person / Small Team (up to 5-6 people)
-
The 100-Dollar Test, Scorecards
Small
Small or Medium Team (6-10 people)
-
AARRR Approach
Small
Single Person / Small Team
For early-stage, business-aligned products
Story Mapping
Medium (6-10 items) / Big (over 10 items)
Single Person / Small or Medium Team
Best to get the end-to-end version and vision of your product and plan a few releases beforehand
Semi-quantitative Analytical Approach
Medium / Big
Medium or Big Team (over 10 people)
Pays equal attention to both business and development sides
The Kano Model
Medium / Big
Single Person / Small Team
Involves your users, based on their opinions
Before we move on to the conclusion, we also would like to share with you a few tools that may come in handy when you have to prioritize product development at the post-MVP stage.
Trello — a great tool for the project management with the help of boards and cards.
ClubHouse — another project management software but with a wider set of functionality.
Liquidplanner — a useful tool which pays much attention exactly to the prioritization.
Aha! — a roadmapping software for PMs.
ProdPad — a project management software with tools for the deep interaction with your customers.
💡 Conclusion
These were insights on how to prioritize development by the Stormotion team. The main rules you should follow to succeed are:
Know your business well and set measurable aims.
Analyze the most important KPIs and user feedback.
Consider opinions of all participants of the project prioritization process.
Create a backlog.
Prioritize at a high-level and then concretize your goals.
It’s also possible to use development prioritization models that rely on different approaches:
Quantitative methods:
The 100-Dollar Test.
Semi-quantitative Analytical Approach.
Scorecards.
Qualitative methods:
Classification Ranking.
The Kano Model.
MoSCoW Analysis.
AARRR Approach.
Story Mapping.
Stormotion is a niche Mobile Agency, aimed to help Startups to Develop & Improve their Apps - working side-by-side with your In-House Product Team. We're happy to support you and bring your startup to the next level.
{"value":[4.2,4.8],"count":[2,46],"from":"2018-02-19"}
quote
Discuss your Startup Roadmap with us!
Rate this Article:
(46 ratings, average: 4.8 out of 5)
Thank you for your vote!