Building a Minimum Viable Product

The world is full of acronyms and their meaning changes depending upon the context. With respect to software development MVP means minimum viable product, but what does that mean? Why would you build one? What are some tips?

Let’s start with a concise definition and we'll dive in from there.

A minimum viable product is an unoptimized, partial product used by your market for the purpose of vetting a speculative solution.

Breaking down our definition we can learn what an MVP is.

Partial Product Used by Your Target Market

This means you're not building the entire product, rather you're focusing on the most import features first. Efficiency and performance aren't your goals at this time - instead you're trying to build something that captures the essence of your idea.

Your goal is to give the product to people who are likely to be users. Let them see and experience the solution so they can provide feedback. This will help you gauge if you're on the right path, make decision about what features to build and what items matter most to your users.

For the Purpose of Vetting a Speculative Solution

Don't worry if you hear "no" or negative feedback from your users. This is valuable because people take an idea to the Nth level in their MVP product only to discover their market doesn’t love it, like it or worse – doesn’t want or need it. Your MVP should  help you get to a “yes” or “no” answer quickly – that’s the goal.

The cycle of build > test > feedback continues until you have a product that meets your users wants and needs.

Tips for Building Your MVP

Here are a few general strategies and opinions that we’ve formed over our careers.

1. Fail fast and often. Does that sound counter-intuitive? The idea of the MVP is to help you get to a “yes” or “no” for a feature or entire product as soon and cost effectively as possible. Hearing "no" (and why) is valuable during your MVP stage. "No" saves you time and money.
2. Build a list of feedback questions or a survey to help track and measure feedback from your users. 
3. Allow your users to provide feedback comments as well. This is often where new ideas and perspectives come from.
4. Carefully consider the features you build. Make them earn the right to be included in your MVP and if they can’t be justified add them to a “good idea” list.
5. Can your idea be conveyed and experienced by people without having to write code? If so consider an interactive wireframe prototype. It’s like a usable paper napkin drawing. It simulates a product – users can click buttons, navigate to screens and gain the valuable experience seeing your idea brought to life. The prototype doesn’t do anything, but no code is written and this saves time and money.
6. Defer visual design. Unless your MVP is specific to a visual / graphic design problem space, defer the time and effort.
7. Defer localization. Unless your MVP specifically deals with how your product will serve people who speak other languages, defer localization at this stage.

We hope you’ve found this article helpful. If you’d like assistance with your MVP contact us for a free consultation.