In software development, decision-making can sometimes be very complex if it’s an MVP project, even more so. An MVP is characterized by being reduced to just a few essential features that distinguish it from the competition.
But how do you identify the less obvious features in addition to the very obvious ones? In this article, we deal with this question and present five different methods for prioritization.
Why feature prioritization in MVP development at all?
As already mentioned, an MVP is, by definition, a product with a manageable range of features. Of course, the focus is on the feature representing an innovation. But the choice is usually more complicated than it appears at first glance.
If, for example, an app is to be established on the market that digitizes the management of rental apartments, the question arises as to which services the app should contain in the MVP version and which should not (yet): create utility bills, overview of incoming rental income, inventory lists, chat module or Something completely different?
Prioritizing this is not easy. This, in turn, is linked to the questions of what is desired from the customer’s point of view, what is an innovation that creates added value and also purely pragmatic,
The influencing criteria of feature prioritization:
- Degree of innovation: Which features are really innovative?
- Customer needs: What problems do my customers have that I can (exclusively) solve? Which features really add value? Both of these are particularly important. Many market entries fail because they have not found a product-market fit or have misjudged it.
- Costs and effort: What costs and effort do the individual features cause?
- Time: How time consuming is the development of each individual feature?
- Skills: Which skills does my project team have and which do not?
- Competition: Which features do my competitors prioritize?
- Monetization: Which features are customers willing to spend (a lot of) money on and which ones not?
It is important to keep an eye on these criteria in order to then create a list of all relevant features. Practice shows that the list is often extremely long, which does not make the decision easier. With the following five methods, features can be prioritized and thus, a systematic and model-based selection can be made.
Actually, the abbreviation would be MSCW Model; since this is less memorable, the letter O was added twice. So the model is now called after the Russian capital Moscow. The MoSCoW model is relatively simple but effective. It divides features into four criteria:
Must-Have (Mo): The Must-Have functions must be available for the MVP to be functional and compliant with the law. This would be in compliance with data protection regulations for a publicly accessible app.
Should Have (S): These are all features that make the MVP competitive. Making a choice here is much more difficult.
Could Have (C): This means all functions that didn’t make it into the Should Have category but could still be a (somewhat) relevant feature. Could have features are functions that improve a product but do not have a major impact on the purchase decision in detail.
Won’t Have (W): Won’t Have features will definitely not be included in the MVP. These features are intended for the phase when the MVP has become a mature product.
Advantages and disadvantages of the MoSCoW method
The MoSCoW method is very easy to use, understand, and implement. It helps the team to make decisions within a set framework. But the simplicity also has disadvantages: The model is crude. Costs and time are not taken into account. There is no method-based prioritization within the criteria. There is a danger of categorizing too many criteria as must or should have.
Feature Buckets Model
The feature bucket model is popular in software development. It takes customer needs and KPIs into account. The method is based on sorting features into three buckets:
Metric Movers: The bucket contains the features that have a high impact on the KPIs of the MVP project. These can be, for example, Downloads, sales, willingness to pay, etc.
Customer Requests: As the name suggests, the features that customers absolutely want and also expect from an MVP are sorted here.
Delights: Additional features are recorded here that increase the joy of use to a certain extent and are sometimes unusual but still offer added value.
Pros and cons of feature buckets
The feature buckets reveal which features are really relevant for the MVP project and illustrate which bucket contains too many or too few features. The disadvantage here, too, is that no prioritization is made as to which of the features should be started with.
Feature Priority Matrix
Like the MoSCoW model, the Feature Priority Matrix also has four dimensions in which the features are sorted according to their priority. In addition, however, the development effort is also taken into account.
The criticism of the MoSCoW method is taken up here. The Feature Priority Matrix is mapped in a coordinate system. The workload is entered on the x-axis from left to right, and the customer benefit is entered on the y-axis from bottom to top.
Looking at the graphics, it quickly becomes clear what is at stake. The aim is to determine the features that are easy to implement and, at the same time, have a high priority on the part of the customer.
Accordingly, the bottom left features have little or no customer benefit and are also complex to develop. They are appropriately referred to as time sinks. Quite the opposite of the box at the top right.
At the same time, these functions are very useful for customers and relatively easy to implement. They are called quick wins. Very useful but complex to develop features are called Big Bett. Features that are easy to produce but not very useful are called maybes.
Advantages and disadvantages of the Priority Feature Matrix
The Priority Feature Matrix has all the advantages that the MoSCoW model also has. In addition, there is information about which developments should be started on the MVP. Another disadvantage is the coarseness of the model. As a result, the effort estimates may be inaccurate.
Professor Noriaki Kano developed this method. The model named after him serves to put customer satisfaction and customer benefit at the center of actions. The Kano Model provides information on how closely the properties expected by customers match the actual properties. The Kano model is also used in MVP development.
The Kano Model divides features into five categories based on customer value.
Basic features: These are features of the product that customers take for granted. If the product didn’t have these, it wouldn’t even meet the minimum requirements. With smartphones, for example, it goes without saying that you can use them to make calls and install apps on them.
Performance features: They are also referred to as quality features. They have a major impact on customer satisfaction. Performance features are also used as a comparison by the customer when choosing between several products. With a smartphone, this could be the quality of the integrated camera (megapixels, number of lenses, light intensity, etc.)
Enthusiasm features: They summarize features that customers did not expect but, as the name suggests, inspire them. In the case of a hotel stay, this could be a fruit basket that is placed in the hotel room every day. The guest did not expect it but is all the more pleased about it and, if possible, only books hotels of this brand on their next trips. (So the wishful thinking about enthusiasm features)
Insignificant features: These refer to features that have little or no impact on customer satisfaction. For example, the color of towels provided by a hotel will be this for many people.
Rejection features: These are features that are the reason why a product is not bought. For example, when a smartphone has extra thick glass to protect the display, the sensitivity of the touchscreen is too low.
How is the data for the Kano Model obtained?
Data is collected either through interviews or by the respondents completing a questionnaire. It is asked how the customers perceive a feature or a feature. The possible answers are:
- I would be very happy about that
- I assume so
- I don’t care
- I just accept that
- That would bother me a lot
Dysfunctional questions can also be used, such as: How would you feel if the product did not have property xy?
The results are then aggregated to get a grand total and then plotted on a chart for visualization.
Advantages and disadvantages of Kano
Kano has the user’s interests fully in focus. The model is a good method for evaluating individual features in terms of their added value from the customer’s point of view. In MVP and general product development, competitive advantages can be identified, and customer segmentations can be carried out based on their preferences.
However, due to ever shorter product life cycles, high levels of competition in many markets and technical progress, features that customers see as exciting can quickly become a performance or even basic features. The project teams have to be very careful here. Kano is also not ideal for very new products. Due to the lack of experience, test persons find it difficult to assess which features they prefer.
User Story Mapping
User story mapping is a very common method in product development, especially in app development. When it comes to user story mapping, the focus is also on the customer perspective. User stories are visualized through the mapping and show the user’s path to a specific goal.
The linchpin is already formulated user stories of the personas. The goals are at the top. Below comes the backbone with a description of the activities and tasks that need to be done from the user’s point of view to achieve the goals. Below the backbone is the body map with further details on the activities.
The more important the tasks for the functioning of the MVP, the higher they are. With a horizontal line through the map, you can easily determine which feature will be included in which release.
Advantages and Disadvantages of User Story Mapping
A big advantage is the visualization of user activities. This is how you keep an overview. Errors / missing aspects are quickly identified. The focus on users is also a strength – their needs are definitely taken into account. For the MVP, it is also determined in a comprehensible manner which features the MVP should contain. The disadvantage is the effort involved in serious implementation.
Conclusion and tips Methods for MVP prioritization
The methods presented could be supplemented by numerous others. Especially Kano and User Story Mapping are in high demand. They have a very strong focus on the user, which is an important condition for developing a marketable product beyond the MVP.
However, the project team is at least as important as the methodology. No one person should be solely responsible for MVP prioritization.
A team — preferably heterogeneous — should deal with prioritization. Specific tips for feature prioritization can usually not be made. Fortunately, more and more users want products that are manufactured fairly and environmentally friendly or avoid brands that don’t. We, therefore, like to give a tip to include socio-ecological aspects in the feature prioritization.
All models focus on qualitative methods for decision-making. Due to the aggregation, the Kano model has a quantitative component. For a more precise prioritization or for market research purposes, the survey could be supplemented with conjoint analysis.