The latest news from Balsamiq:
A behind-the-scenes look at how we decide to work on product features, bugs, and chores.

Trouble viewing?
View it online.

A 2-part series on how to prioritize software engineering work.
For startups and mature companies alike!

Bugs, Chores, and Features

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 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.

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!

Stay tuned for part 2 next month - we’ll discuss how we keep track of what to work on, how we prioritize between different Bugs or Chores or Features, and some general useful principles we follow.

What happened at Balsamiq in September

As always, we released several improvements to our web apps, and did a Desktop release with all the same improvements. You can read all the details in the Release Notes.

We published a bunch of website improvements: we merged the old newsletter and press mentions page into the blog, which we now call Company News. We also published a new detailed page for educators on how to use Balsamiq in a classroom setting. We also published 2 new articles on our Wireframing Academy: Ten Principles of Effective Wireframes and Evaluating Wireframes with Usability Inspection Methods.

I was interviewed for Product School, and we keep sponsoring podcasts such as Founders Clinic, SaaS District, and Boagworld. What other podcasts for founders should we support?

Last but not least, we continue to work on our company itself, forever improving our processes to ensure our longevity.

UX/UI links for September

In Praise of Breadboarding: An Essential UX Tool
"Designers need a way to determine how a product’s content will behave across multiple screens without being dragged into making interaction and visual decisions too early."
-Karina Kedo

The Power and Paradox of Bad Software
“The software people get amazing tools that let them build amazing apps, and the climate people get lots of Fortran. This is one of the weirdest puzzles of this industry.”
-Paul Ford

Task Analysis: Support Users in Achieving Their Goals
“It’s important not to confuse goals with tasks. For instance, a user’s goal isn’t to fill in a form.”
-Maria Rosala

Don't Draw the UI, Draw the Priority
“The priorities should guide the pixels and not the other way around.”
-Robin Rendle

7 UI Patterns in E-Commerce Apps
“Try to create different types of cards for different types of information. This sets information apart visually, and helps users learn the visual language.”
-Jennifer Jhang

That's it for this month!

That’s it for this month. Let us know what you think of our prioritization system, or tell us about how YOU do it! We’d love to include your quote in a web version of this article in the future.

See you next month with part 2 of how we prioritize our product work!