You’ve done your best to avoid it, but the inevitable has happened – a user has run into a bug. Now whatever purpose brought your user to you has been suddenly blocked. And while eliminating bugs may be low on your priority list (“We eliminated X bugs in the last quarter” isn’t the most compelling sales pitch), for your users, bugs likely render your product useless. Whatever feature you’ve built might as well not exist.
Of users that encounter a bug, only 1 out of 26 will complain to you about the bug. And 88% of users will simply leave. The vast majority of the time, you lose a user and never even learn why. You’re already losing customers and are going to keep losing customers until you can eliminate the bug. In a world of continuously increasing user expectations, you have to accelerate how quickly you go from a bug arising to a bug being fixed to minimize losses.
Let’s be optimistic and assume that a user reports the bug through whatever bug reporting system you have. Even now, you may be a long way from solving the problem. You still need to find out what's causing the issue and figure out how to fix it. But going from bug report to bug fix requires communication among people with different knowledge bases and incentives, and, as anyone in engineering will tell you, the communication workflow for giving accurate and valuable accounts of bugs is far from excellent. Diagnosing and fixing reported bugs is an inherently slow and noisy process, easily lasting weeks or months.
The slow process of reporting bugs
Let’s quickly walk through what a normal debugging process looks like for software companies.
A user runs into a bug and decides to report it.
The game of telephone begins when a user reports a bug. Unfortunately, users often don’t have a background that prepares them to write good bug reports and can easily give an account of what happened that misses necessary information or is inaccurate about what led to the issue. The user who runs into a bug likely doesn't know what seemingly irrelevant details might actually be crucial for causing the bug or the right terms to describe what they did.
Support cares, but can’t solve anything.
The first point of contact is unlikely to be a developer who would best know what questions to ask to identify what might have caused the bug. The customer-facing support folks who are the user’s first point of contact are heavily incentivized to care but also aren’t capable of resolving the underlying issue, and likely don’t know what an engineer needs to know in order to diagnose and fix the issue.
The engineering team tries to interpret.
The support team sends the issue ticket to a product leader who interprets support’s description of the bug and decides how highly fixing the bug should be prioritized. But the Engineering team likely hasn’t gotten all the information they need, so they have to either fill in the gaps themselves – and perhaps miss important details – or guess that some recent change they made must be responsible for the bug they’re just now hearing about.
Engineers (try to) tackle the right problem.
Armed with incomplete and potentially misleading information about the bug, devs are assigned the task of fixing the user’s issue. They likely won’t be able to replicate the user’s problem, or they may be able to fix something but not the thing that was giving the user problems. Maybe they test if a recent change to a checkout button is causing problems for a user who can’t check out, only to find everything working as intended.
The developer reports to the Product Lead that all is fine, but all isn’t fine. Perhaps integration with Paypal has broken, but the user didn’t mention that they were trying to use Paypal. While figuring out what to do about the bug, Product Leads may need to have several back and forth discussions to help the developer team understand what has gone wrong and how significant the problem is.
Now everyone is annoyed.
At each step of the communication process, we’ve gone further from people who are most directly emotionally affected but can do the least (users and the support members they communicate with) to people who can do more but are less closely connected to the end user’s experience. Support wants to fix users' issues as soon as possible, but the engineering team who can fix bugs has its own goals. Fixing things that are supposed to work feels like a step backward for developers, so receiving a message saying “Hey, this is broken” can feel like a nuisance, especially when you know you might be in for a wild bug-diagnosing adventure.
This process is doomed to waste time – even when everyone is prioritizing fixing the bug, there is still a game of telephone communicating the issue from user to dev that makes the dev’s job harder, because the dev gets an incomplete or inaccurate description of the bug. We’re relying on a slow process that also makes developers’ work harder because it relies on their ability to understand how users are seeing an application when they have the least customer-facing experience. Users get impatient, support feels helpless, and developers feel like they’re being sent distracting and impossible tasks
When traditional debugging can help
Traditional debugging comes in after we’ve already played this game of telephone. This means that traditional debugging can only save a small amount of time compared to the total amount of time between a bug arising to it being fixed. The slow game of telephone happens outside of what traditional debugging does, so most of the time that a bug spends driving your users away, traditional debugging can’t help you.
To significantly limit the damage that bugs can do, we should expand the role of debugging to supplant the game of telephone in our bug removal process. If debugging can take on the role of communicating to developers what happened to cause a bug, then it can be orders of magnitude more helpful in reducing the time bugs spend doing damage.
Debugging done better
We need to feed developers an accurate and robust description of what happened leading to a bug as fast as possible. Bug reports should give an objective account of all the actions a user took leading up to the bug, and they would ideally do this while minimizing the responsibility the user has in describing the bug.
PlayerZero packages a user's step-by-step experience into an easy to reproduce simulation without requiring the user to give any additional information. The user can send the developer everything they need to understand and solve the issue without having to describe what happened themself, because PlayerZero passively logs and bundles this information. By sending an objective and complete account of bugs users experience directly to the engineers that can fix them, you not only make it easier to find a solution, but you avoid wasting time understanding and reproducing the issue.
PlayerZero eliminates the game of telephone.
By eliminating the need to write bug reports, PlayerZero cuts the time lost and communication problems that come from the game of telephone between the users who experience bugs and developers who learn about them. No more translating what Support says happened; PlayerZero facilitates immediate communication of exactly what happened leading up to a user experiencing an issue. It gives developers better information about particular issues faster and allows them to more accurately understand where their priorities should be.
Everyone wants to do bigger and more exciting things that spend their time patching bugs, so fixing bugs should be as fast and easy as possible. PlayerZero allows you to automate the part of fixing bugs where the most time is lost – getting the bug a user experienced in front of a developer who can fix it – in a way that makes the developer’s job easier. PlayerZero allows you to spend less time fixing each bug and focus on the particular bugs that users run into. This means less time spent losing users and more time building the things that really move the needle. See for yourself how PlayerZero can save you time and improve your workflow.