One thing clients can struggle with when working to create and market an app is when to go live.
They may believe:
- It doesn’t have enough features yet to be valuable to users.
- The visual design isn’t quite right yet.
- There may be bugs that haven’t been found in testing yet, which may cost them users.
In other words, they believe it has to be perfect before they can show it to anyone.
We understand clients want to present the best possible version of their ideas to the world. However, by not releasing early and developing iteratively, we’ve found they’re missing out on valuable feedback from users.
This early release is called a minimum viable product or MVP. It’s a version of an app that does precisely what it was designed to do with no frills or extras.
This minimal version of the product saves time and money in the long run by providing greater clarity—early in the process—about what the application should actually do. Here’s how.
Imagine you’re creating an online auction site for heavy equipment. As soon as you can list equipment with information about the item and pricing, and can take bids, you’ll want to release the app to a select group of users. This version is designated as your MVP.
Perhaps you don’t have email notifications enabled, or you can’t upload images from your mobile phone, or you don’t have the 3D walk-around of the item implemented. That’s ok! You can add these as you go.
As your users interact with the MVP, you might find they are having a difficult time locating the seller’s contact information, or the search mechanism needs to be reworked, or the images should be larger. It’s better to find out now when those changes are easy to make then later when the process will be more involved and more costly.
An MVP can be opened up to 5 or 500 people. The number isn’t that important. What is important is that the feedback you get from them can—scratch that, should—help shape the development and design of your product in a way that’s impossible without their input.
You simply can’t know at the outset everything about what your audience’s pain points will be or how different people will interact with your app. By delivering an early version of your app to a select group or marketplace, you maximize your chances of getting quality opinions and feedback from a representative cross-section of your intended user base.
You can’t simply release your app and expect the ideas to come back to you, however. It’s important to create an environment at the outset where testing, reporting, and incorporating changes are an integral part of the development process.
There will be times when you do need to modify a part of your app based on user feedback—or even change direction entirely. This is known as a “pivot,” and it’s seldom a small or easy change. Ideas that seemed great during initial brainstorming, but don’t work well in practice, will surface quickly when you adopt this strategy.
We’ve found that such shifts in direction are much less difficult for the team and the client when they are based on direct evidence from users testing your product.
Other times you will want to stick to your original vision on a certain aspect of your design or implementation based on your unique perspective, or an industry insight you bring to the table.
While deciding whether to “persevere or pivot” can be a tough call, at least you will have data upon which to base those decisions. This creates a “build-measure-learn” loop that will continue to guide and shape the creation of your app, making it the best it can be.
Each incremental release will be stronger and better suited to the problem it was designed to solve. And you will drastically shorten the time and cost it takes to add the features that will get your app to version 1.0.