Those of us who’ve been around the product development world for a while know the stages of product development pretty much by heart. While some aspects of the process have changed over the years – think rapid prototyping – the core elements have stayed the same. From identifying a need to coming up with ideas, from specification through prototyping, from testing through refinement and onto release, there are certain steps that product development teams follow.
But as engineers, how much thought do we give to what comes afterward, once the products we’ve worked on are out in the market?
Sure, we get to respond to requests for tweaks and new features, and have to make fixes when we’re the recipient of unwelcome (but never all that surprising) bug reports. Or, in this day and age, a very public complaint about some failure or another that’s appeared on social media.
But how much thought does a typical engineer give to how they’re working with customer support – the crew that’s the first line of defense when issues arise?
The answer, if we’re being honest, is probably not all that much.
So it was good to see a reminder from Chris Coleman, writing recently on embedded.com, that addresses “how customer support and engineering teams can work better together.”
Coleman writes from the perspective of someone with considerable engineering experience in the embedded world, largely in the wearable space. He went on to found a company that has a platform focused on the “observability” of embedded IoT and edge devices, monitoring,
analyzing, and responding to crash data. So he has a foot in both the development and ongoing support worlds. And, naturally, since it’s what his company does, it’s no surprise that he argues for engineering to be proactive by monitoring devices, rather than waiting for often isolated, one-off bug reports/support tickets from customer support coming their way. Still, the argument he makes is pretty compelling.
He begins his piece by noting that, despite all the testing in the world, it’s just not possible to anticipate every last way that your product will be used, or all the “environmental conditions” it will meet up with. We see this with our SOMs all the time, as more and more customers from diverse industries, with new applications adopt them. Yes, you can set out the use cases and conditions that your product will support, but even within those boundaries, the unanticipated can happen. And it can be almost impossible to replicate exactly what happened leading up to a problem occurring.
Next, he outlines what customer support does to respond to problems. We all know the continuum here, from restart the device to send it back to have us take a look at it. And we all know that customer support works with tiers with respect to the criticality of an issue, and that they group problems in buckets.
These reports will then make their way to engineering teams. Being on the other side of receiving this information, it’s not super actionable. Often very different underlying problems manifest in the same way. It’s hard to know what exactly to fix and what changes will actually drive down the bulk of reports.
Over the years I’ve talked to so many support teams that see engineering as where bug reports go to die – very rarely do any resolutions come back. I’ve also seen many engineering leaders find the support requests inactionable – it’s very hard to go from a summary like “80% of issues are around connectivity” to actually fixing the problem.
Not much to say here, other than “ouch.” Or maybe been there, done that.
As I said earlier, Coleman is putting forward the case for adopting his company’s product. Nothing wrong with that. And nothing wrong with suggesting that engineering should work more closely with customer support. As an ISO 9001:2015 certified company, Critical Link has processes in place that ensure we close the feedback loop from customer support back to engineering. This helps our team to be vested in the entire product lifecycle, and ensures continuous improvement in our designs. From Coleman’s perspective, he advocates having embedded engineers begin to utilize practices that focus on tracking core vital signs with respect to device reliability. This will give engineering a better handle on problems, and provide support with a better, more informed means of communicating with customers. And no more tickets that never get closed out.
My main takeaway from reading this piece is that engineering and support can never operate independently of each other, and if there are approaches (and tools) that make products more supportable and customer support more capable of truly supporting their customers, I’m all for it. Consider these words to the wise.
Source of image: Buyer Foresight