The latest news from Balsamiq:
How do you decide which bugs, chores and features to work on next?

Trouble viewing?
View it online.

The end of our 2-part series on how to prioritize software engineering work.
For startups and mature companies alike!

Last month we shared how we decide whether to work on bugs, chores or features, depending on the age of our software.

This 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 at Balsamiq.

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.

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 from a couple of months ago? A well-written FAQ, a tutorial or even a personalized email reply with a workaround might be the right solution.

What happened at Balsamiq in October

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 two new articles on our Wireframing Academy: Designing Effective Data Tables and Usability Testing Wireframes with Your Users. Leon also gave a great talk called How to Use Wireframes to Improve Team Communication and Participation - check them out!

We keep sponsoring many online events, and continue to work on making our company run smoothly and efficiently. Among the many efforts in the last month, we’ve improved how we audit customer data for GDPR, we improved how we run monthly all-hands meetings, we’re doing our yearly company-sponsored employee donations, we’re planning for Q4 and beyond, and much much more.

UX/UI links for October

State-Switch Controls: The Infamous Case of the "Mute" Button
"Remember, your goal with an on–off control is to make sure that users quickly understand both the current state, and what will happen if they press that control."
-Raluca Budiu

8 First Principles of Software Design
“Working code is the ultimate source of truth for everyone, including the users.”
-Tom Parandyk

Where in the Design Process Are We?
“Challenging the brief and pushing for a solid product/market discovery phase is sometimes needed and will help the project in the long run.”
-Martin Sandström

Break Apart Your Features Into Full-Stack Slices
“Think of your feature like a stack of pancakes, where each pancake represents a layer of your system. Eat a piece of all pancakes at the same time.”
-German Velasco

Dig & Document: Before You Start Designing
“The very first step in the process needs to be to understand the requirements.”
-Vasudha Mamtani

That's it for this month!

That’s it! We hope this 2-part series was useful to you.

Let us know what kind of topics you’d like us to cover in the future! More about how we work? Tutorials about our products, or wireframing in general? Advice for bootstrappers? Just reply to this email and let us know, we aim to please! 😊