When you’re planning the development of your app, you may find yourself falling into one of the traps of app development, such as the One-more-Feature. You want it to be perfect, so you’re thinking of all the cool features that would help to achieve this perfection, and so the list keeps growing. You know what they say: more is more, right? Well, no, it’s not. There are features that are certain must-haves but there are some that will be just useless. Instead of implementing every possible suggestion, you should focus on the right time to quality ratio. Prioritizing the features for your minimum viable product is the key.

In our article Things to know before you make an app, Mateusz Mach, CEO at Five App, says:

We spent a huge amount of time making additional features for the product before we even showed it to the public. Every person with whom I talked brought up something else and to satisfy their needs, we tried to implement as many suggestions as we could. Finally, the app premiere was delayed by two months and after gathering feedback from our real users, we completely pivoted and changed the direction of development. MVP of the app on one operating system would be just enough to verify our idea. The sooner, the better.

So how do you prioritize features for a minimum viable product?

With the commander’s intent.

Commander’s intent describes military-focused operations. It is a publicly stated description of the purpose of the operation and key tasks to accomplish. It plays a central role in military decision-making and planning. Why? Because it helps to keep the goal in mind and answer the questions that appear on the way to achieving it.

Do you know Southwest? If you live in the USA, you surely do. If you live in Europe: this is the father of all Ryanairs, Wizzairs, and other cheap airlines. Their core idea is to be “THE low-fare airline”. And this single line is enough to make the decisions about any additional services that they would like to add.

So when a person from the marketing department says that her surveys indicate that the passengers might enjoy a light entree on the Houston to Las Vegas flight, the only question that needs to be asked is whether it helps the company achieve their goal and be “THE low-fare airline”. If it generates an additional cost, then the answer is no.

When a cabin crew asks if they can sing “Happy birthday” to a flight attendant during the flight, it’s fine because it does not generate any additional cost (so it’s not contrary to the company’s core idea). But if they would like to throw some confetti, it would create some extra work for the cleanup crews (and extra work means extra time and higher fares), it’s not ok anymore.

When prioritizing features for your product (let’s not call it an MVP, at least for a moment), it’s exactly the same.

Read also: 5 things you need to do before you start software development

The features you want and the features you need

Let’s say you want to make an app for scheduling appointments. Your core idea is to make scheduling easier for your prospective customers. Now, let’s think about the possible features. Write them all down and ask yourself a question: How much do I need it now? What you want and what you need is not always the same.

  • Integration with Google Calendar / Outlook Calendar / iCal?

It will surely make scheduling easier.

  • Time zone synchronization?

Definitely!

  • Manual availability settings (so that users can decide that they want to have meetings only in particular hours)?

Of course!

  • Buffer time between the appointments?

Useful if your users would like to have at least a small break between their meetings.

  • Custom look of the calendar?

Well, it doesn’t improve the process of scheduling in any way. Not necessary.

  • Payment options to allow users paying for your service?

Pretty important but unless you confirm that you are able to find any users, it’s rather useless.

  • Automatic generation of invoices for the users who are using the paid plan?

You will worry about it once you have enough users who pay, and in the meanwhile, you can do this manually. Right now, this would not make scheduling appointments any easier.

  • Payment options (for instance, for the doctors, who would like their clients to pay for the visit in advance)?

It won’t make the process of scheduling any easier – it can wait.

You get the point, right?

Right now, it’s important to choose which of the important features that passed the “commander’s intent” are the most important ones. And here I would like to stop for a moment and discuss what a minimum viable product is. Because unlike the common belief, MVP is not the first version of your product.

Read also: Why do you need innovation workshops?

Minimum viable product is not the first step

A minimum viable product is when the market decides that your product solves an important problem – and is ready to pay for that. At this stage, you should be able to prove that you are able to scale your sales, access new users in a repetitive way. This means that you do NOT start making your app with an MVP. It is quite late in the whole product development lifecycle and before you get that, you should have some core features built already.

Before an MVP, there is a feasibility study, there is a proof of concept and there is a prototype.  If you want to get familiar with the whole process, I recommend you take a look at this ebook: Software development – step by step.

When prioritizing features for the early stages, you need to start with the core. Let’s go through our features list again:

  • Integration with Google Calendar / Outlook Calendar / iCal?

If it doesn’t integrate with your users’ calendars, the app is useless. Then it’s very important! But maybe it would be enough if it integrated with one of these calendars only? For the very beginning, of course. Find out which calendar is the most popular among your target group and start with this one. The others can wait.

  • Time zone synchronization?

If it doesn’t synchronize, it will cause a huge mess. Your users won’t be able to recognize the value brought by your product. You surely need it asap.

  • Manual availability settings (so that users can decide that they want to have meetings only in particular hours)?

Well, it seems quite important but I imagine that it can be skipped in a proof of concept. If the user puts anything in his calendar in the hours when he doesn’t want to have meetings, it will work anyway. Not very convenient but possibly good enough

  • Buffer time between the appointments?

It’s sure useful but not that necessary. The app will work without it.

You see? We’ve started with a list of 8 features. At first, we struck off half of them for a prototype. Then, we struck off another 2 for a proof of concept. And this is how we prioritized the features.

Prioritizing the features is crucial for the successful development of a minimum viable product. It’s understandable that when you’re designing your app, you’re thinking about literally everything, including all the what if’s. What if we want users to be able to do that on their own? What if we need to accept payments like that? What if we want companies to be able to create profiles?

This thinking is quite natural in the beginning. You have to escape it, though, as some of the wonderful features are stopping you from launching your app on time. Don’t let the cool stuff slow you down. It can all wait for the right time.

minimum viable product case study