JoshSweeney

Send People On Site

Understanding customers and their needs can sometimes be a complicated process. Most software companies today seem to develop and deploy in a bubble only taking customer requests through a narrow channel of managers, product managers, and sales. This channel is in place to help keep focus in the R&D department but can lead to drastic problems on site with customers.

The standard in a majority of software companies is that only certain people deal with the customers. As I stated before, the positions with this “privilege” are sales, management, product managers, and support.  The problem that companies run into with this structure is that the people developing and testing the software never get a good understanding of the headaches that their software causes. They are so shielded by the internal information channel that even if the software is considerably hard to support, use, or customize, they may never get a full understanding on just how bad it is.

This is the case in many places except with the Mercury/HP group. Once SPI Dynamics was bought by HP I was able to get a front row seat on the impact that going on site would have. The Mercury/HP group was extremely adamant about sending engineers on site to fully and thoroughly understand customer issues. I have to say that this was one of the best and most logical ideas I had witnessed in a long time.

Sending developers and QA engineers on site proved to be one of the best learning experiences that one could get. The developers quickly gain an understanding of why customers are having trouble with a piece of software. The QA engineers are able to understand first hand how each customer is using the software which enables them to create more “real life” testing scenarios.

With today’s economic climate not every company can really afford to send developers and engineers on site. Although face to face communication and working on site with a customer allows for the best customer experience there are many alternatives.

The first is a forum. I don’t mean your standard community forum where the company politely asks if everyone can monitor the forum as they get time. Most of the time this does not work and many posts go unanswered leaving a bad experience for large groups of users. What I suggest is holding people accountable. Make it mandatory that each developer/engineer monitor the forum for a certain period of time and assist users in order to better understand their pain points. With this monitoring there should be metrics such as how many people they helped, how many problems were solved, and what problems are reoccurring.

Another alternative is web meetings. A web meeting where users and engineers can remotely share monitors and speak on the phone is a low cost solution that opens the lines of communication.

Lastly is to give them the time to sit with support and help them solve issues. Support is the main channel in which software issues come in, especially when no forum is available. Allowing this time will give developers/engineers first hand knowledge of the frustrations that not only customers run into but also the frustrations of support engineers.

The overall theme is to not shelter the people who have the most impact on the software. Help them understand the problem that customers run into so that they can have more of an understanding of their pain. Many times it is easy to sit back and dismiss software issues when your in the bubble. Working with someone directly who is having a problem helps both parties create an understanding and be more willing to help each other over time. In addition, multiple departments working together promotes cross training and understanding.

Tags: forums, on site, support, web meeting