Part of the time I manage a remote team of engineers and we’re always kind of on a seesaw of fixing bugs versus working on new features — to the point where I don’t think we’re fully effective at either. Should we spend two weeks or even a month not working on any new features so we can figure out all of the problems we’re having (and risk telling our small group of investors that growth has stalled)? Or do we continue doing what we’re doing and accept it as the reality of the modern undermanned and underfunded startup?
We actually split the workload and have a Sustaining team that work closely with support that handle identifying and writing the fixes, then submitting them to the Core Dev teams to review and fix. The focus is Features, but bugs need to be properly managed. Trying to juggle between the two within one team hurts customers and creates challenges for the Dev teams involved.
There are two trains of thought where having the Dev teams handle bugs as well as features, but being realistic, it's not fair to the business, customers or the feature developers.
If the bug volume is heavy then that speaks to other issues tied to design and quality, but the business and customers shouldn't suffer by trying to force developers to try and juggle both.
Bugs will upset users. New features they do not know about will not.
Focus only on keeping users happy.
You can't really look at it that way. You must fix bugs or you will lose customers and earn a bad reputation that will block future sales. You must offer new feaures or you will be seen as lacking innovation. Given the pool of talent you have to do both of these, you need to divide them into bug fixers or new feature developers. You have to know which matters most to current and future customers to do this division properly; if you don't, get out there an ask them!
It's really so subjective and depends on level (severity) of bugs. Minor annoyances are very different to bugs which effect or prevent operation (or worse, corrupt data).
Generally we address (prioritized) bug fixes and feature upgrades at the same time. If we are busy with new feature and discover a high priority bug then we stop and create a hot fix, rolling it into current release as well as new release we're busy with.
Also, what one person would determine as minor may actually be major to customers, especially if effecting the way they use the system. For example a click and drag that didn't always work while not fundamentally dangerous, but will soon become very annoying and may cause you to lose customers.
As someone who has and is on both sides of this table (investor and developer), I'd much rather have a solid and reliable system before adding new features. A system that can't be relied on due to bugs is going to upset customers (most expensive) and is going to tie up expensive customer resource services as well as (potentially) development time for quick fixes—my experience is that it's better to bite the bullet and fix what needs fixing. This doesn't need to be everything though. As an analogy, a car will run just fine if one of it's wheels has a slight wobble, provided the cause of wobble is understood. So sticking with the car analogy, I'd say aim for a car that is drivable, that you would be okay driving your precious family in even if one wheel has slight wobble and there is an occasional squeak.
I have an article about this here: