Why Building MVP is Important and What Are The Next Steps

Every application has one purpose: to help the users achieve a concrete goal, and in a seamless and pleasant way at that. That definition is as general as it gets but there’s a point to this vagueness.

And this point is: most often this is all you know when you start developing or expanding your software. You know you want to help the users. You may even know what exact activities the users should perform in your application. But do users really need this? And what do seamless and pleasant mean in this context? These questions are more difficult to answer.

Because here’s the thing: you can assume that the users DO need this feature, and you can assume how good user experience should look like. But assumptions most often backfire. And betting real money on assumptions is not something many people would want to do.

So there are two questions here:

• If you’re building from scratch, how do you make sure that you deliver value?
• If you already have an MVP developed by one agency, what are the best options for moving forward?

Let’s begin with the first one.

How To Build A Value-Adding MVP

Eric Ries has written a book called Lean Startup that perfectly describes the thinking behind creating a value-adding MVP. There are a ton of great points and approaches worth adapting in business development.

So instead of recapping what the book has to offer, we’ll share our practical conclusions that come from over a decade of developing software.

When building software, there is a strong temptation to write down and plan every feature that comes to mind. MVP’s goal is to test a hypothesis but when the development gets going, it’s often the case that ideas for features accumulate. It’s quite a natural process but planning to chase after these ideas poses a couple of risks:

• The market can change and the ideas may stop being viable
• The funding can deplete before you get to something that the users will value
• It may turn out that the ideas didn’t pinpoint the users’ needs 

And there are three ways to go about these risks here.

The Best Approach: Remember That You’re Experimenting

In this approach, you’re doing things by the book (and a very concrete one: Lean Startup). This means that you overcome the natural tendency to plan ahead, and focus on building a small app that will allow you to test things like:

• Do users really need what you thought they needed? Using Dropbox’s example: instead of building a cloud file-storage service, they started with a landing page that described what Dropbox would do, and placed an email subscription form there. This allowed them to test the idea cheaply and quickly.
• If the users need something slightly different from what you thought they needed, what exactly is it?
• What is the most efficient way to deliver what users need? How the product should behave for the best user experience?

You see how users react, and based on that you adjust. In short, MVP in this scenario is one iteration of the build-measure-learn cycle.

You use as few assumptions as possible, you build an MVP, test everything with the users, and then adjust. Rinse and repeat.

Second-Best Approach: Develop The Crucial Features And Test

If for some reason you cannot approach the project as an experiment and you need to deliver a fixed idea, it’s best to identify just a couple of features (or even one) that are at the core of the idea. In other words: a feature without which the app couldn’t even exist.

Then you deliver this small and sometimes rough around the edges app to the first users and see how they react. You learn what they like, what else they need, what needs adjusting.

Third-Best Approach: Prioritize 20%, Deliver, Test

Some products are supposed to compete in an established market. In this scenario, the users are used to a certain way of doing things, and going against the current would be ill-advised. So naturally, there is already a set list of things a product should do and how it should work to ensure both differentiation and familiarity.

The best way here is to take the list of features and prioritize 20% of them. This will help to structurize the development process, and will still give some room for feedback from users. Because after they test the first version of the product, you can still adjust the planned features based on the users’ feedback.

If you'd like a more detailed breakdown of what MVP exactly is how useful can it be, and how to approach building one, check out this article.

So You Have An MVP. What’s Next?

Above, we looked at some of the approaches to building an MVP. Whichever approach is the best for you, it will take a couple of MVP iterations to find the balance that the users look for. Chances are that up until this point most of the development work has been done by an outside agency. So what’s next?

There’s still work to be done. The MVP iterations allowed you to build a product that the users need, and now you can add things that make the use of your product even smoother. But you need developers. What are your options? And what is the best way to proceed for each of them? We list your options below, describing how we approach each.

Option 1: Stay With The Current Agency

If you’re happy with the results and the quality of work, virtually this is the best option for further development.

All the product knowledge is in place, all the future plans are written down and understood, there is a backlog, a product team, and communication channels set up. You can smoothly transition towards product expansion, or if it is at the feedback stage, we will focus on bug fixing, behavior monitoring, and maintenance.

Option 2: Create In-House / Agency Hybrid

If you want to build your own in-house team, you can choose to go with a hybrid model, where the agency supports your core operations.

In this scenario, we’ll focus on transferring the knowledge to your new in-house team, making sure that they have everything they need, providing support and code reviews. While we’re doing that, we’ll keep looking after the product itself. The goal here is to have a smooth handover.

Option 3: Transition to Full In-House or New Agency

For many reasons, you may decide to build an in-house team that will be able to fully take over the product development, or you may want to change an agency altogether.

In this case, our goal is also a full and smooth handover. We will support the product, do code reviews, and knowledge transfer sessions until the new team is fully capable of taking over.

If you’re planning to follow this path, make sure that the legal agreements about intellectual property protect your business and product. A good practice for the agency (that we apply at Monterail) is to ensure that the client receives the intellectual property rights either by license or by transfer.

Summary

If there was just one thing you could take out of this article, let it be this: MVP = experiment. Understandably, we don’t always have as much freedom to experiment as we would like, so you can adjust the MVP approach using what we’ve outlined above.

And once you have an MVP, there are a couple of options for going forward, from staying with the agency you started with to recruiting your own full in-house team. If you’re building your product with us, you can be sure of our professionalism and support in whatever you choose to do.