Processing the Results
The goal of processing this feedback is to classify each anchor (or common grouping of anchors) according to three key attributes:
Begin this process by transcribing the anchors into a spreadsheet or other system that you use to track product requirements. When there is more than one anchor around a common complaint, record the number of anchors that related to this complaint. Determine the root cause or area of the product associated with the problem. Here are some common root causes:
As you're processing the cards, be certain to include photos of the original cards written by your customers, because there is both meaning in the spatial arrangement of the cards and a certain empathy and intimacy that comes from working directly with your customers' feedback. In some cases you can even get a sense for the passion a customer has about a given topic by looking at the card they've created. I've seen cards with lightening bolts, frowns, "!#@&!#", phrases like "grrrr," or statements punctuated with several exclamation points. All of these are reflective of a customer who cares pretty deeply about the topic. Retaining this information is important to motivating your team to action.
Characterize the perceived severity of the problem. A common approach used in managing bugs associated with software systems is to assign each bug a numeric ranking from 1 to 5. Even if you're not working on a software system, you might find that this list provides you with a useful way of characterizing customer feedback.
Characterize the priority of fixing the problem, again using a numerical ranking from 1 to 5:
It is relatively easy to create consistency within your organization for severities, because they can be objectively verified. Priorities, on the other hand, are subjective. A misspelling in your documentation may get a "4" for severity, but different cultures will ascribe different priorities to fixing such a problem. I've found that Americans and Europeans are more tolerant and are happy to give these kinds of problems correspondingly low priorities. Japanese customers tend not to be as tolerant and give documentation bugs high priorities. Because of the subjective nature of bug priorities, use a cross-functional team approach to establish priorities. As you can guess, high severity problems correlate with high-priority fixes.
Even this level of analysis may be insufficient when making a good choice on how to handle a problem. Consider that sometimes trying to fix a Severity One problem (crash with no work-around) could cause other problems. This situation often happens in older software systems, and makes deciding what to fix extremely challenging.
Review the final results, organized by priority, to define how you will address each priority. It is especially important to communicate your choices to your customers so that they can understand how you're addressing their feedback.