Find the right level of engagement with your tech support.

     

Talk to a product manager about Tech support – and you will most certainly get a reaction. Sometimes – “a great source for product insight” – or “constant interruption on stupid topics”

Technical support will never leave a product manager speechless. Because for High Tech products, including sw services, there is often a need for tech support. Even if great care was taken to build the product for the right Persona and to focus on overall UX there will always be unpredicted situations during installation or use.

Frequency and involvement

In one company were I was heading up the PM team we organized tech support with a common email group. All support topics were sent to all PMs. Anyone in the team could pick up the topic and give a prompt answer.

People in sales etc were really happy with the fantastic support from product management – and the effort was reasonable. Requires quite some email discipline to work properly – PMs who were doing some (more important strategic) work would NOT pick up the issue – leaving it to a less booked colleague.

I would say that the key challenge for the product manager when it comes to tech support is to FIND THE RIGHT LEVEL OF ENGAGEMENT. If too high – you will do nothing but support ongoing business. If too small – you will miss out on the fantastic insight opportunities given!

Tech companies often organize support in levels:

  • Level 1: Help Desk
  • Level 2: Technical Maintenance
  • Level 3: Change Team (typically in or with Development)

In some companies product managers are asked to “listen-in” to tech support at least once per quarter. I think this Is a great policy and often gives very valuable information. Typically PMs are only involved in Level 3 issues however. Level 1-2 are handled by the Product Care team on their own.

Also, you would want to direct the product care team in how to prioritize between smaller and not so small support items. Even support should be orchestrated with the overall product strategy in mind.

For example, in a global industrial company selling both hw and sw all defects were categorized in 5 classes: A – F:

  • A:  Small, non-reoccurring
  • B:  Medium, non-reoccuring
  • C: Small, re-occurring
  • D: Medium, re-occuring
  • F:  Major

Product managers were informed on A-C and was opted to take personal action on D-F.

As an interim product manager I was responsible for a Telematics product. The company (had) decided to push all (100%) problem reports to the PM in charge. Maybe this was a good idea at the start – since I realized most problems had nothing to do with our product.

Instead it was the customer who had problems with their SIM-cards and cellular subscriptions. The Insight was  - maybe it would be a good thing to handle subscription issues by bundling a prepaid SIM-card with the product...

Bugs, comments  - or just any kind of feedback on product usage – is a great asset for insight creation. If handled in a good way this could indeed be the major source for ideas on incremental product enhancement.

 

About The Author

Erik has extensive experience in product management, business management and development. Within the software, electronics and hardware, Erik has pursued commercial success.