Bug Expectations

When someone runs into a bug our natural inclination is to help them feel optimistic. We likely can’t personally fix the problem and we want to reassure them that their issue is important and will be fixed. This might create short-term happiness but it risks long-term frustration and disappointment.

It’s a lesson that’s often learned the hard way. You tell a customer that something will be fixed only for it to linger in the bug tracker and, 6 months later, cause that customer to be furious with you. It happens to all of us. I sent far too many replies like this early in my career:

Unfortunately this is due to a bug on our side. Don’t worry, though, I reported it to our development team and we’ll get it fixed soon. I’ll let you know when that happens and thanks for your patience!

So optimistic! But there are three problems in that type of response: it promises a solution, it suggests a timeline, and it fails to provide a workaround.

We just created a cascading series of problems for our future selves. We didn’t provide a workaround so the person we helped is now stuck and likely to ask for an update next week. We promised that we would fix the issue and put our development team on the hook for an expectation they had no hand in creating (and are likely unaware of). And we set a timeline and created a ticking clock in our customer’s mind.

Plus, if we don’t deliver we let the customer down twice: we have buggy software and we can’t follow through on our commitments. Let’s avoid that! Instead, it’s best to set less concrete expectations and follow three guidelines.

Figure out if there’s a workaround

The best bugs are those we can avoid by working around them. They still need fixing but avoidable bugs are simply less annoying (for both us and those we help). To find the right workaround, ask the person about their ultimate goal. If you listen closely to their goal (rather than the exact steps they want to take) you can often find an inconvenient-but-feasible solution. It may not be what they hoped for, but it gives them a way to move forward.

This also lightens our self-imposed pressure. Avoiding the bug is already a positive result! You can close the conversation with something like, “We’ll look into what’s happening here and I’m glad we got another option set up for you.”

Decide if you’ll keep the customer updated

Bugs that people experience every day merit periodic updates. Those customers, even if they memorize a workaround, will have a daily reminder of your product’s flaws. But that’s not every bug, and you certainly don’t have to keep every customer updated about every bug. A good question to ask yourself is whether this bug exists in an infrequent product flow or in a pattern of regular usage. Infrequent bugs mean there’s less value in ongoing updates, especially if you already helped them avoid the bug with a clear workaround. For those customers the bug may just be a one-time occurrence.

It’s best to have a consistent approach across the team so that customers get a similar experience once they run into a bug. One way to create that team-level consistency: audit the last 100 bug tickets you resolved, measure how long it took between initial report and resolution, and measure how many total replies your team sent out with status updates. If it’s taking months to resolve the typical bug those followup replies are likely wasting time for both your team and customers. Calibrate your approach to your customers and your product as the right answer depends on context.

Promise information, not solutions nor timelines

This can push against every tendency you have. The problem is that software development is a complex process in which even seemingly “simple” bugs can stump a team or sit in a backlog.

The only situation in which I feel comfortable providing a timeline is when the bug is already fixed and that release is already planned. In other scenarios there’s just too much that can go wrong.

The best approach is to set simple expectations. It’s better to promise future updates instead of specific next steps. As one example, you can write, “We don’t have a timeline right now but if that changes I’ll let you know.” and avoid writing, “I’ll let you know once our team has [investigated, fixed, or looked into] this bug.” People may be disappointed, but you’re at least not giving them false or risky hope.

One caveat: the above advice applies best if your product serves individuals. If the bug impacts a 6-figure enterprise account then you very likely must solve the bug and keep them updated. But work as a team and match expectations to what your development team can deliver.

People ultimately respond best to honesty. When they run into a bug in your product they’ll often feel fixing it should be your top priority. But we know that’s not always the case. It’s better to help them feel heard without setting them up for future disappointment.