MVP the Right Way

An MVP answers two very important questions: “Should we build this or not” and “How can we improve our initial concept with real user feedback?”

In other words, the idea behind an MVP is to quickly get the product to the market, so that you can begin to apply, iterate, and add features based on solid customer feedback—not just assumptions.

What are the benefits of an MVP?

When designing a product, keep the big picture in mind while proceeding with small consistent steps towards the ultimate solution by making necessary adjustments, measuring progress, and taking the next considered step. Ask yourself: “What is the minimum we can do to prove that our product works and solves problems?” With this in mind, you can avoid wasting time building lower priority things first.

The best products seek to solve a problem that nobody has been able to solve before

Those who build and test MVPs can balance between efficiency and usability as well as save time and money in the product development stage. When developing an MVP, you should think of the features your product has and narrow those down to what you need your users to test.

Aligning timelines with objectives

Timing is very important when developing a new product. What's more, it can be a source of co nfusion or frustration for the stakeholders. With a new product, you are facing two issues: what you think the user needs in order to use the product, and the actual behavior of the user that uses the product.

Creating an MVP allows you to get your app in the hands of its users as soon as possible. By doing this, you will create an opportunity to steer feature ideas, user personas, and demographics into actual data.

This also serves as a chance to learn more about your actual users and what engages them, not just what you perceive as their needs based on hypothetical user personas. To achieve this, you should focus on the core functionality of the app rather than the features. The more features you bring into your MVP, the more time it will take you to complete the product.

Think of Uber as an example. When Uber started, the initial target was a user persona: a city commuter. Later, other features were added to meet the needs of other user personas: large groups (UberXL), ride sharing (Fare Splitting), and price-conscious commuters (UberPool). However, the very first version was simple, small, and targeted to particular users. Instead of building everything at once, Uber let their users tell them what they want to be created next.

For every new feature you add, there is exponentially more work to do. Features require input from multiple stakeholders, including product management, engineering, quality assurance, and so on. You might have to rework the entire navigation and experience, as well as provide additional hours of testing, development, and bug fixing.

Just one new feature can potentially slow down a release by two or three months, depending on the scope. When designing an MVP, strip your app down to the core function that a user needs in order to use it. Put it into the hands of the target user and see how they respond. Focus on the core experience of the product.

If you bog down the app with a wide ra nge of features, you are delaying the data that can be derived from customer engagement. This can result in the potential loss of passionate, loyal customers that can’t live without the basic core function.

Your MVP is a machine for turning questions into answers.

This may sound simply like reasoning for killing features—it’s not. It’s about prioritizing the right features to provide the best value to the user. The end goal for any designer is to make users and stakeholders happy. By giving your users a proper core functionality and the best experience, you will not only make them happy but you will create a product that has value, which is what the stakeholders want.

Start with performing detailed analysis, gradually adding functionality, and keeping the concentration of the team. Dividing the development into series of small tasks. Also, remember to adhere to a simple formula: test, implement, and test again.

Henrik Kniberg, Agile and Lean coach says that at Spotify they use 4-stage iterative product cycle (Think It – Build It – Ship It – Tweak It). When the company launched in 2009, the primary focus was on the most important feature: playing music. Having released a desktop app, they were able to test the market within the limited beta release. This allowed Spotify to accumulate momentum and solve licensing issues related to music—both very important for the planned entry to the American market.

Today Spotify uses the same agile process for scaling. The basis of each of the four stages is the constant work of small teams testing hypotheses. At the “Think It” stage, the quality of the MVP concept is measured, and during the “Build It” stage, a physical MVP is produced, the quality of which is carefully tested. The next t wo stages, “Ship It” and “Tweak It,” measure the quality of the MVP in the long term as well as the degree of customer satisfaction. Since it’s launched stage by stage, they receive constant feedback and iteratively improve the product.

Features can be different in complexity and scale, but the consistency of the experience is most important. The experience gives customers trust in what you develop.

Want to know more about SoftServe Design Doing process as well as what we learned by testing the minimum viable product, read “How Design Thinking Can Transform Dying Organizations,”, a new whitepaper from Matt McBride, SoftServe’s vice president of global experience design.