Ok, so you stumbled upon the idea that looks cool and promising. You think that it is good enough to turn into some product. And you decided you'd be building an MVP to test your idea. What do you include into it? What should be left? How big the MVP should be? These are the questions you'll be asking yourself.

As product developers on a budget, we are constantly asking ourselves these questions. We just cannot afford to spend an excessive amount of time on something that might not turn out to be true. So let's dissect the thought process that goes into answering these questions.

Who are you building your product for?

First and foremost you need to decide, are you the target user of the product or is this someone else? The reason why this question is so important is that it determines the length of the feedback cycle that happens as you develop your MVP (and then your product), and also the quality of the insights you get from this feedback.

You are the target user of your product.

If you found yourself desperately needing some product that does not exist yet and decided to build one, my congratulations — you are having a luxury of accessing the deepest insights about target user's needs — your own. Now your task is to use these insights to your advantage and build the product that will satisfy your needs first. Some of the questions that will get you closer to this goal:

  • What is the problem that I have?
  • Is there any product on the market that solves it?
  • If there is some product, why am I not using it?
  • Is it too expensive? Is it hard to use? Does it solve my problem by creating some other problem? Maybe it's inappropriate to use this product given my circumstances?
  • If there are no products that solve my problem, maybe there is a combination of different products, that could?
  • Why am I not using this combination then? Maybe it's too hard or impossible to combine the two together? Or the combined cost is too high? Or this combination creates some other problems I need to deal with?
  • What if I could tweak some existing product to work better for me? What if I could combine some existing products in a meaningful way?
  • What do I like about existing products that I want to keep?

All of these and many more similar questions will get you closer to the understanding the core features of the product. Then, when you have formulated the list of features that your product might have, ask yourself one more question:

  • Can I fulfil my needs if my product didn't have this feature?

The answer to this question will help you to split the features into two buckets: the ones that are core to your product and should be part of your MVP and the ones which are just nice to have. Then take the first bucket and build.

This all may seem daunting at first but in fact, if you truly find yourself in a situation where you are the target user, then all of this happens naturally, and, for the most part, subconsciously. You think of something and then immediately understand, why this may or may not work for you.

You are building a product for someone else.

This is by far the most common way to build products and as a result, there is a ton of books and research about how to create products in a most efficient way. The objective is similar to the previous case — to provide a solution to the problem someone has in particular circumstances. But the means to get there will be slightly different because you no longer have access to your own insights.

The popular theory of jobs to be done says, that no one actually buys products per se, they rather hire the products to make some progress in their circumstances. Therefore you have to approach the definition of your MVP and your product from a slightly different perspective. You still ask the aforementioned questions trying to pinpoint the user's needs. But you should not take user's words for granted. Oftentimes what user think she needs is not what the actual need is. So in addition to asking these questions, you have to observe the users behaviour as well. And once you have some observation data and you see that this data does not align well with what users were saying about their behaviour, you're in a great position to ask more questions and get deeper insights. Which in turn will result in a much better understanding of the features, that are really important to your users and should be a part of your MVP.

What should be in your MVP? Features that are essential to get the user's job done.

What should not be in your MVP? Anything, that is just nice to have.