What is an MVP?

According to Wikipedia an MVP (minimal viable product) is a product with just enough features to satisfy early customers, and to provide feedback for future development. Some experts suggest that in business to business transactions an MVP also means saleable: “it’s not an MVP until you sell it. Viable means you can sell it”. Before you decide to build a new product or application, make sure you define your MVP first.

It is very common that a client approaches us with an idea to automate or streamline existing processes to increase productivity. We find that often that their ideas are very large and can take a long time to develop. This can cause a lot of a lot of feedback, delays, changes and revisions. Even worse, when put in production, the actual usage is much lower than expected. These problems can happen because you didn’t take an MVP approach or the MVP was poorly defined.  You can end up spending a lot of time and money on features that were not needed or poorly designed. The nature of the business may have evolved so what you developed no longer applies or has changed.

How to define your MVP

This is possibly the most important phase of developing an application. We suggest that you never forget the original objective of what you want to develop. This is a personal mantra that I have when I talk to teams and clients. When a discussion is stuck, repetitive or doesn’t seem to go anywhere, I usually interrupt and ask “What is it we are trying to do here?”. Often times people go “ahhh… right…. that is not important, lets focus on this…”.

I suggest that you write down the primary objective and problem(s) that you are tying to solve. Then, if you can, talk to your users, ask them what problems they have and what would they like to see. How can it work better? What would save them time? Write it all down and if you can, break it down into bullet points or items. Then, reorder the list based on priority. This list may be too long or represents a very large project.

Try to focus on the most important items or features on the list. Review the other items on the list and if it is not directly related or has no impact on the more important items, these are probably secondary features and not needed for your MVP. Take as many features and items out of the list (save them for later). Review what you have left and compare with what you stated as your primary objective. Hopefully these should align and give you an “A-Ha!” feeling that this is what you want to develop.

Questions to ask when defining your MVP

Ask yourself the following questions when you define your MVP:

• What is the main problem you are trying to solve?
• Is it really a problem?
• Who are your users?
• What makes your idea or solution different from others that possibly (or probably) exist?
• Does your idea actually solve the problem?
• What is the most important feature of your solution?
• Is this “X” feature actually needed? Or just a “nice to have”?
• Does this “X” feature add real value to your users?
• If you are selling this then ask your users “would you pay for it”?

Visual mock-up of your MVP

After you have your final list of items and features, try to write up a description of your solution or application. It helps when you describe your typical user, what do they do, what interactions do they have and what outputs or feedback they can get from the system. What also helps is creating visual mock-ups of your solution. There are many drawing tools available on the web that you can use to create mock-ups. I particularly like Balsamiq which allows me to create screen mock-ups for both web and mobile applications with an easy to use interface. Pen and paper works just fine too. You can find alternatives for Balsamiq here.

Discuss MVP with your team

You have a well defined idea with the minimum features needed, a description of what it does and a visual mock-up of what you think it should look like. Before you go trigger happy and start spending time and money on building or coding, share it with your team. Share it with your potential users, ask them if it would solve their problem? Does the “flow” of the steps in the solution make sense? Discuss with your developers, get recommendations from them.

Do your research on different ways to get it done. For example, If it is a mobile app, maybe it is better to do it in a hybrid platform so you can have an Android and iOS version for less money. If it is an online solution, maybe you can get away with doing it in WordPress and create plugins for the more complicated parts instead creating a website from scratch. If you are selling a product, try using Shopify to sell it online instead of building an entire e-commerce platform.

Develop your MVP

After you have validated your MVP with your team and potential users, done your research on how to build it, you are ready to develop it. You may want to do it in-house or hire a team. No matter who you choose to develop your project, you need to be 100% involved. Don’t expect a well built solution if you are not present in the process giving constant feedback and communicating what you need. Before you start, make sure you define the priorities to develop first. The most critical and helpful features should be built first, tested and released. Once you know that these features are working is when you can continue with the rest of the items and features. Don’t be surprised if you end up with a smaller completed MVP before your project is done. If that is the case, I suggest stopping any further development and go to the next step.

I strongly suggest an agile or lean method for developing your product. I personally like using SCRUM which allows the team to deliver small and useful increments in short sprints of time. We use a modified version of SCRUM at NearSource that works better for smaller teams. You review each sprint and provide feedback to the team. During this time priorities can be changed based on feedback and revisions of what has been completed. Using sprints avoids lost time and effort spent on features that end up not being needed or not developed correctly. It is easier and less costly to make corrections during the process then waiting for the entire product to be completed.

Don’t over-complicate!

Don’t be afraid to have manual elements or processes in your MVP. For example, if you need payment processing and don’t have the time or budget to integrate it with your system, then don’t do it! Online payment gateways allow you to log on their system and enter credit card information. You can consider using PayPal as an alternative to process payments. Another scenario is your system needs user sign-ups to work, but you need to approve users before they can start using the system. Instead of spending time and money on algorithms to pre-qualify users, just have it work manually. When you are just starting you should be able to review each sign-up manually and approve them individually. Once your business grows you can revisit this and automate it.

Get user feedback

Once you have completed a stable MVP, have it approved internally and possibly have some beta testers trying it out then you are ready for feedback. Don’t wait for your users to start talking about your system. Find out who uses it and who stopped using it (if any). Contact each one individually with some prepared questions. Ask them if it solves their problem. Find out what is missing for them to continue using it. Ask what they like and what they don’t like.

If possible, have a ticket system where users can submit problems or questions. This will provide you better feedback and insights on what your next phase is. Review all the feedback and repeat the process, define which items are more important, weed out the ones that can wait or don’t provide you any value.  Repeat the steps you did with your first MVP and define your version 2.0 of your system.

I want to build my MVP!

You are probably excited and can’t wait to get started to define your MVP and develop it! You want to make sure you are doing things the right way using the least amount of effort. If this is your first time, you may want to consider a partner or resource that you can count on. NearSource has several years of experience developing custom applications and web solutions for different types of businesses and clients. Some of these projects are completed within weeks and some can take several months. We are here to listen to your ideas and give you recommendations on how to get it done. Read more about our application development services. We also provide general consulting services if you just need help to document your idea and want to develop it with your existing team.