Rephrasing Insights in the Customer's Voice

Raw insights from discovery interviews are typically written from the observer's perspective — "customers struggle to assess product quality before purchase," "users report confusion about the pricing structure," "support tickets cluster around the return process." These statements are analytically useful but emotionally distant. They describe the customer from outside.

The discipline of rephrasing insights in the customer's first person changes something important about how teams relate to the map.

What First-Person Rephrasing Does

Writing an insight in the customer's voice — "I can't tell whether this product will perform in the conditions I'll use it in" instead of "customers have difficulty assessing product performance" — does several things simultaneously.

It makes the pain specific. The first-person version contains the customer's actual concern (performance in real conditions) rather than a generalized category (difficulty assessing products). Specificity is what separates insights that drive design decisions from insights that generate nods of acknowledgment and no action.

It creates empathy in alignment workshops. When a room of product managers, engineers, and marketers reads "I can't tell whether this product will perform in the conditions I'll use it in," they are briefly inhabiting the customer's perspective. That inhabitation — however brief — changes the quality of the decisions they make. It is harder to dismiss or deprioritize a pain when it is expressed in a human voice.

It tests the insight's validity. Some observations that seem like customer insights do not survive the first-person translation. "The return process is inefficient" rephrased as "I..." requires the designer to specify what the customer is actually experiencing. The struggle to complete the sentence often reveals that the observation is organizational rather than experiential — that the "insight" is really about the organization's process, not about what the customer goes through.

"Every customer insight should be rewritten in first person: 'I feel frustrated restarting the process.' 'I don't understand the pricing.' 'It takes too long to get support.'"

Handling Internal Insights

Not all insights on a journey map come from customers. Many come from internal discovery — from colleagues describing pressures, organizational constraints, and team-level frustrations. These insights belong on the map too, but they should not be expressed in the customer's first person.

A simple convention resolves this: tag internal insights with a hashtag indicating their origin. #Pressure: We have no visibility on what customers do after onboarding is clearly an organizational constraint, not a customer experience. The hashtag keeps the insight on the map while preventing it from being confused with a customer voice.

This clarity matters in alignment workshops. When participants are reading the map, they need to know immediately whether an insight represents what a customer experiences or what an internal team observes. The first requires customer-centered design responses. The second requires organizational change responses. Mixing them produces confusion about who is responsible for addressing what.

The Test for a Good First-Person Insight

A well-rephrased first-person insight should pass three tests.

Could a real customer have said this? The language should sound like a person speaking, not like an analyst summarizing. "I find the product comparison experience cognitively demanding" does not pass this test. "I can't figure out which product is right for me without reading a lot of technical detail I don't understand" does.

Is it specific enough to design from? A team presented with this insight should be able to sketch a range of responses — better product descriptions, a comparison tool, a guided quiz, a community review format. If the insight is so vague that any solution would technically address it, it needs more specificity.

Is it clearly separate from a solution? If the insight already implies its own solution — "I need a better way to compare products" — it has slipped back into solution language. The customer's voice should articulate the experience of the problem, not the preferred response to it.