How I Can Use Speed Boat

Processing the Results

The goal of processing this feedback is to classify each anchor (or common grouping of anchors) according to three key attributes:

• The specific area of the product associated with the problem

• The severity of the problem

• The priority or urgency of fixing it

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:

• Poor documentation Incorrect, improper, misleading, outdated, incomprehensible, and so on.

• User inexperience Users didn't know that something could be done with your product.

• Defect An error or bug in your product. It is best if you explore this just enough to confirm that you understand the problem, so that you can correlate it with your defect-tracking system.

• Technology incompatibility A previously unknown or improperly communicated incompatibility with your product.

• Mismatched expectations For example, a customer expected the fountain pen to work while on a plane and expressed frustration when it didn't.

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.^[9] 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.

^[9] You should adapt this list to the ranking system used by your company.

1. Crash with no workaround. Often associated with unavoidable data loss, and typically considered the worst kind of bug. For nonsoftware-based products, this kind of problem could be considered equivalent to a serious safety issue that motivates a product recall. Using this as a baseline, you can adjust the rest of the rankings in a way that makes sense for your product.

2. Crash with workaround.

3. Serious problem.

4. Minor problem.

5. Not a bug (something the customer reported as a problem, but isn't).

Characterize the priority of fixing the problem, again using a numerical ranking from 1 to 5:

1. Immediate The problem must be fixed immediately, with the updated product delivered to customers as quickly as possible.

2. Urgent The problem must be fixed before the next major product milestone.

3. Before next release The problem must be fixed before the next version of the product is released to customers.

4. As time allows Although it would be nice to fix this problem before the next release, customers can live with the problem.

5. Defer We understand that at least one customer perceives this as a problem, but we're going to explicitly defer addressing the issue.

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.