5 min read

The industry has become tired of MVP requirements and the associated bureaucracy and paperwork. Companies want to be agile enough that they can build a solution without any documentation at all. It has got to the stage where even a road map no longer seems important.

But does this approach make sense? Personally, I do not feel this is the right approach.

What are MVP requirements?

The business part

When it comes to MVPs there are several requirements. On the one hand, we have business requirements, which are a description of how you plan to solve your customers’ pain points. Let’s take a look at TikTok, a giant in the entertainment market that rose to success quickly.

TikTok is “The mobile application, that allows users to make and share short music videos”. Whilst this simple sentence contains high-level requirements, it has only a general description of the applications goals and features.

No developer would understand what to do with it and that is the tricky part. A founder sees the product as a whole but to actually build a product you need to know the details for every possible interaction. We refer to these details as “user requirements” and they show us what the user is able to do when using the app.

A good way to document these requirements is to use the ‘event – feedback’ format. This process involves describing every action on each screen of your product, which then goes on to form your technical requirements.

The technical part

The technical or functional requirements include features that developers need to build. To identify these requirements we need to first form user requirements. Everything the user sees hears or interacts with when using a product needs functional requirements.

The registration screen with login/password text inputs and integration with social networks. The video recording feature with the ability to choose video filters. The video editor is able to cut video, change filters, add or delete music background. The integration with the database with free available music.

This is an example of what technical requirements look like. Of course, in the real world, we need to put details for every word. Which filters should we use? What should the functions do? Where do we get the music from? How should the video be recorded? And so on.

Technical requirements also include hardware requirements, including a list of devices with screen resolution, operating systems, and browsers.

Why do you need requirements?

The goal of an MVP

Your requirements will completely depend on the goal of your MVP launching. You need to have a goal for every iteration, because as your MVP concept grows founders often forget the core values of the product.

The second point is much more practical. Your development team needs to understand you clearly, and you must be able to convey your message in a way that is easy for anyone to interpret. In order to attract and assemble the right team, you must work on becoming a good public speaker and also a great recruiter.

Startups are known for their agility and often constant changes, to keep at the cutting edge you must be able to keep up with this tempo. We have created a list of requirements that you may find useful to help you stay on the same page as your team:

Help to build the development process

Define the tasks for your team members

Make sure communication is clear to help prevent misunderstandings

Determine the product features

What to include in your product?

Prioritize

There are a number of approaches that can be taken in order to work out which features should be prioritized. From interview-based to mathematics-based prioritization models, in terms of requirements, prioritization means choosing the hypothesis that most needs to be tested.

The main point of this process is to understand that there are no resources that work with every feature, so we need to implement which approaches will be taken at what stage, in order to ensure maximum value at each point in time.

Prioritization framework

The prioritization for early-stage startups may look like “Go & Ask”. This approach can sometimes work but in the case that your customers have no idea what they actually want, then there are other approaches you can try.

In order to prioritize features, it is important that you consult with all stakeholders from the founders to the investors and even your customers. Thus there are exist over 20 prioritization frameworks to work with every aspect of product building.

I’ve highlighted 2 frameworks, that both efficiency and easy-to-use to implement them into your production process.

Buy feature

The “Buy Feature” it’s a game-based approach to let your customer choose the required features.

You need to assemble a group of your customers and provide them with game-money and a list of features. Every feature has own price. The price is based on how much it will cost and this will depend upon the criteria of developing the feature. This may include the time it took to develop, the number of developers required or the difficulty level of the technology behind the feature. Customers need to buy features they think are important.

There are rules:

Every buyer gets the same amount of game-money. The buyer budget has to be a third or a half of the general cost of all features. When a customer buys some feature, you need to take the money and ask why did they buy it The game is over when buyers have no more money or they have bought all the features the interested in.

Sometimes, it is not an individual that buys the feature, but rather a group, in which case the price is defined by the customers.

MoSCoW rule

This approach is widely used to identify the features that are important for all stakeholders.

All that’s needed is to ask customers to prioritize features themselves from the following categories :

Must have – the most critical features to be included in the current release. Without them, there is no reason to move on.

Should have – important, but not critical features at the current stage. Another way of saying this would be “ nice to have ”.

Could have – these features are not that important but are a secondary level to the “Nice to have” features.

Won’t have – features, that have no use for the product or its development strategy.

This approach is simple and quick, however, there may be issues if respondents couldn’t classify the features correctly and do not see any difference between the must and should have levels.

The 20/80 principle

It is said that only 20% of effort brings 80% of the result. For a digital product, it is important to focus on the core features, since in many cases only 20 % of everything you plan is actually used by the majority of your customers.

Focusing on the core features means you do not disperse your resources. It is important to remember that an MVP is a tool for learning and testing your initial hypothesis and ideas, it is not your finished product. If you test out all your ideas at the MVP stage it is highly likely that you will run out of both money and time before developing your product.

Be progress-oriented

Once you are done with one hypothesis, it’s time to move on to the next. Using the minimum set of functions necessary will give you the flexibility to adapt to various hypotheses. This is the meaning of prioritization.

You can test hypotheses with users only. There are two approaches:

The team makes a list of tasks, develops them and then sends the developments to the users to test for feedback. The team asks users what they are missing and then develops these missing features.

Personally, I recommend the second approach because it reduces the costs of making errors.

Try to always follow the principle of 20/80. Focusing only on 20% of your clients, 20% on the functionality, etc. at any one time. Do not asses every user, but rather spend your time questioning those who are your most loyal customers and have been with you the longest.