A Quick Guide to Designing and Building Successful MVPs.
What are MVPs? MVPs are tests, discoveries, and proofs-of-concept used to test if an idea is feasible before dedicating more resources to building a better version. It’s how a startup team finds out if the idea they started with is not a million-dollar idea, how a big company avoids negative reviewers, and how entrepreneurs get important and free market insight without paying for it.
Done well, an MVP can become successful enough to keep users interested in future developments, but when it is not, it can be why a good product never comes out.
So, how might we avoid the latter? What are the most important factors to consider in building a successful MVP? Here are five things to keep in mind:
Start small. Keep it smaller.
Anything is manageable when it is small. M is for minimum, so you want to start with very little. Whether it is the team size, the online cloud space, or a massive design language, you want to keep things as small as possible. It is easy to stay small during inception, but well-designed systems eventually scale up as they grow. When the level of complexity becomes unmanageable, you break it down into smaller interconnected subsystems (similar to what we refer to as a microservice architecture in software design).
Focus on objectives
The project objectives aim to bring a shared understanding of the vision or the outcome. They serve as directives to focus on the overall team output.
There is a difference between objectives and features. The objective is where we want to go; features are how we will get there. Features can change quickly with each release, but objectives do not (unless they do not meet the desired solution). Everyone on the team must understand the priorities, especially in the early phases of production, because the clearer the objectives are, the more synchronized everyone on the team becomes, resulting in fewer errors and increased efficiency in implementation.
Progress. Not Perfection.
A perfect product claims that it knows everything, does not have flaws/bugs, and solves 100% of the problem. Even if it is true, someone out there will still experience a variation of the problem that the product cannot solve.
When you build and release a step at a time, you admit that the product is not perfect but still humanistic.
Take Figma, for example.
Earlier versions of Figma were not perfect and received strong negative pushback from designers and design teams.
That did not stop Dylan and Evan, founders of Figma. They progressively added new features to it, turned it around, and now it is the standard design tool in UI/UX, quickly replacing competitors. Figma was not an overnight success, but with each iteration, it kept getting closer to achieving its goal. Today no one cares how bad it was at the beginning, only how it is now. This story is similar to how many apps made it, from Twitter to Facebook and Instagram.
Progress makes a man better, not perfect. So leave perfection to the gods; they can have it. We will do what works for us, one step at a time.
Release what works.
MidJourney is an AI art tool that can render artworks using only text. At the speed of its current growth, we might soon find it difficult to tell the difference between real art and computer-generated art. And it’s only in beta.
When I was writing this, users could only use the AI tool on Discord. There was no app or website, just a Discord channel. But it was working nonetheless, and many people are using it.
With great ideas like these, it is tempting to wait and build the perfect SaaS or desktop software before giving it to users. This decision is one main reason why some great ideas do not start. There are already existing apps and other experiences that take a lot of the user’s attention. What you want to achieve with your buggy MVP in this phase is to show that it works.
Remove what does not work.
Understand that some features will not work for the MVP. Some are just not suitable for the current state of the product, and others are just not needed. Just as you add features, you should be quick to remove them in such cases. MVPs should always be light and flexible enough to adapt quickly.
Learn from Feedback
Feedback is a response to using a product or experience. Listen to what users have to say to learn and understand more about what they need.
Sometimes feedback can be confusing, as users give feedback by voicing their preferences; do not take their word for it and apply it directly as it was said.
“I don’t like the red button because it looks dangerous.” or
“Can you make it bigger?” (Something logo designers are cursed to hear for the rest of their lives).
But instead of quickly discarding this as the preference of just one person, look beyond it. I can assure you that there is always a reason. Ask for it if you have to.
“I don’t like the red button because it looks dangerous.”
“I would like it better if it was bigger” (maybe she can’t see it clearly? Or her girlfriend said so? I don’t know, ask her).
This process is one of the things that makes design great; understanding user behaviors and actions and translating them accordingly into the product.
Fail often, Fail Better.
Failure gives room to improve and learn. Behind every success, there are a thousand failures. Startups and teams who permit themselves to fail often also succeed better. The team should experiment with new approaches, features, and ideas, as this brings innovation, creativity, and better understanding. However, creativity breeds chaos and can lead to losing focus on what’s important, so carry it out in an open and restrictive environment, where there is no penalty for being wrong, only you are wrong in the right direction.
Conclusion
An MVP brings the discovery of what users think of the product, helping the team to verify the feasibility before launching a better version.
The MVP should fail, so the later versions won’t have to. Fail often, and as you mean it, but more importantly, use it to gain insight into what you didn’t know or might have overlooked about the market and the users.
The objectives and the features of the product should always be in tandem. Not observing this can result in a chaotic production, which never ends well.
Always consider three things when designing MVPs:
- Build fast
- Ship early
- Learn and repeat
Success and failures are not immediate; if the MVP was not successful the first time, evolve it. If the objective was wrong, change the direction of the product. If the idea is not good enough, remake the idea.
Above all, never lose sight of the concept behind product design, making better products that solve everyday problems.
