Building feedback loops: It’s the process, stupid

[A dramatization – well, sort of] In the not too distant past, I was sitting at a customer site on the other side of the country, waiting for a software vendor (whose application was integrated into my company’s software solution) to respond to a customer question about a piece of functionality that wasn’t working as documented. As I sat there waiting for the phone to ring, my mind wandered a bit, and I found myself daydreaming about creating some kind of technology that would allow me to reach through the telephone lines and smack the next person who tells me “Well, we can’t seem to recreate the problem over here. Can you tell me again what the problem is?”

I can’t tell you how many times I’ve heard that response. Well, the guy finally called, and his response was as expected – “Can you help us understand the problem? What is your user trying to do? We can’t recreate your problem, and we need more information.” After a red eye flight to the east coast, followed by 6 hours of user training and a poorly re-heated fast food lunchtime feast, I’m on the edge.

OK, let’s look at this logically – how can you tell me you can’t recreate the problem, and then in your next breath ask me to explain the problem? There seems to be an endless volley between product management and engineering and engagement personnel to clarify exactly what the customer wants and needs, and what the development team can deliver. I thought there was a “process” to handle the information being passed between organizations, and between our customers and pre-sales team. Apparently the “process” is send an email or jump on the phone.

Then comes the domino effect: The customer doesn’t think his input was adequately prioritized by the salesperson, so he contacts one or two other people at my company. The salesperson enters the request into the bug/enhancement tool, as does one of the other customer contacts. The QA team sees the new item, and flags the development team for an update. Meanwhile, the salesperson and one of the contacts have discussed the issue with a member of the product team, and the second contact has discussed the issue with a separate member of the product team.

Oh, did I mention that all three had a different understanding of what the problem was?

One of the product managers adds the issue to his next meeting agenda, while the second product manager goes straight down to engineering to talk about short-term solutions. Based on that conversation, engineering adds a small patch to the upcoming build schedule. Three days later, the salesperson logs into the bug/enhancement tool for an update. He doesn’t see an update, so he contacts someone on the QA team, who refers him to engineering, where he sees that a patch is being applied in the next build. He then contacts the customer to give him the great news. A week later the build is completed, two weeks after that QA approves the release, and the customer logs on to the new build – only to find that the problem he reported is still there.

Ouch.

OK, while I stand by my claim that the above account is largely a dramatization, this problem is all too real. Some of the finest, most well-organized teams have fallen into this communication trap. To overcome it, you need to automate.

Water follows the path of least resistance. In my experience, so do communications between customer-facing groups and product development teams. We all hate to admit it, but when it comes to solving complex software problems or responding to detailed customer functionality requests, development teams usually do what it takes to get the product out the door – even if it means bypassing specific customer requests and revisiting the same problems later. But keeping development on schedule and providing continual feedback to your customers should not be mutually exclusive.

Documentation is the key. The aspects of good documentation are simple: they must be clear, concise, consistent, and most importantly, they must deliver the expected results. This point deserves emphasis: it is one thing to create documentation that fulfills the technical requirements, but an entirely separate issue to create documentation that anticipates questions and provides solutions.

But who has time for clear and concise documentation? Everyone, if you have the right tools. Put the tools in front of the people, and make them as simple as possible (the tools, not the people). How do you get your globally dispersed sales team inputting customer bugs and requirements, you ask?

In my experience in building out and managing operations and project management teams, the goal is to make the entire process as transparent as possible, at every stage. For issue tracking / change management systems, the following model has worked for me:

• The customer contacts the appropriate customer representative with an issue or a suggestion.
• The customer rep documents the issue/suggestion, enters the information into the repository, and receives a tracking number. At any point, the rep can access the system and get a status on this item. Each time the issue is edited (feedback provided), they can receive an email notice.
• Bugs are sent to QA, while enhancements are sent to product management.
• The bugs/enhancements are reviewed (does the request make sense?), qualified (is this a valid request?), prioritized (where does it fit into our current activities?), and consolidated (do I have any similar requests already in the system?). The tracking tool (we use SharePoint) is then updated with the appropriate feedback.
• Based on the update, the appropriate development organization receives the request and fits it into their development schedule.
• The development organization works with QA to test any new code.
• Once approved, QA updates SharePoint.
• The customer rep is notified that the item has been closed.
• The rep contact the customer and notifies them of the closure.

Based on my experience, here’s the roadmap to success:

1. Train your customer-facing folks to properly capture the information.
   Make yourself the documentation evangelist for your team or company. Advocate capturing requirements via entire sentences versus chopped up fragments of what is loosely referred to as language. Persuade them to break each issue down into logical chunks, and to carefully capture the steps of the problem AND the expected results. If documenting an enhancement request, include detailed use cases that explain how the customer would use the new functionality.
2. Automate the mechanisms for entering information.
   I’ve used both homegrown solutions and internet freebies (Bugzilla), but I love the ease of use and flexibility of building this out in SharePoint. Implement your solution in a way that allows key personnel to easily access and share information. This should be a no-brainer – log in, define the appropriate component, prioritize your information, and then leave your data. The easier you make it, the likelier they are to use it.
3. Set up a process for deciphering this information.
   Once you have the information, what will you do with it? It’s one thing to set up a vehicle for capturing and documenting customer information, it’s another thing to get your product development team to respond – so that your sales team can provide timely feedback. Make your SharePoint tracking tool part of your daily/weekly/monthly process for reviewing bugs and enhancements. Assign responsibility to some lucky product manager, and keep the repository updated.
4. Assign to necessary technical leads.
   The product team has responded, and the appropriate technical lead – whether part of your internal engineering team or part of a third-party development organization – is automatically notified via alerts. Actually, this is a big incentive for y
   our product management team. They are acutely aware that the sooner they respond, the sooner the issue gets assigned to an engineer and moves off of their own plate. How’s that for motivation? Instead of the engineering team lead receiving email notification for every single problem that comes across the product team, the system can organize and delegate based on components – and even based on severity.
5. Update SharePoint at each step.
   At each step of the process, SharePoint should be updated, the customer advocate will have access to that information, and notifications will be sent automatically. This is the key to cleaning up this entire process. Instead of pushing report after report across the organization, simplify simplify simplify. One version of the truth.
6. Train customer-facing folks to log in and report back to customers.
   Every Tuesday morning, I know that I can log into the system and get the latest update on any issue or enhancement that was entered into the tool the previous week. How powerful is that?

No tool will ever solve every team’s problems, but you need to start somewhere – and SharePoint is a pretty flexible platform on which to build.