This article is part of The Preparation Stage section of 📕 Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business.
Leonardo da Vinci supposedly said, “Art is never finished, only abandoned.” This is definitely true for software as well. The only antidote to abandonment is to put your work in front of other people, even when it’s not perfect yet.
The startup industry has coined the term of the MVP, the Minimum Viable Product, to express this in-between-state of being both a wonky prototype and a good-enough product for public consumption.
If software can never be truly finished, any stage of it is your best guess at what it should be at the time it’s created. As the MVP is the first version of your product that your audience will be exposed to, it is a crucial part to get it “right enough” while being okay with it not being “perfectly right” at the same time.
Before we look into what an MVP should have, let’s look at what it is supposed to do. The MVP is your first real contact with your customers. It has two main functions: to allow your early adopters to gauge the value of your service and to enable you to charge them money to gauge their sincerity. The MVP is the first handshake between you and your customers.
To have your MVP leave a great first impression, you will need to scope it sufficiently and time it well. Let’s look into these topics in detail, and then examine a few bootstrapped MVPs that were wildly successful.
Scoping Your MVP
There are two boxes to tick when it comes to your MVP: it has to be the “minimum” of what is needed to make your product “viable.”
What’s a minimal product? It’s the core functionality only, a simple tool without any fancy additions.
What’s a viable product? It’s the essence of the solution to your audience’s problem, a tool that does exactly what it promises to do, and nothing more.
Both “minimal” and “viable” are limiting the scope of your product, from different directions. You can always make your product more viable, but you can’t make it any more minimal without losing your customer.
A minimum viable product should contain a few structural components to make it usable by your audience: your users should be able to sign up and log in, solve their problem, and be able to pay for your product. Anything else is cruft, at least for your MVP.
Depending on the technical skill of your audience, you can get by with a rudimentary interface. If you build a tool for developers, an API and some documentation might be enough. For customers who need a bit more than that, you will have to provide a well-designed interface.
Luckily, creating a well-designed interface is easy for an MVP: if you only solve one core problem, there won’t be much potential for confusion. Every interface component you put into your MVP should lead your customer to your core functionality. If you find yourself having trouble with your interface and user journey, you may have too much non-critical functionality in your MVP.
Your MVP should be a “Mafia Offer,” something your customers can’t refuse because it’s too good to pass up. You can accomplish that by focussing on achieving the “minimum viable” part of your MVP. Solve one critical problem really well. Don’t do anything else. If there is nothing to distract your customers from seeing the value of the product, you have succeeded.
Beware of reacting immediately to early customer feedback. Your MVP is particularly prone to the core problem of software engineering: requirement volatility. Your prospective customers will expect different things from their tools over time. Worse yet, they might not know what they need, or they might have internalized their work too much to adequately express what their requirements are. Some customers will tell you what they think you need to hear instead of just telling you what they know.
All software is an imperfect approximation of a solution to a less-then-well-defined set of requirements. Your MVP will be too, and that is fine. It just has to prove that your core functionality solves your audience’s critical problem well enough.
One last thing about the scope of your MVP: beware of platform overextension. Don’t try and build the very first version of your product for all possible platforms it might be used on and for. If you build an app, find the audience that needs your product most, and build for their platform alone. Your app MVP doesn’t need to be available for iOS, Android, BlackBerry, and Windows Phone at the same time. One of these platforms will fit your product best. Build for that one.
For FeedbackPanda, we tried to find the most important platform and build for that. Since the product was a web-based SaaS for online English teachers, that meant something slightly different for us: choosing the right online school to integrate with, We integrated with the most significant player in the market first, tested, and went for the rest much later. The system we chose before all others was the one we knew most about, and that helped us to focus on building the core functionality without getting lost in the details.
Timing your MVP
Here’s the problem with timing when your MVP is done: it’s incredibly hard to time this, you’re much too invested. You have the grand vision of what your product could be. And here you are, looking at a version that is slimmed down to the extent of being unrecognizable. It will always feel like it’s not good enough yet.
Here is how you can reframe this perspective: All your customers want is to have one less problem in their lives. They are sitting in front of a bowl of soup with a fork. You have a tiny spoon to offer, but you think you could make a much larger spoon. Your customers will be perfectly happy with the small spoon, because no matter what it can do for them in the future, it will already help them with their bowl of soup, right here and now.
The happy path for any customer is to ship the MVP as soon as humanly possible. You need your customers to interact with your product at the earliest possible moment. Only then can you find out what works and what doesn’t. You need the MVP to become part of their daily workflow. That will surface interaction conflicts and feature inconsistencies better than any reflection ever could.
Understand that your first users will be early adopters and innovators. They understand that new products are not “done” and that them using an imperfect product will make it better. Early adopters are aware of their impact on the trajectory of a product, and they will play with something that doesn’t work perfectly much longer than a mainstream customer ever would.
Ship early, and release to early adopters. If you can get them not just to use your MVP but actually commit to it by paying you a non-trivial amount of money, you will have a real shot at building a sustainable business.
Features a Successful MVP Should Have (Eventually)
If you want it to measure customer commitment, add a rudimentary payment system from the beginning. Give liberal amounts of free trial time, but set an end to it. An infinite trial period might keep people stick around, but it won’t allow you to check if your product produces enough value to warrant paying for it.
If your first customers only stay with the product because it’s free, you do not know the viability of your future business. If you offer a subscription and people start signing up, you know you’re onto something. If they don’t, then you have something you can ask them about.
Security and privacy should be present in your MVP from the beginning: don’t ingest personally identifiable information more than you need to. Use Identity-as-a-Service solutions like Auth0 from the start, and don’t implement your own payment system either. Services like Stripe will handle capturing payment and billing information in a PCI-compliant way for you. In general, don’t keep secrets in your database. This burdens you with being very up-to-date with security standards and software updates, which are not core parts of your business. It also makes your small business a lucrative target for hacking, and this puts you personally at risk. Avoid the whole thing by having experts to this for you.
We found one thing to be incredibly useful in the MVP and all later versions of our product: client-side monitoring. By getting notifications for errors immediately after they happened in the browser or apps of our customers, we could see the stack trace and additional information before your customer even noticed the error. On quite a few occasions, I had already composed a customer service response while the affected customer was still typing their initial message. Reaching out to a customer before they even thought about talking to customer service is one of the most effective ways of delighting a customer in a situation that is usually perceived as a negative.
And since we’re talking about customer service: provide a way for the customer to reach you. Give them an easy-to-use contact form, a real-time chat solution like Intercom or UserList, just make sure they have some way to reach out to you when they need to. You’re interested in their feedback as soon as they have something to tell you. Make that easy for them to accomplish.
None of these features have to be part of your MVP from day one. They just should eventually become part of it in some form or another. You can do a lot of the work manually for a while, working with basic tools such as spreadsheets, email, and even phone calls. But eventually, you will want to funnel all the activities through your (soon-to-be-)automated systems.
MVP Cheats
It is extremely helpful to build a product that solves your own problem. You will know when your MVP is minimally viable since it will solve your problem enough at some point. From there, it will be good enough for others as well. This practice is called “dogfooding,” named after a television ad from the 1970s, where the owner of a dog food brand claimed that he fed his dog food to his own dogs. In the IT world, this process has been made famous by Amazon, where Jeff Bezos forced all his development teams to build internal APIs that would eventually be made available to external developers too. That way, all external services would have gone through a long time of internal use, ironing out the bugs and making the interfaces usable.
Another way of thinking about your MVP is to make it a Minimum Loveable Product. What is the first version of your product that an early adopter might take a screenshot of and share with their network? What features do you need for a user to have their jar drop to the floor? What configuration will make it crystal-clear how much time or money they can save by using your product? Getting your MVP to the point where your customers have no choice but to talk about it is what the MLP is all about.
A Few MVP Examples
One of the finest examples of a successful MVP is EndCrawl, a SaaS in the movie industry, providing end-of-movie credits. John Eremic, the founder of EndCrawl, worked in movie post-production for almost a decade, and he found that every production company had trouble with their movie credits. He wanted to build a service to make this much more manageable.
The EndCrawl MVP was a Perl script that John had built at his breakfast table on a Saturday morning. It ingested a pre-formatted Google Sheet that the movie company would edit with their information. Every time they needed a rendered version of the credits, they would just send an email to EndCrawl, and within 15 minutes, they would receive a link to the finished rendering — a process that usually took between six and 24 hours before.
This is what an initial MVP looks like. It is minimal. It’s just a Google Sheet and an Email. It’s viable. It solves the problem of the customer. It’s loveable. It solves the problem surprisingly quickly. The full SaaS UI came later. It wasn’t required to validate the product: production companies were happy to pay $500 to interact with an API through email. And that’s all your MVP is required to do.
Joel Gascoigne of Buffer took the Two-Page-MVP route. They created a landing page, explained what their tweet-scheduling-tool would allow a user to do, and would show an email signup page if someone clicked the Call-to-Action button:
This validation strategy was enough for Joel to see that there was some interest in a tweet-scheduling product, and he wanted to learn even more about his customers before building out the functional MVP. He added a page in between the landing and the email capture, asking prospects to pick a price level they would be interested in paying, together with a free option. This resulted in some interest in paid plans, which was an indicator that tweet-scheduling was something people would pay for. That was good enough to build out the first version of Buffer, a product that was the foundation of an incredible bootstrapped business.
If It Fails, Don’t Throw It Away
Now that we’ve seen a few successful examples let’s take a look at what happens when your MVP fails.
Like everything in the beginning stages of your bootstrapped business, the MVP is mostly a tool for validation. Expect that some of your customers will not like your MVP for some reason, and your job is to find out why. An MVP with acceptance problems has not yet failed; it’s just incomplete. Understanding where the customers have trouble making use of your product is required to make it more accessible.
Sometimes, however, you might just have created the right product for the wrong customer. In this case, start over, but don’t throw away what you have created. Your future business or someone else might be able to salvage your MVP and turn it into a flourishing business for another audience.
In general, you will have a choice: you can adjust your MVP to solve the problem better, solve a different problem for your audience, or look for another audience. I recommend trying to salvage your MVP before scrapping it altogether. However, at some point, you might want to call it a day and look for greener pastures.
I have done this many times before with products or ideas that didn’t survive the first contact with the audience they were intended for. It hurt every time, but whenever it happened, I understood that I had just learned a valuable lesson about what I thought reality would be like and what it turned out to be. Every time you have to correct your perception of reality, you’re inching a bit closer to your customer’s truth. And that is where you will be able to serve them eventually.
If your MVP causes your customers to pay for your product, great. You have validated that you’re on the right track. You can now focus on turning it into a business.
If it doesn’t result in paying customers at all, even after a few iterations, great. You have validated that you were on the wrong track, and you won’t be pursuing that direction any longer. You just saved yourself from trying to build a business that won’t resonate with customers.
Validating that you are on the right path is why you build an MVP. Either success or failure of the MVP will allow you to become a better entrepreneur.
