Prioritizing product supportability
Taking a look under the hood
Especially in a startup environment, Engineering and Product focus is on doing more: more features, more customers, more scalability of the system. But in this race to expand and cover more use cases, to get more customers, usability and supportability often take a back seat.
Supportability is a straightforward concept: how difficult is it, how much effort does it take, to successfully support all of the customers using this product? This ties directly into support load, because the less supportable the product, the more load your Support team will be under as it handles the day-to-day issues of your hopefully growing customer base.
There are two main branches of supportability to think about, of equal importance:
- Making it easy for Support to solve problems: you might think this would go without saying, but your priorities aren’t everyone’s priorities. Especially in the early days, a single support engineer or a small team can handle all of the support issues that a tiny customer base can generate. It’s only further down the road when the pain becomes more apparent, and the choice becomes more stark: improve the product to help out Support, or add more bodies to the support team.
- Helping the customer solve problems without involving Support: the best support issue, to mangle a saying, is one that never happens. Many customers, especially the more technical of them, are perfectly able to conduct their own troubleshooting and investigation when things go wrong. But if they’re not able to gather all the information they need to understand what’s happening, they’re going to have to reach out to you. If you can help them help themselves, you’ll be taking a lot of load off your own shoulders.
Aside from those two, overall product quality and stability is obviously very important as well—it’s a lot harder to support a product that’s crashing all the time, after all—but frankly, if Engineering isn’t given the resources it needs to build to a stable product, your organization has issues that you as a support leader are not equipped to resolve on your own.
Logging improvements
The first set of improvements I always suggest, because they’re almost always necessary, is around logging. When building a new piece of software, logging is much like documentation: often an afterthought, and usually built only far enough at the outset to be barely adequate. Until there is outside pressure to improve, product logs often languish unchanged. “Make logs better” is a broad and vague topic, but in my experience there are three major, and urgent, improvements to be tackled in most software products. From the most to least important, they are:
- Complete logs: if nothing else, make sure your product is logging everything relevant. If full logs are prohibitively large, implement logging levels so more detailed logging can be enabled, and disabled, when an issue arises. There is nothing more frustrating than experiencing a product error and finding a generic error message, or nothing at all, in the logs. You should be able to reconstruct where exactly an error occurred, and why, just by looking at the logs that your product generated.
- Readable logs: it’s not enough to log everything if you can’t understand what you’re logging. Vague messages, meaningless error codes (not documented anywhere), and illogical logging sequences can make it difficult or impossible to understand what’s going on without involving the engineer who wrote the code in the first place, and if they’re gone, you’re out of luck. Log messages should be readable and largely comprehensible to a reasonably well-informed novice.
- Easily collected logs: the greatest logs in the world are useless to you if you can’t get to them. There needs to be a mechanism to a) collect the logs you need, and b) collect only the logs you need. When you can’t collect logs yourself, there needs to be some way for the customer to easily gather and pass along the logs to you, ideally via a simple GUI process or command-line tool. If you have direct access to customer logs, as is common in many SaaS products, you should have an easy way to pull out relevant logs without having to sift through gigabytes or terabytes of extraneous logs from other customers or irrelevant timeframes.
Improving logs addresses both branches of supportability: if customers can read and understand what’s happening on their system via looking at the logs they have access to, then they may be able to troubleshoot and address it themselves, or at least get a more informed view of what’s going on. And on the support side, comprehensive and readable logs can be goldmines for understanding what’s going on under the hood of a very complex system.
Product usability improvements
This is a more nebulous category of improvements, because it’s not always clear a priori what needs to be done to make a product more usable. Instead, it’s a multidisciplinary approach: Support can determine what’s causing customers problems, and raise it to the Product and Design teams. And Product Design can work on user experience (UX) improvements, both with and without customer feedback, to make the product more clear and usable from an interface perspective.
The best way for Support to gather these usability pain points is through regular ticket review and categorization, finding durable trends over time. Are customers regularly confused about one section of the network settings? Are you getting regular support issues because admins are accidentally deleting resources? These are issues Support must raise to Product, along with statistics (“10% of the issues we handled this month are related to this specific product feature”) , to advocate for improvements. (More on this topic below.) Usability improvements make customers happier, but also help prevent support issues from being generated in the first place.
Diagnostics observability for customers
After logging improvements, perhaps the single most effective way of improving supportability is by making product-related diagnostics and error messages more visible to customers. Usable errors in the UI, human-readable diagnostics with relevant links to documentation, and visible measures of system and endpoint health all contribute to helping end-users and customer product administrators to understand where things are breaking and point them in the right direction to getting the product working again.
This third category is interesting because in certain lights it resembles log improvements, and from another perspective it could be grouped under usability improvements. But however you categorize it, improvements in customer-visible diagnostics are immensely helpful in allowing customers to self-diagnose and perhaps even resolve their own issues, which in turn reduces the overall load on Support.
At a minimum, this kind of diagnostic observability is simply surfacing errors to a place where the customer can see them, rather than leaving them in logs the customer may not even know exists. Perhaps the web UI will have a red banner across the top of the screen, or perhaps when the local admin goes to a user management page they will see a very prominent error icon next to users that have recently been having issues. Whatever the implementation, bringing errors to the attention of the customer rather than making them go search for those errors can go a log way towards helping the customer notice issues sooner and get a jump on fixing them without the help of Support.
Getting these improvements on the roadmap
I touched on this above, but identifying supportability improvements is only half the job: you also need to get them done. This can be difficult in the best of circumstances, but in a startup environment where the pressure is high to add features and expand the customer base, it can be nearly impossible. Here are a few ways to help convince Product that these changes need to go on the product roadmap and get built.
- Come with specific examples. “We could have saved six hours parsing logs and asking Engineering about this particular error message if our logs were more clear” is a compelling story. “My team tells me our logs could be better” is not. Put in the work and point to specific places where the lack of supportability in the product has hampered your support efforts, or damaged the overall customer experience.
- Start with low-hanging fruit. When it comes to adjusting Engineering efforts, it’s easier to fit in a two-hour task than a multi-week effort. Speaking of which…
- Consult with Engineering for the level of effort. Figure out how difficult it actually will be to make the changes you think are necessary. Your intuitions may not be correct—some things that seem simple are actually a lot more involved, and vice versa.
- Enlist Customer Success (CS). With their ongoing customer relationships, CS know all there is to know about the things hampering product adoption and use, including poor supportability. They’re also better placed than Support to put actual dollar values on this lack of adoption, which can have a marvelously clarifying effect on product development decisions.
- Stark choice: improve the product or hire more Support staff. If all else fails, this can be a compelling argument, but only if you get executive buy-in. Convince the CEO that it’s cheaper to spend a few days improving logging than to hire additional support engineers, and your job is done. But if you can’t point to hard figures (e.g. ‘It will cost $X in engineering effort to save $Y in salary’), it will be harder to make this argument. Be prepared!
Though they can be hard to prioritize, product supportability improvements will pay back multifold in easier troubleshooting and in helping lower overall Support load. Pay attention to where your Support team is having trouble, and where your customers are experiencing friction, and you’ll be well on your way to figuring out what improvements you need to be advocating for in your next meeting with the Product organization.
Thanks for reading Andy's Support Notes 💻💥📝!