Developing a mobile product requires hard work and the results after you launched your application is uncertain.
Luckily, there's a method to test possible app ideas you have. You can gain a lot of knowledge by building a minimum viable product. The value of MVPs is that you have to spend less time designing and developing. As a result, you'll get a lot of insight early on. This improves the quality of the decisions you make for your product.
In this tutorial, you'll learn:
- what a minimum viable product or MVP is
- how to define your MVP
- applying MVP best practices
- building an MVP
- launching an MVP and receiving user feedback
1. What Is an MVP?
An MVP, or minimum viable product, is a product that has just enough features to test if it is viable in the market. To achieve this, all unnecessary features are stripped away and the application only contains the features that are deemed the core of the product.
- Minimum: This, as described previously, means that the product just contains core features and everything that isn't a must-have is stripped away.
- Viable: This means that the product has the opportunity to get traction and that it creates value for people. Value is a broad definition. For example, a game provides entertainment, which is value. Usually we consider that a product is viable if it can generate enough revenue to be worthwhile the cost of developing the product.
- Product: Of course, you're building a product. You're producing a digital good for people to use.
When you have a vision for a product, it's often complex. You want users to achieve a variety of things using your app. Though, the actual core of a product is often pretty small and simple.
A great example of an MVP would be Snapchat. Snapchat has one particular focus, you can view and send images to other users, but the images you send are only temporarily visible. It's a simple product with a focus. They tested this core concept and it succeeded. Only after the initial launch and product validation, it made sense to start working on more features.
Many of the applications we know are far beyond the scope of an MVP. Let's take Instagram for example. Initially, the MVP could have focused on just filters. You would be able to take a photo, choose an existing photo, and put one of the, let's say five, filters on the photo and save it back to the device's camera roll.
Releasing Instagram as a minimum viable product would have tested the assumption that people use filters to improve their photos. If the app gains traction, you can work on updates, such as profiles and video support. If it doesn't work out and you don't get traction, then it's probably not worth continuing development. Perhaps a different idea is more viable.
Working on MVPs means taking opportunity cost in account while working on a product. After all, failing early means that it saves you time to build a successful product by stopping product development early when a product fails.
Define the core of your product. Build that first set of features and test it on the market.
Developing every possible feature you have in your mind can take months while a simple MVP can take only a couple of weeks to create.
Releasing early has another advantage, user feedback. You're able to collect user feedback early on and you can shape the product based on what your users want.
2. Defining Your MVP
Before you can actually start developing, you need to define your MVP and product roadmap. What features are must-haves and which ones are nice-to-haves? It's very important to stay as objective as possible during this process. A feature you deeply care about might not be the core of the product. Decide if a feature is a must-have or a nice-to-have.
A typical nice-to-have is forgot password functionality. Instead, you could show a support email address. Once you have traction, you can improve this feature and build a proper forgot password flow. At this phase, it's all about limiting the time it takes to get to market.
Write down the feature set of your product in a document. Basically, you write down all the features of your product in detail. This is a working document and gives you an overview of what you will be creating. It's also a useful document to brief designers and investors for example. It's putting your vision on paper. You can also briefly mention for yourself how you accomplish a feature in a technical sense. Feature sets usually include a technical scope. This is especially useful if you work on a project with multiple developers.
The next step would be listing your features in terms of priority. What's the most important feature and which one creates the most value in short term? Once you've defined that, you can put the remaining features on a product roadmap to define what you'll be building once your product takes off.
To better understand your product's feature set is to rate every feature on a scale of 1 to 10, taking into account product importance, complexity, and added value for the user. You can make better decisions in terms of the timeline for your product when you understand the various components of each feature.
3. MVP Best Practices
These are my personal reminders when I define a minimum viable product.
- When you have an idea, take a look at the existing market. What similar products are out there? What is their value proposition? How would you do it differently or, even more important, better?
- Once I've finished writing a feature set, I always review every feature and ask myself if it's truly necessary. Does the user really need to create an account? Can we drop features so we can avoid building a backend?
- Second opinions are very valuable when scoping an MVP.
- Are there APIs, SDKs, or frameworks available that can do some of the work for me?
- For product roadmaps, I plan one release ahead and I try to keep roadmaps short-term as they'll be strongly influenced by user feedback.
- Do proper technical research once you've finished your feature set. No one likes surprises when they're developing a product.
- Talk about your idea. There's a lot of value in feedback.
- When collaborating with designers, ask them to stick as much as possible to iOS standards. Try to reduce the amount of animations in the product.
4. Building an MVP
Every developer or team has different preferences about how to build a product. I'll keep it brief, build the product the way you like and don't lose sight of what you initially defined as the minimum viable product.
It's okay to say no.
Be aware of feature creep, especially if multiple stakeholders are involved. A lot of suggestions you have for features can be included in a next release. As long as you continue to revisit the feature set and make smart decisions based on the initial product vision and information you might gain along the way, you'll stay on track.
Quality assurance of the product is another important step of building an MVP. Assure that your product simply works. Spend enough time to do bug fixing. If you're a solo developer, consider a small private beta with friends and family. If you have a budget, then hiring a QA firm can also be an effective solution to keep your product free of critical bugs that could harm the product's launch.
5. Product Launch & User Feedback
Well done! You've finished building your product. Now is when the real work starts. After you've finished developing, these are your next short-term priorities:
- get traction for your product
- get feedback on your initial product
- identify flaws, such as bugs, product issues, and missing features
- identify your product's strengths
Marketing your new app is not always easy. Here's a tutorial to help you if you need help getting that initial traction. Once you have a first set of users, your priorities shift once again. Now it's all about:
- asking feedback from your user base
- analyzing user feedback
- updating the product roadmap and continue developing
It's not easy to get feedback from users. Your rating on the App Store and user reviews tell you something, but the trick is to get some more in-depth feedback. It's important to always be available to your users. Have a Twitter account, include your contact information in the app, and don't be afraid to be proactive by reaching out to your users.
If you've worked with testers for your product, then you already have a list of people you can have a conversation with.
Whenever you get feedback, it's important to analyze it. Be aware that when something is bad, there's a bigger chance people speak up rather than when they like something. The feedback you get might be bad, but that doesn't necessarily mean your product is bad.
To evaluate if your product is viable, use app analytics, such as Mixpanel to keep track of user activity and retention.
Statistics define if a product is viable, not user feedback.
Compare the user feedback to your original product vision and product roadmap. The most difficult part is to define how this feedback should shape the product vision and that's a choice every product owner needs to make for himself.
Conclusion
Well done! You've learned about minimum viable products, how they make product development more efficient, and how you're able to make better decisions after your product is launched.
A final tip I want to give is probably the most important lesson, know when your MVP is not viable. Deciding not to pursue a product idea is probably one of the hardest decisions a developer has to make, but there's no doubt in my mind it will sometimes happen when you create products. Statistics are extremely valuable post-launch and will help you make data driven decisions.
I'm eager to hear about your experiences building products so far. Please share them in the comments. Any questions and feedback are welcome as well.