Prioritization Games - Speed Boat
In Brief
Speed Boat is an Innovation Game developed by Luke Hohmann where participants surface and prioritize their pain points by hanging “anchors” below the waterline of an imagined boat. A boat is drawn on a whiteboard or shared digital canvas, and participants write each frustration, complaint, or obstacle on a sticky note and place it as an anchor at a depth that represents how badly it slows the boat down. Hohmann’s framing is direct: “The boat is your system, and the features that your customers don’t like are its anchors.” The deeper the anchor, the more debilitating the pain. Participants can also estimate how much faster the boat would go if a given anchor were cut — and as Hohmann notes, “estimates of speed are really estimates of pain.”
The metaphor lowers the social cost of negative feedback. Instead of directly criticizing a product or team, participants are adding anchors to a boat, which shifts the conversation from blame to mapping.
Common Use Case
You have an existing product and a small group of target customers you can convene for about an hour. You suspect customers are sitting on frustrations they have not voiced through support tickets, surveys, or interviews — and you need to know which of those frustrations are debilitating enough to justify product investment before any new feature work. The output is a depth-ranked map of customer pain points, with relative severity, clusters of shared pain, and the customer language describing each one.
Helps Answer
- What are the biggest pain points in our current product or service?
- Which frustrations are most debilitating to customers?
- Are there pain points shared across customers, or are issues segmented?
- What is slowing adoption or retention?
- What should we fix before adding new features?
Description
Speed Boat works by combining two mechanisms: a metaphor that makes negative feedback feel safe, and a spatial layout that forces participants to weigh the relative severity of their complaints. In most feedback channels — surveys, support tickets, interviews — customers report issues one at a time, without comparing their relative impact. Speed Boat forces that comparison. When a participant places an anchor at a medium depth but then sees another participant place a different issue deeper, they must decide: is my issue really less important, or should I move it? That negotiation produces a more honest and calibrated picture of customer frustration than any individual feedback channel.
Hohmann lists Speed Boat alongside eleven other games in Innovation Games: Creating Breakthrough Products Through Collaborative Play (Addison-Wesley, 2006). The boat metaphor has since spread beyond customer research into team retrospectives, where it is usually called Sailboat. As the retrospective community documents the lineage: “The idea started from Luke Hohmann, and over the years has been modified a few times by many in the community.” Speed Boat as covered on this page stays in its original lane — pain-point research with customers — and is not a team retrospective.
Speed Boat surfaces pain points, not features. It pairs naturally with the rest of the prioritization games family: once you know which anchors are deepest, Buy a Feature and Card Sorting tell you which features customers would actually fund to remove them.
For a more complete picture, you can optionally add wind or engines above the waterline to represent positive drivers — features and experiences that propel the product forward. The balanced view prevents the exercise from becoming purely negative and highlights strengths worth protecting. If your primary goal is to surface pain points, keep the focus on anchors and save the positive framing for a separate exercise.
How to
Prep
1. Recruit the customer group.
Recruit from the segment whose pain you are actually trying to map. Mixing segments produces noise — different segments hit different anchors, and you will not be able to tell whether a recurring pain reflects a real shared issue or one dominant participant. If you have access to more customers than one small group can hold, run multiple sessions in parallel rather than one large one.
2. Gather the materials.
You need a whiteboard or large sheet of paper (or a Miro/FigJam board for remote sessions), a stack of sticky notes or index cards, markers for every participant, and tape if you are working on paper. For digital sessions, prepare a Speed Boat template with the boat drawn, the waterline, and a chain hanging below.
3. Draw the boat and the waterline.
On the whiteboard, draw a simple boat sitting on the water. Draw a clear horizontal waterline. Below the waterline, draw an anchor chain hanging down with empty hooks or pegs at varying depths. Label the area below the waterline “anchors.” If you plan to run the optional engines/wind variant, also label the area above the waterline “engines” or “wind.” Keep the drawing simple — a child’s-book sailboat is enough; the diagram is a placeholder for sticky notes, not the artifact.
4. Decide on the framing you will use.
You will introduce the exercise with one short metaphor speech. Hohmann’s site frames it directly: the boat is your system, and the features that customers don’t like are its anchors. Write your version of that speech down so the facilitator delivers it the same way each session.
Execution
1. Open with the metaphor, not a feature list.
Read the framing speech you drafted in Prep. Keep it short. The boat is the product or service, the anchors are the things slowing it down, and deeper anchors are more debilitating. Do not list specific pain points the team has already discussed; the goal is to learn what participants want to surface, not to validate your existing list.
2. Time-box silent anchor writing.
Hand each participant sticky notes and a marker. Ask them to write one pain point per note — a brief phrase or sentence — and to write as many as they can think of. Time-box this to a few minutes of silent writing before any anchors are placed. Silent writing first is the single most effective protection against groupthink: once a participant sees others’ anchors on the board, recall narrows toward what is already there.
3. Place the anchors with depth as severity.
One at a time, each participant reads their anchor aloud, explains it briefly, and places it below the waterline. Deeper placement means more debilitating. Encourage participants to place their anchors relative to others already on the board — if the new anchor is more painful than the current deepest one, it goes deeper; if less painful, it goes higher. The act of comparing and placing is where the calibration happens.
Optionally, ask participants to estimate how much faster the boat would go if a given anchor were cut — a percentage, a multiplier, or a qualitative phrase — and write that estimate on the card. Hohmann’s framing of these estimates: “estimates of speed are really estimates of pain.”
4. Observe; do not validate.
The facilitator’s job during placement is to observe and take notes, not to react. Do not validate or explain anchors. Do not push back on placements. Do not explain features that are mentioned. If a participant asks whether something “counts” as an anchor, the answer is: if it slows you down, place it. Take notes on who places first, who hesitates, what arguments come up about depth, and what gets clustered together.
5. Optional: add engines or wind.
If you decided in Prep to include the positive variant, repeat the process above the waterline once anchors are placed. Ask: “What is propelling this boat forward? What do you love?” The same silent-writing-then-placement sequence applies. Keep the time-box tight — engines are a balance, not the focus.
6. Photograph and document.
Take a photo of the final board. Transcribe every anchor with its relative depth, any speed estimate written on the card, and which participant placed it. Record key quotes from the discussion. The board is the artifact, but the verbal context is where the explanation lives.
Analysis
The spatial layout provides immediate visual prioritization. Read the board across several dimensions:
- Deep anchors represent the most debilitating issues. These are the candidates for urgent attention and the strongest signal that a fix would meaningfully change the customer’s experience.
- Clusters of anchors at any depth indicate widely shared pain points. Even moderate-depth anchors that appear on multiple participants’ notes may warrant priority — convergence across participants matters.
- Isolated deep anchors may represent severe issues for a specific segment rather than the whole customer base. Note the participant and explore in follow-up whether they represent a high-value segment with shared but unspoken pain.
- Speed estimates (if collected) work as a pain proxy, not an engineering estimate. A “10x faster” anchor next to a “10% faster” anchor tells you which one customers feel is debilitating versus annoying, regardless of how much engineering each fix actually requires.
- Coalition patterns. Pay attention to which anchors several participants nodded along with, asked about, or moved deeper after a peer placed theirs. Anchors that triggered visible recognition across the room are the ones likely to convert into product investment.
- The gap between anchors and engines (if used) shows the overall balance of frustration versus satisfaction. A board heavy on anchors with few engines suggests a product at risk of churn.
- Groupthink Once the first few anchors are placed, later participants may cluster around similar themes and miss their own original pains. Mitigate by having every participant write their anchors silently before any are placed on the board.
- Depth calibration Different participants use depth differently. Some place everything deep; others stay conservative. The relative positioning within each participant’s set matters more than absolute depth across participants. Note who tends to go deep and weight accordingly.
- Recency bias Participants tend to report frustrations from their most recent experiences. Ask explicitly: “Beyond what happened this week, what has been frustrating you for months?”
- Dominant participants A confident or senior participant can set the tone for what counts as a “real” anchor and how deep is acceptable. Silent writing first protects against this; in placement, watch for participants who soften or move their anchors after a dominant peer speaks.
- Negativity spiral The exercise is designed to surface complaints, which can create a negative tone. If the room becomes overly frustrated, pivot to the engines exercise or end with a forward-looking question: “If we fixed the deepest anchor, what would change for you?”
- Facilitator validation Nodding, agreeing, or restating an anchor in better language signals which pains the team already cares about, and participants will tilt toward those. Take notes silently and resist the urge to coach.
Learn more
Case Studies
Qualcomm (OmniTRACS / DataVisor)
In a 2003 engagement, Luke Hohmann facilitated Speedboat (and Product Box) workshops with Qualcomm’s trucking-fleet customers to surface their pain points around interpreting and managing the flood of telematics data coming off SensorTRACS / OmniTRACS. The customer pain that surfaced — large amounts of data that were difficult to interpret, manage, and use effectively — drove the requirements for Qualcomm’s DataVisor business-intelligence platform, which Qualcomm publicly launched in 2006. Hohmann recounts the engagement first-person on LinkedIn. (corroborating product launch: Commercial Carrier Journal, 2006)
Further reading
- Hohmann, Luke. Innovation Games: Creating Breakthrough Products Through Collaborative Play. Addison-Wesley, 2006. The primary source for Speed Boat, including the boat-and-anchors metaphor and the use of anchor depth as a measure of pain. One of Hohmann’s twelve Innovation Games.
- Speed Boat — Luke Hohmann
- Innovation Games (2006) — Luke Hohmann
- Sailboat — Retrospective Wiki
- Innovation game — Wikipedia
Got something to add? Share with the community.