What Is Product Support?
A traditional business regards product support as a service to provide the end-user with information relating the product, and help if the product should malfunction.
In the software industry, product support covers the above, but it also encompasses the team of developers, testers, BA's & project managers that get to work closely with Customer Support to fix bugs in operational software.
Why Is Product Support Disliked?
As a developer, where do you start? It's old code. It's constrained by time. It's constrained by technology. It has to be installed as an upgrade to an operational system, leaving all data and active sessions intact.
In short, it is hard to get right. But that's not the reason developers don't like it.
Product Support is seen as a less valuable activity than green or brown field software development. Therefore it's regarded as something the junior developers should be doing.
Developers LOVE to work on new stuff.
Completely new product. New features or capabilities.
Unconstrained by technology.
Unrestricted by the expectations of an existing user-base.
These are the reasons product support is often broken. They are also why product development is often broken.
Too little time is given over to how a product will be supported in the future.
How it will be installed. How it will be updated. The hardware it needs to operate. What the customers actually want the software to do and how they'd like it to do it.
What can we do about it?
There are so many things everyone on the development team can learn from a regular rotation onto product support. Some about technology. Some about the operation of software for a small or large user base. But the biggest thing I learnt when doing support was how customers are actually using the product.
Sounds obvious, doesn't it? The software was "designed" to do 'X' by following steps 'A', 'B', 'C', etc. But was it designed that way? Was it even designed? Did it simply end up that way as the original development team decided that was the way it would be?
Seeing and hearing the way people interact with your software can be a massive eye-opener to a developer. You quickly find out your intention for the way your product is used is often very different to a users'.
Seeing a user having to re-learn how to perform a task in your software after you've released a "patch" (that was really a redesign) is like getting a 'D' grade on an exam you thought you'd aced. So you quickly build a relationship with your customer and their needs.
But what about existing data?
Even automation scripts and integrations? When fixing bugs, you need to do so in a way that doesn't render any existing use of the software or data useless.
This is hard.
This is why support needs senior developers. To ensure existing use is not interrupted.
But the biggest thing a developer can learn (or re-learn) is that software is a tool to achieve other things, not an outcome in itself. The end use is the important thing. Not the technology. Not the internal structure. Not the elegance of the UI. If you break the end use experience, then your software is pretty much useless.
Submit your own review: