.jpg)
Tech concepts often turn into popular, massive, mainstream buzzwords that millions of people repeat without knowing exactly what they mean. Sometimes they even change or develop variants that add confusion to the significance of the original concept. That definitely happened in the case of MVP: the minimum viable product, the idea that made the tech industry such an efficient and disruptive one.
Now that lots of companies use this concept –actually, they’ve been using it for several years–, critical voices have developed that state that creating an MVP isn’t a good idea. Usually, MVPs are lousy products that won’t really engage users nor solve their problems. These skeptical people have coined the term MLP, minimum loveable product, for example, the most simple product that your users will love. We believe that this concept faces a tremendous challenge from scratch: whereas the idea of viability is an objective, data-driven, even technical idea, the one of lovability is pure subjectivity, interpretation, and uncertainty.
However, it’s true that sometimes MVPs aren’t actually well built. Many companies say “let’s create an MVP to test our idea!” like they were saying “let’s make coffee!”: it’s not an instantaneous thing that just pops up. Good MVPs require a small but thoughtful amount of features and that only is something that needs to be critically cared about. But that doesn’t mean they’re worthless to build: the idea of creating a small product that will evolve into something much greater is fundamental. And it’s not actually something that tech companies invented: all of humanity’s creation started like this. Think about cars, airplanes, TVs… everything started as an MVP.
That’s why MVPs are super-necessary and they must be done right. Here we’re going to present you some things that you should always bear in mind when you’re defining the features of your MVP:
You probably know this: every product starts with a value proposition. And that value proposition should involve a story: who, when, why and in what contexts your product will be used. Every product wants to solve a problem, that problem exists in the real life of people, and people don’t just magically say “I will use this app to solve my problem”. Maybe they don’t even know that they have this hypothetical problem.
Here’s where the story comes in: write down the most important of all problems that your app is going to solve and list all of the steps that a person would have to make in order to overcome them. Determine the exact moment in which your product should appear in that person’s journey and think about the steps that he/she should make inside your product. Then, think about the steps that you and/or your product should make to solve that person’s problem. Describe each step thoughtfully, listing all the helpful information that you will eventually need.
This is actually simple: take all of the user’s journey steps that you described before and turn that information into particular features. Mark the specific features that you consider critical, the fundamentals, those ones that will make the user love or hate the app.
Once you’ve decided which features are absolutely necessary, you will have an idea of what are the main tasks that your product will achieve. If your product responds to those tasks, you will win the user.
But where to start? Well, you should be very clear about what you want to test: if what you want to test is if people would subscribe to your product, just creating the landing page with the subscribe button would be it. Think about the tradeoff between easy implementation and the necessity of the feature. That might be a helpful way of defining what you should test in the first place.
These are the main steps in order to understand what features are fundamental in your MVP. Remember: MVPs are made to test your product. They should be simple and well built, thoughtful, and they must solve the most essential problem. Feedback will give you the right answers for the next question: how do I make it evolve?
.svg){kind=logo}
