Bugs vs. product-market fit: why even startups need to build high quality products

When you're in the earliest stages of your startup trying to find product-market fit, the advice everyone gives you is to ship fast and ship messy, because you'll know you have product-market fit when users are willing to jump through hoops and use your product even when it’s janky and broken.

Having gone through the process of finding product-market fit, and now working closely with many early-stage founders who are prioritizing quality and squashing their bugs with Jam, I think “startups can afford to have bugs” is bad advice.

Why? Founders need clarity to find product-market fit and bugs obscure clarity.

Bugs obscure clarity when searching for product-market fit

One of the best indicators of product-market fit is retention. If users come in, use the product, stick with it, and tell other people who come in and stick with it too, you’ve got it. You’re no longer worried about product-market fit, you’re now thinking about the next phase of your company.

But if users are not retaining, and they tell you the reason they’ve stopped using your product is bugs, it’s really hard to know for sure if that’s an excuse, or if that’s the reality.

Though it sounds basic, it can be incredibly difficult to tell whether there’s a product problem or a quality problem, because they both can look the same: users come in with a need for what you’re building, and maybe even a willingness to pay, then leave after trying out the product.

When you don’t know whether your retention problem is caused by not having product-market fit, or whether it’s caused by having major bugs, it’s really hard to make important decisions for your company. Without that clarity, how do you know whether you should focus on continuing to experiment to find product-market fit, or focus on fixing your bugs?

Bugs deter progress for startups searching for product-market fit because they obscure the clarity founders need to make important decisions about the product direction.

Reid Hoffman is right: startups should launch fast. But then they need to fix their bugs.

The idea that startups should launch fast and before they feel ready was coined by Reid Hoffman more than a decade ago.

If you're not embarrassed by the first version of your product, you've launched too late.

He’s right – startups should get their initial product out the door as fast as they can. This creates momentum, unlocks learning, and most of all, puts needed pressure on the team to make the product as good as possible, as quickly as possible. After all, when are you going to feel the fire in your belly to fix a bunch of bugs, before or after you’ve told people to start using it?

But people have taken his “ship fast, be embarrassed” advice to mean that early stage startups can afford to have products that they are embarrassed about, and that’s not helpful to founders.

Having said that, some startups can afford to have bugs in the product. If there are truly no alternatives to the product, if customers pay a lot of money for access to the product, or if the product is not mission critical, bugs may not lead to loss of retention or murkiness about product-market fit in the same way.

But if you are building a product where there is an alternative, or it’s critical in someone’s workflow, bugs can be a blocker to someone using your product, even if it’s exactly what they need. That makes it hard to know if users are leaving because they do not want to use the product, or because they cannot use the product.

How to ship high quality software as a startup

In my interview with Omar Torres, Chessly’s founding engineering leader, he explained why quality is the number one thing he is prioritizing on his engineering team:

Quality is a big part of what I try to push. Writing code that is free from bugs, that is well tested. From my experience, I’ve seen that the lack of quality and reliability stops or hinders growth and progress.

That focus on quality for early stage startups is important, so how can you do that in practice?

First, the smaller the surface area, the easier it is to keep things high quality, especially with a small team. Part of the reason a “minimum viable product” is so important is that the minimum part helps keep things small enough to maintain well. Early stage startups should aim to keep scope as small as is reasonably possible. (Reasonably is key – there are of course exceptions like Rippling where the company strategy is to cover a large surface area out of the gate.)

Additionally, quality is a full team effort. It takes everyone on the team to be dogfooding the product, giving feedback and reporting bugs.

Even with everyone on the team participating in testing and dogfooding, it can be useful to bring in a QA tester early to systematize testing. Here’s a guide to hiring a great first QA person.

Lastly, it’s also helpful to set up lightweight processes, tools and workflows that improve the team’s ability to ship quality software.

Early stage companies in today’s hyper-competitive environment must prioritize quality

When you are an early stage founder, you are in search for clarity. Bugs obscure clarity.

While there’s an old startup trope that your product should be so valuable that people will use it even when it’s buggy, that advice does not seem to stand in today’s hyper-competitive environment.

With so many alternatives (more companies were started last year than ever before), and with people now reliant on software products to live their daily lives, if your product doesn’t work reliably, people will probably not use it. Not knowing if you have a product problem or a stability problem will make it much harder to navigate the search to product-market fit.

So if you are a founder building a startup where there are alternatives, and the product you are building is mission critical to someone’s day, do launch fast, but launch something small in scope, and then use that momentum from launch and pressure of being public to go and quickly fix all your bugs.

That way, you’ll create clarity around the product’s viability that will help you make the critical decisions on your way to product-market fit.