Death by a thousand bugs
An ever-increasing volume of reported customer support issues is a good indicator of product growth, but is rarely welcomed with open arms.
It’s painful - there is no sugarcoating it. And it’s pretty much inevitable if you want to grow a successful product. You might get away with it for a while, but there’ll be a tipping point where it imposes itself on your teams in one way or another. It’ll sap time and eat away at morale. It’ll lead to others in your organisation questioning the quality of your work. Questioning what and how you’ve prioritised. What’s more, it’ll severely hamper the rate at which you can deliver impactful improvements, sowing scepticism and attracting scrutiny from those outside the team - particularly leadership.
This article explores how this manifests as a product grows, and what can be done to stem the tide or, better still, nip it in the bud.
The usual suspects
Customer support issues can bubble up from anywhere. In my experiences, it’s often a multi-pronged assault, but the usual actors are:
- A dedicated service desk
- Customer success / experience teams
- Other product teams
- Account managers (in B2B orgs)
It doesn’t help that support is often an after-thought. It's rare for an organisation to have much, if any, proper customer support elements in place before their product gains traction.
Tipping point
The earlier you begin to think about support, the better - as soon as your first few customer support issues roll in. Some indicators that it’s definitely time to get on top of this are:
- More than 20% of the work items your team work on are customer support issues
- There are multiple routes in to your team for customer support issues
- There are multiple regular meetings in which customer support issues are discussed
- Customer support issues are getting through to the team at a consistently higher rate than you can work through them
Coping mechanisms
The good news is that there are a whole lot of different levers you can pull to minimise friction and noise, and ensure that your product teams have continued traction with improving products, all the while keeping the quality bar high and shoring up customer trust.
🔦 Acknowledging support is a thing
The first thing to do is often to recognise that there is stuff to do, and this is impacting on team(s), the wider org, and of course customers.
This could be as simple as making reference to it in show and tells / weeknotes. It could be bringing it up in stakeholder conversations and 1-2-1s. It could be having a regular triage session in your team.
📝 A standard way to record issues
Having a template is a great starting point. There are a few basics that you need to have in place in order to understand how the supposed issue actually manifested, and then there are a few bits over and above that can help you triage and prioritise. Be wary of making any templates too rigid or over-elaborate though, as that can lead to the approach being circumvented, or avoiding it altogether.
Here’s my starter-for-ten anyway:
| Template item | Description | Example |
|---|---|---|
| Description | A plain text description that outlines what the actual problem is as simply as possible. | A customer called up to explain that when they clicked on the Next button on the third page of the application form, nothing happened. |
| Environment | The actual environment that the problem occurred in. If this is production, it's probably more serious than a problem that is only in the test environment. | Production |
| Steps to reproduce | A bulleted list of actions that can be followed to reproduce the issue. |
1. Go to the application form. 2. Progress through the first and second pages. 3. Select "UK" in the country drop-down. 4. Click "Next". |
| Expected outcome | What you expected to happen. Can be multiple things. | Customer progresses to the fourth page of the application process. |
| Actual outcome | What actually happened. Can also be multiple things. |
1. Unable to progress. 2. Jargon-laden error message displayed. |
| Screenshots / videos | The ideal is a video showing the issue occurring, but failing that screenshots can help bring this to life. | Imagine a video of an error message :) |
| Link / URL | If there is a link you can go to that will help you recreate the issue, include it here. | hyperact.co.uk/blog |
| Notes | Anything else that might help understand, diagnose, or fix the issue. | This seemed to work fine when we selected other countries, so it may be related to that. |
🎯 A central tracking system for issues
A “service desk” or “support” project in Jira is the most common approach I’ve seen. If you don’t use Jira or any other kind of formal work management tooling, this could be something as light as a shared Google Sheet.
The key here is that there is one single source of truth, everyone who needs it has access, and that it easily lends itself to integrating with how your teams visualise their work in progress.
It’s also good to be clear on how said integration works - do your teams spin up their own Jira tickets within their own boards and link them? Do they use the parent ticket, and the team boards are set up to pull in the parent ticket? You don’t necessarily need to be consistent across teams, but it definitely helps if your team is clear on the approach here.
🔝 A clear prioritisation mechanism
The best organisations here have a clearly defined framework for prioritising customer support issues. This does not need to be complex - in fact, the simpler the better.
HubSpot prescribes four different classifications based on the impact on customers. Twilio has three. Something as simple as this can really help bring a bit of focus.
Centralising this on a Confluence page or Miro board, and referencing it on your product team canvas will help.
⏳ A baseline service level agreement (SLA)
Setting yourself a goal of how quickly you want to turn around customer support issues can really help bring focus, and also acts as a yardstick to measure the health of your overall approach to support. If you’re regularly failing to triage and resolve customer support issues in a reasonable time, then you may need to do more.
If you have different classifications of customer support issues, it's not uncommon to have different SLAs per classification, so that critical issues are turned around more quickly, and less urgent issues don’t disrupt the flow of the team any more than is necessary.
🛣️ A single route in to the team to discuss support
You have an approach for tracking and prioritising customer support issues, but you still find issues working their way through to your team by various channels, as well as being peppered by updates on those that are outstanding.
Having a dedicated Teams or Slack channel for support-related comms can really help here. You can use this to push updates, and others in your org can ask questions in the open, fostering a standard, coordinated approach.
The only risk here is that it can be really helpful to keep comms about customer support issues on your central tracking system (e.g. on the associated Jira ticket), so some discipline is required to ensure that any pertinent comms that takes place in the channel is added to the tracking system where appropriate.
👥 One or more people accountable for support
This is a biggie for me. Potentially a game-changer. I saw this at one of Hyperact’s clients where a VP of Support joined and really upped the all-round game, bringing with him a calm authority, and helping to impose structure, discipline, and focus.
It doesn’t need to be such a senior appointment, but the reality is that those in customer experience and in product development have day jobs. Their priority is not a healthy, well-oiled support process. They can carry this to a point, but sooner or later you’ll need people whose primary priority is the support process itself.
🛠️ Arming your support specialists
The aim here is to shift the diagnosis and resolution of customer support issues as far left as possible, minimising the amount of issues that impact development teams.
Building up a knowledge base is a great place to start, even before you have dedicated owners of support. If nothing else:
- An overview of how your product works
- A list of “known issues”. These may be issues that simply won’t be resolved anytime soon and are not worth tracking, or those that have a standard approach to diagnose and/or resolve. Simple runbooks can help for the latter, that describe the steps taken.
Tooling is another area that can really help.
- Could you give better access to logging or audit data to help support specialists diagnose and potentially resolve issues?
- Could you give access to scripts that they could run to address other issues?
- Could you provide more life-like environments to help recreate issues?
📑 An agreed, documented workflow for issues
Another area where organisations fall down is not having a clear workflow for customer support issues. This is particularly important as an organisation scales and more parties are involved in the support process.
A great starting point is simply drawing up how support works on Miro or similar and talking it through. The output of this then becomes an artefact that those involved can rally around, and then later down the line you could formalise this using workflow management of Jira or whatever issue tracking tool you use.
I’d recommend not imposing an elaborate, strict workflow from the off as it can often be too limiting. Instead, let it develop informally and organically, and when everyone is comfortable with it and you’ve got an agreed flow drawn up, then consider aligning this to your issue tracking tool workflow.
🗺️ A coherent strategy on how support is tackled across the organisation
Acknowledging my bias given I very much view this from a product team perspective, the big question for me here is how much involvement do product teams need to have in support? I’ve worked in organisations where customer support issues hitting teams were the exception (one a sprint maybe), and other teams where more than half of the team’s focus was support. More granular questions may include:
- Should there be a product team dedicated to support?
- Can some of this be outsourced?
- Is there a broader policy of not addressing any support issues that are below a certain threshold of impact?
Answering these tough questions (even asking them is tough!) and being very clear on your overall approach can have a huge impact on how your steer your product through these increasingly choppy waters.
🔁 Regular reviews and iteration of support processes
Like we do with our products, our broader strategy, and our ways of working, frequent check-ins are essential to align, focus, and course-correct. This doesn’t need to be onerous - a monthly review of where you’re at and a lightweight prioritised board with your highest priority actions and owners is probably enough to get you started.
🔍 An increased focus on quality
Everything so far is much more focused on symptoms rather than root cause. Support issues are inevitable - there is no doubt about that - but equally, there is an awful lot you can do to minimise the volume and severity of those that trickle through by starting on the front foot. A few recommendations:
Clear product principles
Setting the quality bar from a user experience can really help. This may manifest as a broader principle around quality, but it can also be useful to set your stall out from the off in terms of lower level detail. No layout flicker. Standardised, informative error handling. Max page load times. The basics that you might take for granted in some products, but without this, these things can often manifest in support issues down the line.
Automated testing
To be fair, rigorous manual testing - including a well defined and reviewed approach to regression testing - can make a world of difference. But it often slips. And it's prone to error. Automating this is a logical next step, and for me is the gold standard all product teams should strive for.
Continuous integration and continuous delivery (CI/CD)
Baking your automated testing into your CI/CD process maximises the value your automated testing provides, shifting it earlier in your process and reducing the effort required to resolve issues as they’re found at the earliest possible point.
Collaborative software development
This could be a three amigos session at the end when an engineer thinks a user story is ready to be merged in. It could be a three amigos session before development starts in anger. It could be pairing or mobbing. It could be code reviews. Anything that helps to foster that shared understanding, and gets a few more pairs of eyes on new capabilities can really help here.
The Scout Rule
Put simply, leave a place better than you found it. If you spot quality issues whilst working in a certain area of your product or code base, try and address them where possible.
In summary
Navigating the challenges of escalating customer issues is pivotal for sustaining product growth and ensuring customer satisfaction. Implementing a structured approach for managing support, from early detection through to effective resolution mechanisms, is crucial. Establishing clear communication channels, prioritising issues based on impact, and investing in a knowledgeable support team are key strategies. This holistic approach not only alleviates the strain on development teams but also strengthens trust with customers, underscoring the importance of a well-orchestrated support system in driving continuous product improvement and success.
