How We Prioritize Product Work

A behind-the-scenes look at how we decide to work on product features, bugs, and chores.

We generally categorize software engineering work in these 3 buckets:

Bugs

Bugs are user-reported problems with the software, which generate support tickets.

Examples of bugs we have fixed are simple typos, the web app logging people out every day, or the fact that some people couldn’t register the desktop version because we didn’t support proxies.

Some Bug fixes are just simple string edits, others require a whole bunch of new code to be written in order to fix them.

Fixing bugs makes the support team happier.

Chores

Chores are problems that are invisible to the end user, but that can cause problems if not addressed.

Examples of chores are adding metrics to make sure you get an alarm before the server runs out of disk space, updating some libraries to keep it secure, updating our build processes so we can test things quicker, refactoring old code, or adding automated tests.

Fixing chores makes the dev and ops teams happier.

Features

Features are new bits of functionality that users can see and use.

Examples of features are adding search and replace, making the app work on tablets, or redesigning how a feature works.

Adding features makes the marketing and sales teams happier.

Working on bugs, chores, and features makes our customers happier. 😊

When we prioritize work, we think of each bucket as an accelerator pedal.

The job is to decide how much to push on each of the 3 pedals.

No matter how big your product team is, there’s only so much you can push.

Sometimes you only push on one pedal for a while, but usually you push on all 3, with various strength.

How do we decide what to push on?

It largely depends on the age of the product.

Before launching a new product, the focus is pretty much ALL on Features.
As we approach launch, we switch to Chores (setting up build environments, for instance) and make sure we don’t have too many Bugs.
Right after launch, the focus is pretty much ALL on Bugs, to make the new young product as solid as possible as quickly as possible.
After a few months, especially for an online service, we probably need to focus on scalability-related Chores.
Once Bugs and Chores are manageable (i.e. support is fairly happy and the product is fairly stable), we can entertain working on Features, a little bit at the time.
When a product is over a year old and is in its adult ‘normal’ state, we push more or less equally on all 3 pedals, giving a preference to Bugs.
When a product is old and in maintenance mode, we pretty much only work on Chores (security fixes), and Bugs if deemed absolutely necessary by Support. The rest of the team usually starts working on features for the next product, and the cycle starts again.

Here’s a handy chart for the visual learners like me:

Why do we prioritize bugs over the rest?

For several reasons:

We have over 500k customers, and only 3 tech support people, who don’t even need to do support full-time. This is insanely good and efficient for the industry. This is only possible if our products are super-solid.
Having solid products is a competitive advantage. We have the reputation for having great, non-buggy software. A company that puts out software that’s noticeably buggy cannot be trusted. If they don’t care about the quality of their main product, are they going to be just as sloppy when it comes to customer data privacy or even accounting and finance?
We value having a solid product over having a beautiful or feature-rich product. Let’s do fewer things, but do them very well.

Another reason was suggested by our customer Nils Faltin:

Bugs can breed other bugs. Even a small malfunction can lead to a bigger malfunctioning in another program part down the road. So you should be eager to extinguish the small fires before they set the house on fire.

Why do we always use a mix of all three?

Again, for several reasons:

It’s impossible to work on features only once ALL known Bugs are fixed, because Bugs just keep coming forever, and some are not worth spending time on until other Chores or Features are built.
Only fixing Bugs for months and months without working on anything new is depressing — just ask our editor team about our year-long beta period… 😉
Some Chores can be fixed at a very low pace — there’s no need to fix them all at once, and they’re a great type of work to do if you happen to have a spare hour or two.
If we don’t give customers new Features for too long, they leave. Our reputation as innovators takes a hit. We can’t afford that long term.

We, of course, consider the availability of our developers. If we don’t have enough resources to push hard enough on what we want to push on — and we can afford to — we grow the team!

How do we keep track of what we could possibly work on?

At Basecamp, they don’t keep a backlog. We also don’t have a single giant backlog…we have several! 😊

We have a 12-year-long history of bugs and feature requests in Pivotal Tracker, labeled by feature. We add a +1 to each story every time it’s requested, and wrote a little tool to tally up the votes. We also have our own home-grown project management system where we add future feature ideas. Our support team has their own lists of things they’d like us to improve.

I think these various lists are very useful. Writing something down ensures that we won’t forget it, and is a great way to stay focused on the task at hand, instead of getting sidetracked in less important tasks. Just add them to the backlog, and when the time is right we’ll get to it.

The process we use to review the backlog regularly is what we call Priority Review Boards. It's simple and effective, check it out!

How do we prioritize between different Bugs?

Bugs that generate more support come before others.
Bugs that don’t generate a lot of support, but that cause a lot of damage when they do happen come before others (data loss, crashes).

A useful mantra to keep in mind, when dealing with bugs, is this: Recent does not mean urgent. Just because something was reported recently, it doesn’t mean it should be worked on first! Resist this very natural temptation, and always weigh urgency against other work already in the backlog.

How do we prioritize between different Chores?

Chores that, if unaddressed, will cause “fires” (like server downtime or data leaks) come before others.
Security issues come before others.
Chores that reduce our likelihood of regressions come before others.

How do we prioritize between different Features?

We always try to achieve feature parity as much as possible between our versions — this makes the product easier to understand, easier to support, easier to document.
We consider market changes (new platforms or new APIs we can use).
We often bunch up related stories — we look at the Pivotal Tracker labels with the most stories and we work on a bunch of little low-hanging fruit bugs, chores or features that are related to each other.
Tackling them together is more efficient than doing them with time in between.
This is why it’s very important to use labels, and use them well.
We sometimes splinter off one or two people for a while to work on bigger, big bang for the buck features. These are typically editor features which each product will inherit automatically, or with little work. Examples might be image links, search and replace, the new Balsamiq Wireframes codebase…
We consider supportability issues: for instance, we work on features that don’t change the BMPR format first, to give customers time to gradually update from Balsamiq Mockups 3 to Balsamiq Wireframes.

I encourage us to NOT look at competitors. We should be aware of what they offer and how they position themselves, but we shouldn’t spend time looking carefully. We win because we have a tighter connection with our customers, and because of our own focused and innovative vision.

Be confident in your own abilities, and move forward.

Another good mantra to remember about features is this: don’t scar at the first cut. Just because a few people are very vocal about something, it doesn’t mean that it’s urgent, or that we should do it at all. Make sure it fits in the long-term vision for the product.

Last but not least, remember that not all solutions involve coding! Remember the whole product concept? A well-written FAQ, a tutorial or even a personalized email reply with a workaround might be the right solution.

That's it! I hope this behind-the-scenes look will be useful to you. I also spoke about this topic as part of this interview. Let us know what you think!