Bug Fixes vs Features

When do you ship and when do you fix?

There's never enough time to build everything your users want and to fix everything that's broken. As a PM or a founder, you know this better than me.

So, how do you balance between bugfixes and features?

It might sound like a simple question, but it really isn't. Focusing on the wrong thing will waste your resources at best, but so will not focusing at all.

I've certainly made my share of mistakes with this, both as a PM and as an entrepreneur running a software business.

Now, I keep this in mind when approaching the question of bugs vs features:

  • Always remember the big picture.
  • A fixed bug can be a feature.
  • The hunt for technical debt never stops.

But first, a quick personal story from my entrepreneurial days:

Too much focus on one thing

During the first years of turning my product into a business, I had a feature-first mindset. And it made sense: I was a software developer, but I didn't enjoy the process of writing code as much as I enjoyed shipping cool stuff.

So adding new features to my product was the most important part of my life. Each next release would have at least one major feature and a whole bunch of smaller ones. The changelogs were all about "Feature X added" and "New feature: Y".

Fancy!

Bugs and fixes were of course a thing, but it wasn't a priority for me. Fixing bugs wasn't as fun, and I didn't think the problem was that bad anyway. "What sells my product are the features, not bugfixes. I'll take care of the bugs later, as soon I'm done with this next big thing I'm currently working on."

Fast forward a year or so. My product has dozens and dozens of features, and it's selling relatively well. But there's a problem.

Three problems, actually:

  • The product is literally unusable due to all of the bugs.
  • My customers buy the marketing, but they hate the execution.
  • I spend most of my days doing technical support, which I hate.

At some point, I've had enough.

The solution? Not just a feature freeze, but a full-blown feature reduction and a massive bug hunt.

I've spent the next couple months nuking features left and right and fixing hundreds of bugs. I didn't have feature analytics back then, so I prioritized based on market research, user feedback, and my gut feeling, for the most part. Gut feeling isn't a great prioritization framework, but sometimes you gotta rely on it.

The results exceeded my expectations. I was worried the customers would complain about the feature reduction, but the reality was that most never even noticed. Instead, they were delighted by the stability of the new versions. And I was over the moon with our support volumes dropping to near-zero.

It's been a long time, but this experience taught me two lessons:

  • You don't just build every feature your users ask for, especially if they're a small, but vocal minority. Every new feature comes with strings attached.
  • Sometimes the best thing you can do for your product is to remove features and fix bugs. A fixed bug can be a feature if it's critical or widespread enough.

It was a drastic decision, though. And while a feature freeze and reduction worked out in this case, it isn't always the right option. I had a different experience in one of my recent roles where it made more sense to go fast and break things without pausing to clean up the mess, and that turned out to be the right choice, too.

So instead of generalizing, here's how I think about bugs vs features today:

Remember the big picture

The big picture is what's most important for your product and your company.

As a PM, you probably know this already. It's what you find in your company's vision and mission statements, in your CEO's memos, in your strategy document, in conversations with users and stakeholders, and elsewhere.

If you're a solopreneur or a small business owner, understand and define these things early. Having them written down will make your life easier in the future.

The big picture can be about the design and the user experience. It can be growth and expansion. It can be about sustainability. It can be about stability and reliability.

Ideally, it's not just a boilerplate document, but something the company actually believes in. Keep it in mind at all times, it will guide your priorities.

A fixed bug can be a feature

"Fixed a bug where the app would randomly crash" might not look as fancy in the changelog as "Released a shiny new feature that lets the user do literally anything".

But if reliability is among the key aspects of your industry and those random crashes are indeed driving your users insane and away then fixing them could be a win not just for your users, but also for your brand perception, and, in turn, sales.

For this reason, I'm against the idea of treating bugs and features as separate entities. No matter which prioritization framework you prefer, you can and should always compare bugs and features side by side.

This isn't comparing apples to oranges. They're all apples!

The hunt for technical debt never stops

There's always room for improvement.

Even if your product backlog and your social media feeds are not overflowing with bug reports and complaints, there's always something your engineers could be doing to improve the reliability of your product.

A popular notion is that an engineering team needs to be spending 20% of the time on tackling technical debt. I'm not a proponent of a specific percentage, but I do agree with the idea that the improvement work should continue no matter what.

Unless you're absolutely out of resources and the survival of your company depends on you shipping new features, allocate time for fixing things that are broken and maintaining and reinforcing the ones that aren't yet.

The worst thing you can do is go fast and break things when you can afford to go just a little slower and break things a little less, and then be forced to scramble and drop everything when an emergency hits and it all comes crashing down.

Popular tags