How bug-free should your MVP be?
I know MVPs are supposed to be lean in terms of having just enough features to address the problem, but should they be virtually free of major bugs?
I know MVPs are supposed to be lean in terms of having just enough features to address the problem, but should they be virtually free of major bugs?
I think that's one of the main ideas behind doing something as an mvp. If it's truly minimal then you - in theory - reduce the surface area for bugs and are more likely to have thoroughly tested and polished what little is there.
My personal opinion is that user experienced (something they notice) bugs are a major trust and credibility breaker. Whenever I visit someone's new project and something doesn't work I immediately feel that they are about 75% less credible and I trust their ability to make my life easier or better far less. I'm much more likely to leave the app entirely, similar to closing a tab on a slow website. I know it's harsh but it's not really a conscious decision on my part and it wouldn't be helpful for me to sugar coat it here.
As a developer thats scary for me because we think of an mvp as almost like a tech demo, a beta, so of course it's going to have bugs. But in the end I think it's better to lack a feature now and implement it later, than to present one that is likely to break to a user.
That's quite scary for anyone trying to test out buggy products!
I think as long as there is a sufficient amount of expectation setting then people wouldn't be so put off. As long as it's made clear that it's in the early stages (and the price reflects this). But the certainly needs to solve a need either by providing useful features or be great value. In either case I think bugs are acceptable to an extent.
Would you say you've found bugs have discouraged you from continuing to use a product even where you knew it was an early stage MVP /beta?
I definitely agree that you can alleviate this with some expectation setting like you mentioned.
I'm not always the most forgiving user unfortunately. I've abandoned products before when I've run into bugs quickly enough or often enough. When I'm trying out new products I'm usually in my most cold and calculating mode. Typically I have a real and immediate problem that badly needs to be solved for me to even be looking, which makes me more easily frustrated and quicker to jump ship. That's usually when I'm looking for my business needs though. Personal needs I tend to be more easy going.
Generally, I would have thought the more pressing a need is, the more forgiving one can be, especially if the potential solutions are scarce.
That's a good point about the difference between business needs and personal needs. Businesses have particular requirements which, if not satisfied, can lead to negative impacts on revenues, staff, reputation etc.
At the risk of sounding vague, this depends entirely on what the bugs are and what your goal is with your MVP. If you're not sure what your goal is, this is a great time to put some thought into it. Not everyone builds an MVP for the same reason.
For example, if I was trying to create a new wearable computer that goes on my face, I might build a non-functional prototype to wear around just to see if there are any fashion or comfortability issues that make it a non-starter. Technically, a completely non-functioning product is the ultimate bug, but that wouldn't matter for this particular MVP.
Or let's say I was building something highly transformative, like an AI system that could design a website based on a user's text description. My goal might be to prove that this is game-changing enough for me to raise millions of dollars. In that case, I might be looking for early adopters to use it enthusiastic despite some major bugs, because the benefits are worth it.
Or I could imagine building a new blogging platform, but wanting to minimize the number of features I spend developing. If my goal was to test whether or not feature X was sufficient enough for people to start paying, then I would consider it important for X to be relatively bug free, but I wouldn't care much about bugs in features Y and Z.
And then, of course, there are products that require so much trust from your customers that the slightest hint of a bug anywhere can lose you business. I won't eat at a restaurant with dirty floors and tables, even though the only thing that matters is the kitchen.
So it really depends.
This is fair, it really does depend on the context. I also think that the type of niche you're targeting matters.
If it's a B2C app, you're going to get much higher expectations from consumers who are used to slick bug-free UI in their daily experiences. Even in B2B, with the consumerization of tech services, users I'm businesses are starting to expect the same high level of polish they receive in their personal lives.
So I think some niches and groups of customers will be less tolerant of bugs than others, it's just about finding the right ones (or working hard to fix everything)!
This comment was deleted 7 years ago
Watch out or you'll get an angry mob of indie hackers coming after you (me included) :P
Then again, I guess you have to disrupt yourself or risk being disrupted by someone else!
It really depends on the market. I'll gladly tolerate and help report anything from minor rendering bugs to full on crashes in a beta release of a game.
For something like payment processing, I have virtually no tolerance for bugs, even if they're purely cosmetic.
Software without bugs does not exist in real life š
That said, I'd absolutely avoid show-stopping bugs, or bad crashes, and have some way to show a friendly message rather than a weird error message.
I'm in the "squash all the bugs" phase with my project now, and while it's a pain to track everything down, I also know that if users found those bugs instead of me I'll lose their trust.
Famous startup quote: 'If you are not embarrassed by the first version of your product, you've launched too late.' - Reid Hoffman.
I think you should try your best to test and remove obvious bugs up front, if you've found them your customers will too. But generally 99% of bugs are picked up by my customers doing things I never would have expected them to, so you just have to launch as quick as possible, let customer usage play it's course and try to be as responsive as possible.
I've seen that adding something like a 'BETA' banner in a corner of the site significantly reduces user's angst when they hit an issue, it's somewhat expected.
While this might be true about your first version, it shouldn't be due to bugs. Rather it should be because you launched in order to get feedback and realized that your UI/UX was lacking, maybe you were missing killer feature X or maybe your copy was completely off. You need to remember that an MVP is your minimum viable product (emphasis on viable). If your product has a bug in it's core, I would consider it incomplete and not viable.
The classic example is one were your product is a form of transportation. You might start with a skateboard, then a bicycle, motorcycle and finally a car. You might be embarrassed at the skateboard but it was still a successful mode of transportation without bugs; just not your final product. (image reference:
[1] http://assets.uxbooth.com/uploads/2015/01/Spotify.png)
TL;DR: Minimize your features and make sure they're bug free. Your MVP should be solid and minimal not a lot of features with some bugs.
Whatever you choose to do needs to be done with a high level of quality (nothing is perfect). The whole MVP thing is about restricting what you choose to do, not how well you do it.
Maybe I can offer this as an example:
My web-app https://SalesWolf.io has bugs, but it was enough to generate 160 users and some paying customers. There's still bugs but I'm working to improve them now that I have user feedback
For mobile or desktop applications, crashes will kill your users interest in it. So, no crashes regardless of how alpha it is.
My products still have bugs in them. They were functional when I launched, but had a lot of bugs.
If you're creating something that people want or need, they'll overlook some bugs.
Don't let perfectionism get in your way. Launch the product. Fix the bugs as they pop up and keep improving. Sure, you'll loose some visitors, but you'll gain extremely valuable data from those that stick around.