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.

Take a look at startups and companies that have already done 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 Feedback

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”.

---

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 feedback, users often highlight:

• bugs that they’ve noticed
• things they like about the application
• things they don’t like about it
• things 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 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].

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 further development. Sometimes backlogs consist of users stories, like in this example.

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.

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)

1. 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.

2. 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.

3. 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.

 

• Cost-Risk (the development side)

1. 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.

2. 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.

3. After all the points are distributed, you will be able to calculate the percentage as in the previous table.

 

• 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.

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).

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).

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.

 
 

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 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.

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.

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:

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.

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.