The goal of any business is to provide value to your customers. And the only trustworthy indication of whether you’re doing that — of whether your minimum viable product is, indeed, viable — is an exchange of money between you and the customer. In other words, if people are willing to pay you to use your product, then it’s viable.

The definition of viable is pretty straightforward. Let’s identify what a viable MVP is not.

  • Viable doesn’t mean an absence of bugs. All software products have bugs. That’s not the fault of its developers. Software, being complex, is easy to screw up. In building a feature for one part of an application, you might end up breaking another part by accident. There are ways to detect bugs and minimize them, but if you’re building an MVP, chances are you won’t have the resources to put best practices to use. Test your product and fix at least the most obvious, annoying and critical bugs, the ones that might turn off your customers. But don’t aim to fix all of them. Aim to launch early instead.
  • Viable doesn’t mean an MVP is perfectly designed. We all have our own understanding of what a “perfect” design is. There are plenty of beloved apps out there with well-thought-out user experiences, sleek and smooth interfaces and eye-catching animations and transitions. Of course we want something like that in our applications! But creating an outstanding design takes a lot of time and effort. It’s like trying to run an ad campaign similar to Nike’s or Coca-Cola’s, but on a shoestring budget. You simply can’t do it because they’ve been around for decades, their brand is known, they have an army working for them and they have an unlimited budget. You can’t build a perfect app with just a handful of people. Instead of aiming for a perfect design, admit that you’re small and make a design that works, that helps people achieve their goals. You’ll be able to iterate and improve on your design later.
  • Viable doesn’t mean that an MVP contains all of the features you imagined your final product would have. Quite often, founders build apps that are viable for themselves. But have you asked your customers what is viable for them? For example, you may spend months building a sophisticated and secure login feature that supports two-factor authentication, only to learn once you launch your MVP that most of your customers don’t care about using it in a secure way. Build a version that contains a minimal set of features instead and ask your customers what they want to add. Maybe they’ll be okay with a simple Google login, and they’ll trust Google’s security. You never know.
  • Viable doesn’t mean your MVP needs to be an application. Most of the time, your MVP is not an application. Think about the different types of products you can create, and focus on marketing and building an audience instead. Can your MVP be a newsletter? Or maybe a digital course for your audience that’ll solve their problems with a DIY, educational solution? Can you just provide a service or consultation for them? Because if you choose any of those options, you’ll be investing in marketing for an audience instead of in product development, the latter of which is expensive and risky. It’s better to develop a product when you know that there are people waiting for you to build it, rather than building it and then scrambling to find someone to sell it to.

All this being said, I don’t promote building subpar, half-baked products. We all have certain expectations for products and services because we judge them compared to other exist
ing products and services that we are. That’s why McDonalds started offering healthy food recently — everyone around them offers healthy food to their customers, and they just can’t carry on and ignore that.

But if you’re a small team with limited resources, you also can’t pretend that you’re some magnificent, huge startup and create the same quality product that an established team would create. Your customers will forgive you for some of the shortcomings of your app. Seek out early adopters who will be willing to try your early releases in exchange for the ability to get involved in the product development process. Focus on building something small, but useful — you’ll grow over time.

Originally published on Medium