Product Development: Tips for Building a Successful MVP

Whether we’re working on a mobile application for hundreds of thousands of people, an enterprise software for a large multinational company or a small internal tool just for us, we always like to take the MVP approach. Why? Because the flexibility of the production process is much bigger when we start by designing and developing an MVP, and that ultimately results in much larger overall benefits for the client.

The benefits are truly numerous and heavily documented, so we won’t focus on them in this text. What we will focus on are some small tips we always keep in mind when we’re developing an MVP. It doesn’t matter if we’re just starting out with the product discovery process or we’re already heavy in the development phase, these 5 things keep us right on track!

Focus on solving the right problem

A lot of products fail because they either want to solve a bunch of user problems but really can’t properly solve any of them or because they are solving a specific user problem which is never validated and it turns out not to be a problem at all.

The key is to focus on creating a product that solves a specific user problem that is actually a problem. But, how do you do it? Well, by creating a hypothesis and validating with actual users. This is important – before a single visual is created or a single line of code is written, we need to define and validate the problem that the final product needs to solve.

To successfully define a problem, we first need to define these three elements:

1. A user group
   • We need to define a primary user group because different groups have different wants and needs. What could work for one group could completely fail for the other.
2. The problem they’re facing
   • This is never done by gut instinct. To define a problem, we need to talk to real users.
3. A solution and a clear benefit for users
   • People won’t use products just for the sake of using them. They need to get something in return.

When we define these elements, we can put them all into a single sentence in the form of a hypothesis:
As a [type of user] I want to [do what], so I can [benefit how].

Here’s an example.
“As a [tourist] I want to [find the cheapest public transport route from Airport to my Hotel] so I can [save money].”

Now that we have this hypothesis, we need to go out and test it on users. If it turns out to be a real issue that a lot of people are struggling with, we’re onto something and we can continue. If it’s not, we need to go back to the drawing board. The beauty of the MVP approach is that we can actually do this multiple times because we haven’t started any production yet!

Define your value proposition

After we successfully defined a specific user problem the product needs to solve, we can say we’ve done a big chunk of work, but we still need to explain it in a way that’s easily understandable to users and even potential investors. We need to define the product’s value proposition.

So, what’s a value proposition? Well, think of it as a tagline or a sentence that promises what the product will deliver or enable users to do. There are a ton of great examples, so if you ever need some inspiration, just google “Best Value Proposition Examples”.

Most value propositions are short and to the point, and some are even catchy. But the most important things that connect them are the key elements they communicate:

1. They show benefits of the product
2. They are solution-oriented
3. They highlight competitive advantage

When we work on value propositions at Bornfight, first we focus on defining what users really want, what value is offered by the product and what value is offered by the competition. And then we focus on the sweet spot between user’s wants and the product’s value. Just like in this picture below!

Include only necessary features

Oh, let’s add just one more thing… Well, we have this, so we can also add this as an upgrade… I just got an awesome idea we could implement… There’s this thing I saw… I thought we could… Let’s just…

You’re all probably very familiar with this situation. You start throwing ideas and functionalities around, the urge to include everything is just too big and before you know it, you have a billion dollar product that costs just as much to develop. The MVP approach, on the other hand, is about taking the opposite route.

Building an MVP is all about focusing on core functionalities that will make the product tick – functionalities that solve the problem we defined. Why? Because that enables us to fully test out the features on users before we commit on the full product. Sometimes we see that the feature works great and it needs to be in the product, other times we see that we need to change things – it’s all a normal part of the process. If we added all of the features at once, we’d spend too much time and money before we even have a chance to test if the basic elements work with the users.

When building an MVP for clients, at Bornfight we always double down on the problem that the product needs to solve and then create a list that consists only of features that are needed to solve said problem. Everything else is put to the side. By doing that in the initial stages of the production process, like the discovery workshop, we make the entire production process more flexible and our ability to shift around, cut or implement new product elements increases greatly. And that’s extremely important when it comes to building a new product.

As for all the other amazing ideas and features – we keep them in the backlog just in case. More often than not, they stay in the backlog indefinitely as they’re not needed at all, let alone as much as we might have thought in the beginning.

Validate and test in the real world

Another important aspect of building an MVP, or any digital product for that matter, is to validate and test what you created with real users. Forget lab conditions and guiding subjects to the end goal – most of the time, you just won’t get the info necessary to draw conclusions that will help you decide if the change you made is positive and what you should do next.

When we design and develop MVPs, we always take the current version of the product, give it to users from the defined target audience and ask them to perform a small task like locate an item, put it into the cart and go to checkout or send a message to a colleague and find the section with achievements. The important thing here is to give users just a brief overview of what they should do and then observe what they’re actually doing, where are they drawn to, where do they feel something should be located.

By observing exactly what the users are doing, where their fingers or mouse pointers are going and what they’re commenting while they’re trying to perform the tasks, we are actually gathering information. We are gathering data that will show if specific product elements we implemented made users faster and more efficient or just left them confused. It also helps us decide if we should implement some new elements or features, if we should rearrange the positioning of elements on screen, and even if we should completely scratch a specific feature.

Always remember that people are creatures of habit and, when it comes to tools they’re using, they’re constantly looking for the fastest or the least complicated way to reach their goal. By testing in real conditions and with real users, we can actually get the info on how they want to do it. And we can adjust our product accordingly!

Analyze, iterate, upgrade

In the section above, I covered the importance of testing the product with real users and gathering data by observing what they do. Well, all of that doesn’t matter if we don’t do something with that data.

To make all that testing and validation matter, and not just another step of the process, it’s extremely important to:

1. Analyze gathered data to come to specific conclusions about the product and the elements we implemented
2. Use those conclusions to iterate on the product and define specific product elements that would help users even more
3. Upgrade the product by implementing those defined elements
4. Test everything again and repeat steps 1, 2 & 3

Creating an MVP or a full product that customers will want to use is an iterative process that consists of testing, analysing gathered data, implementing upgrades based on that data and doing it all over again. All with the goal of making the final product as functional and user-friendly as possible while always keeping in mind the main user problem it solves and the core functionality it offers.

By going through that iterative process, we ensure that users who get accustomed to using the product always get something new, whether it’s a new functionality or increased performance that enables them to be more efficient in what they’re trying to do.

How to MVP?

Following all of this, I’ll just say one thing before I conclude.
An MVP is not built like this.

But like this.