Escalation that wasn't

Escalation that wasn't - is a false alarm. Raised by customer and escalated by friend’s next door (customer care) to top executives as business critical bulge. This falls as lighting on engineering, who then keep aside all planned activities to look into this. Although engineering maintains limited buffer for such unplanned activities, and most of the time ensures release on plan but lighting like this leaves certain impact that results in loss of productivity, compromise on quality or if nothing else then at least causes distractions from roadmap. And worst, engineering assessment of escalation is a known limitation or a known issue with version that customer is using, probably an workaround solution is already covered in release documents.

While engineering may struggle to find an answer to such situations, it is up to the Product Manager to minimize such distractions. The mystery of escalations that wasn’t is solved by ensuring proper programs on educating the users (end user, Tier x support, marketing, and customer care) on product usage. So how different it is from regular NPI process. Why and how could this objective be achieved?

Well, the training (as part of NPI or independent process) is largely held either during a product launch, or when a new deal is signed / renewed or on could be on customer request. Most of the times these trainings have contents like videos, audios, large documents etc which probably are never referred again or simply not good enough to highlight Do's and Don'ts or Is, Is Not of the product usage. Emphasis on trivial things gets lost in understanding the solution set.

Educating the users (periodically) has two very important advantages;

1. It reduces pain points for engineering
2. It improves the product image
   

Some of the ways to ensure proper product usage or educating the customer could be;

Insulate Installation:
Make software installation more robust. Let the installer be intelligent enough to check for exact pre-requisites, eg Service Packs, specific driver version etc. and conflicting application, if any.

Product tips on login:
Customer should be advised with tips as and when he/ she logs in to your application. Such tips are optional and can be turned-off by user. So you as a Product Manager need not to worry of customer complaining of annoyance.

Quick reference note / do's and don'ts:
They are available on end user machine and can be popped through your application on a single click. Whenever a user hits an issue / error situation, he gets a pop asking to refer specific section in help file or a release document.

Bench marking:
Eg. The software takes 60 secs to launch when connected to internet and 30 secs when your computer is not attached to a network. Such benchmarking helps setting the right expectation. These are important as they directly impact the user response behavior and product image. They also improve moment of truth for your product / service.

Escalation tools:
Ensure that you have clearly defined escalation path. Escalation is accepted only with some bare minimal information such as OS flavors, Service Packs, logs, registry information etc. Make your tools validate the escalation content first before it goes to top. For eg. Software ver 3.5 is certified only on Windows XP and Mac while software version 4.0 is certified on Windows XP, Vista and Mac. Now if an escalation is raised for 3.5 on Vista the tool manages on its own.

You as product owner can possible think of more and better options to manage such escalations. While whatever may the method be, Product Managers must always remember that your users (customers) can be your best salesman. Educate them and keep them informed on regular updates.