The MVP Problem
As an outsourced development partner, we work with a lot of different customers on a lot of different apps, software, and websites. The only thing that is the same between these various projects is an unrelenting difficulty in communicating a customer’s desires into working code that fits the customer’s budget and timeline. Understandably, every customer wants a great product for a great deal. Who doesn’t!?
As professional software developers, we are pretty skilled at estimating the amount of work it takes to get from an idea to a working, sellable piece of software. (Notice I didn’t say “a finished product.” There is no such thing. More on that later.) Given enough information, we can usually get within a 20% variance after just a couple of conversations.
The trickier part is getting to the first version of the application or software, often called the minimal viable product (MVP). What makes this tricky is the the term “viable.” Most outsourced app developers will give customers a canned definition of MVP, something like “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” That is the classic definition, and one that we use when building our own tools. The problem is that customers don’t just want to get user feedback, they want to start getting revenue with the MVP. The product is only viable if it can generate revenue!
Setting Expectations
It has been a hard road, but at RocketBuild we are slowly coming to terms with our history of poorly communicating what an MVP will do, what it will look like, and what a customer can reasonably expect for their budget and timeline. We need to improve at setting expectations around the three major variables of a product version:
- What will the user interface (UI) look like?
- What features will be included?
- What’s not included in this version, but is backlogged for later?
The entire purpose of this blog post is to provide a framework for what customers should expect when we use the term MVP, viewed through the lens of those three questions.
What will the MVP user interface look like?
The short answer is that it will be minimal and likely based on a design framework that the developers can implement without a lot of custom design work. The easiest place to cut significant costs on an MVP is in the user interface. User experience (UX) design services, while worthwhile and necessary for polished products, are expensive. Coding a custom user interface based on good UX planning is also very expensive.
What we recommend for the MVP, and earliest iterations of the product, is to use an off-the-shelf UI. There are a ton of great design frameworks for building out a simple, clean interface that will be easy-to-use and easy-to-implement. Some of our favorites are:
Bootstrap – Perfect for clean, modern web application and mobile application UIs. Very versatile.
Django Suit – When we build in Python, this is our go-to for a simple, attractive admin UI.
Material Design – Google’s design standards made accessible for projects of any scope.
What Features Will Be Included in the MVP?
There is a lot of gray area when talking about software features. Human language is a remarkably flawed way to communicate technical details clearly and concisely! This is where collaboratively writing user stories comes into play. The process of working together with developers to generate descriptions of what a customer wants their users to do can be both enlightening and thought-provoking.
Once a thorough list of user stories has been written, we like to walk through them with our customers and make recommendations about which of those stories makes sense to include in an MVP based on what the customer has identified as their goals for launch. It is a great opportunity to generate a backlog (reserve list) of features as well, granting everyone a glimpse into the long term plan for the product while paring down the list for the MVP.
The best way to determine which features to include in the MVP is to address the following needs while reviewing the list of user stories:
- How will user’s register for the product?
- How will users be managed?
- How will transactions be processed?
- What 2 – 3 pain points will be solved for my users?
- How will I track my most important metrics?
- What can be done manually or outside of the app to start?
Once you have used those criteria to narrow down the most important features, it becomes much easier to determine what will be in the MVP as opposed to future iterations.
What’s Not Included in the MVP?
If all goes well while generating user stories and paring them down for the MVP, per the above process, then you will be left with a pretty long list of things that you will want to do later. This is called the “backlog.” It is important to have a healthy backlog for two reasons. First, it gives you, the product owner, something to be stretching toward as you ideate and polish those ideas. This is empowering and energizing! Second, it gives your beta customers and early adopters something to look forward to as you tease it out to them in user surveys, product reviews, and the like.
More specifically, it is likely that you will want to leave the following things out of your MVP, and likely your first couple of iterations, due largely to the investment it takes to build them and the fact that they will likely not affect your revenue potential out of the gate.
Things to leave out of early versions of your product:
- Highly custom UI
- Detailed reporting within the admin portal
- Touchless onboarding of clients
- Edge case user needs (not core to solving the business challenge)
Other Things to Consider for Your MVP
Use open source plugins and libraries when possible. You can save a good deal of time and money by allowing your developers to leverage some out-of-the-box plugins, modules, and code libraries that others have built and vetted. They may not last for the life of your product, when your needs become highly custom, but they will work to get the MVP out the door.
Don’t be reactive to the whims of your first few customers. You are likely to get a lot of good (and bad) ideas from your first few customers, and there is ample reason to listen to them. They are trusting you when no one else has yet, and that has power. Just be careful not to spend a lot of time and money on something that solves very specific problems for only one or two clients. Add their ideas to the product road map so they know they have been heard, but don’t front load that work when you could be investing in core functions and features.
