lean-startupIf you read The Lean Startup, Eric Ries mentions that it doesn’t matter if your product is buggy. Because the goal is to understand the market.
If you listen to YC “How to start a startup”, lesson 13, Kevin Hale says that the best way to have products users love is to go the extra mile from a so-so product to a very fine polished product with zero bugs and a lot of humour.
Of course, both agree on a very short feedback loop from the customer, in order to achieve a faster product market fit.
The question is purely about bugs and polishing.
According to your experience, does the presence of bugs / the polishing influence the product market fit?
Should I try one more A/B test or first fully debug and polish the previous one?
We programmers hate bugs, but maybe wrongfully so. Is there real-world data on this?
Remember that bit in the Lean Startup, where Eric talks about his product IMVU and how the team learnt so much by bringing in a person who met the target demographic to test out the product?
That is a very cheap and quick way to get realistic feedback from people who would actually use the product. Invite people in the target demographic to a test session. Sign NDAs if necessary. Have the dev team observe how the user is trying to figure out and use the software (See if the user can do the whole process, download, install, configure, basic use, without instructions from you). Note the difficulties, bugs they encounter and fix them before release. Usually bugs discovered on such a preliminary round is going to affect the usability of the software. Sometimes devs worry about bugs needlessly. As Eric mentions in the book, some of the bugs they fretted over where not even discovered because they were deep in the levels that users normally don’t go into in the early days.
Rule of the thumb is to ship functional products (if your product is augmented,then at least the MVP core of it should be functional). Do a closed door beta test. Even a small one with just one or two people unfamiliar with the system from the target market can teach you lots. Second, if the bugs are first or second layer or effects core functionality, you should take time and fix them or offer a work around. If the bugs are deep, have it in your bug log, prioritize and work on them. If you are nice, be ready with a known issues section on your website or in your documentation.
I think the key is here that your product should be at a stage where it is barely usable. The related concept of minimum viable product is that it should serve its intended purpose. If it is too buggy or crashes frequently then you are clearly not read to ship it to the customers. The lean startup methodology suggests that you should focus on one feature and get that feature right. Other features and improvements can be done overtime.
So, presence of bugs in the key feature of the product will clearly affect your customers while polishing and adding new additional things can be done once you have some more feedback.
All content is licensed under CC BY-SA 3.0.