Draw a boat on a whiteboard or sheet of butcher paper. You’d like the boat to really move fast. Unfortunately, the boat has a few anchors holding it back. The boat is your system, and the features that your customers don’t like are its anchors.

Customers write what they don’t like on an index card and place it under the boat as an anchor. They can also estimate how much faster the boat would go if that anchor were cut and add that to the card. Estimates of speed are really estimates of pain. Customers can also annotate the anchors created by other customers, indicating agreement on substantial topics. When customers are finished posting their anchors, review each one, carefully confirming your understanding of what they want to see changed in the system. Click here to understand other characteristics of the game.

Although most customers have complaints, few customers are genuinely “against” you or your product. Even if they express extreme frustration, the reality is that they want to succeed when using your product (see the sidebar “Speed Boat for Expensive Products”). Giving them a way to express their frustration without letting a group mentality or a single person dominate the discussion is what most customers want. Speed Boat creates this relatively safe environment where customers can tell you what’s wrong.

Another significant reason that Speed Boat works is that many people don’t feel comfortable expressing their frustrations verbally. Giving them a chance to write things down gives them a way to provide feedback. It also gives them an opportunity to reflect on what is genuinely most important. The opportunity to reflect is especially important for those customers who just seem to be somewhat unhappy people (you know, the ones who complain a lot about the little details). Asking them to verbalize their issues, especially in writing, motivates them to think about these issues. Many of them will identify trivial issues as just that—trivial issues—and, in the process, focus on the truly big issues. Thus, they end up voicing their complaints, but they’re put into perspective. When they get used to thinking about their complaints, especially quantifying what the impact is, they are more reasonable and will contribute more to success—theirs and yours. However, there are products for which the sheer number of seemingly trivial complaints adds up to one truly large complaint—the product or service offering might have been good enough to purchase, but not good enough to continue using or to recommend to others. In this case, Speed Boat helps you identify the set of problems that you need to address before your product fails. Although we don’t require that customers use different sized or shaped anchors, the game does not prevent customers from changing the size, shape, weight, or number of anchors that they add to the boat.

Use the best possible imagery that you can to keep the mood playful. Buy pictures of boats and stickers of fish at stores that stock school or craft supplies and post them on a whiteboard. Print anchors on your index cards. Keeping the mood playful helps everyone deal with the potentially stressful content of the feedback. Aladdin Knowledge Systems, Inc., the world’s leading provider of hardware-based software antipiracy solutions, went so far as to merge a fast boat with a USB dongle to create vivid imagery that helped set the proper tone for their session (see Figure 2.23). You can also go “lo tech” for your boat, which the Greater Boston Chapter of the ACM did when they played Speed Boat. In this game, Tobias Mayer simply drew a speed boat on a chalk board (see Figure 2.24).

Steve Peacock of Air Transport IT described a variant of this game he played with customers at an annual users conference. Instead of using anchors, they referred to complaints as barnacles. Barnacles were of three sizes—small, medium, and large—where the size represented the strength of the complaint.

Although you want customers who can, and will, contribute, avoid including any customers who are likely to be overly dominant or negative. If you must invite such customers, consider running two Speed Boat sessions: one for the unruly crowd and another for the quieter, more thoughtful crowd.

It helps to review your service and support systems to identify any specific items that may exist for customers coming to the event, because they use this opportunity to ask pointed questions about the status of reported problems. It also helps to make certain you’re aware of any plans to address known problems. Although it is important to try to avoid addressing issues during the game, there are times that you will have to do this, so be prepared.

After the facilitator introduces the game, give customers a few minutes to gather their thoughts before you expect them to create anchors. Then, to help get the process of posting the anchors to the wall started, the facilitator should gently ask a few customers for completed anchor cards and tape these to the wall on behalf of the customer. After this is done, other customers will spontaneously join in and add anchors. There is no requirement that customers take turns posting anchors. In fact, the game works better if several customers and the facilitator are posting anchors at the same time because there is a formal review process.

See Figure 2.25: Posting Anchor Cards

When customers have finished posting anchors, the facilitator begins the review process (see Figure 2.26). Try to review every single anchor. This lets your customers know that their feedback is important. The approach that works best is to let customers finish adding anchors, and then ask them to be seated. Walk up to the anchors and review each one. Although only one customer created the anchor, invite the whole group to comment on what was written. As you review the anchor, it is critically important that you refrain from trying to solve the problem, respond to the feedback, or justify why a certain choice is made. Doing this will dramatically change the game dynamic. Instead of encouraging forthright and sincere discussions of perceived problems, customers will interpret your response as a defense mechanism and will quickly become guarded in their communication and cynical of the process. Seek to understand the underlying reason why this anchor is holding them back from success, not in responding to or justifying the status quo.

There are practical reasons why you should not attempt to address or respond to anchors during the game. You probably don’t have all the data needed to make a thorough response. You probably don’t have all the necessary decision makers in the same room. You are almost certainly violating your product development and product management practices by making decisions in this manner. Perhaps most seriously, you’re probably not in the right frame of mind to address these concerns, and you don’t want to let the stress you may feel during this game result in short-sighted decisions.

Note that reviewing every single anchor doesn’t necessarily mean reading or sharing each anchor. Sometimes it is better to quickly group anchors with similar content and/or themes and talk about these anchors as a group. This means that you need to continually scan the anchors that are being added during the game to see if there are obvious trends. In rare cases, you can move anchors that customers have added to start the process of group formation during the exercise.

The spatial arrangement of the anchors usually has important meanings to the participants. One example has already been mentioned—grouping similar cards. Sometimes customers will naturally put “heavier” or “larger” anchors near the bottom, or designate that there is more than one boat, where different boats have different meanings. To preserve the spatial memory of the exercise, take many photos during the game. Always take photos of the final card arrangement.

Consider asking customers to vote on the top three or five anchors whose removal would have the most positive impact on the boat’s speed.

One variant that can be useful is to ask customers to add “engines” to the boats after they’ve finished. The engines represent features that can “overpower” the anchors and enable the boat to move faster. Do this carefully, because it changes the focus and dynamics of the game. If you really think that you need to focus on adding features, consider Product Box, Buy a Feature, or Prune the Product Tree. Sometimes, however, the energy of the room changes and the participants naturally start talking about adding features. When this happens, go with the flow and add some horsepower to your boats.

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. 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.

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.

• Pictures of a speed boat

• Anchor cards

• 5"38" cards that customers can use as simulated anchors to capture their concerns

Few customers hope or expect that a product will fail. Instead, after a product has been purchased, customers will often work hard to ensure that the product succeeds. This is most easily observed in Business to Business (B2B) and Business to Professional (B2P) product and service offerings, where the commitment to success is proportional to the price of the product. Someone who just spent hundreds of thousands or millions of dollars on a product is facing considerable pressure to make certain that they made the right choice—pressure such as their next raise, promotion, or even their own job! These people tend to be great candidates for Speed Boat, providing direct, candid, and honest assessments of the anchors that are slowing down their use of your product. They want you to succeed. Let them show you how.

One of the hardest things about Speed Boat is not responding to customers during the game—especially when they write an anchor that is just wrong! This is where good facilitation skills are critical. In these situations the facilitator must keep the focus on understanding the issue presented by the customer. There will be plenty of time to address the customer after the event. And chances are you’ll want to communicate this to all of your customers because chances are good that more than one will share this misunderstanding.