Voice of the customer and customer journey maps are two powerful tools to help keep businesses on track to deliver on customer needs at every point in their journey. But too often these tools are hobbled by incomplete data, outdated assumptions and contradictory information. What can businesses do to avoid this trap?

A combined approach of measurement and participatory design can restore the vibrancy and relevancy of VoC and customer journey mapping programs and keep the focus where it needs to be: on delivering and surpassing the customer needs.

What Is Voice of the Customer?

“Voice of customer” (VoC) has become an all-purpose term to describe market research techniques that identify, structure and prioritize customer needs. Typically, VoC data is gathered via the structured activities of researchers. Examples of these structured activities include focus groups, contextual inquiry and ethnographic studies. A classic example of a resultant VoC metric is net promoter score (NPS).

What you may not know: VoC initially achieved notoriety in 1966 as part of quality function deployment (QFD), a method originating in Japan for deriving engineering characteristics of a product directly from the stated needs of the customer. QFD focused on the importance of the VoC data and insights flowing through and influencing product development in a holistic and continuous way — through R&D, design, engineering, manufacturing, testing, support, compliance and beyond. We’ll see how valuable that approach can be below. For now, though, this historical context should naturally lead us to question practices and anti-patterns such as: 

  • Focusing data gathering only on early phases of product development.
  • Discarding or downplaying VoC concerns upon entering stressful, deadline-driven “just build it” phases.
  • Keeping VoC data and insights within product management and design, instead of sharing them across all specialties involved in delivering the final product (technical “build” specialties, quality assurance, sales, etc.).

Related Article: Transforming Listening Into Action: Fortifying Voice of Customer Programs

What Are Customer Journeys and Customer Journey Maps?

A customer journey is the path a customer takes when using your products and services to achieve a goal. It’s a story of how a persona goes from the realization of a need to the satisfaction of that need. A customer journey may range from high level — a person hearing of your company for the first time through to a long-term relationship — to low level — purchasing a single item from your ecommerce platform.  

A customer journey map is a visual tool to help represent, analyze and build shared understanding around a specific customer journey. Like most visualization tools, a customer journey map allows for participation, by allowing anyone the ability to step into the customer’s shoes, empathize with her, walk through a scenario, and identify ways you could provide her with a better experience. As a tool of customer empathy, a good customer journey map will go beyond the customer’s mechanical actions into her thoughts and emotional experiences.

Many different templates are used for customer journey mapping, but most of them provide areas to express the context (who, what, expectations), the journey (actual experience expressed in a sequence of key touchpoints), and insights (expectation vs. experience gap, improvement ideas).  

Here is an example template from Heart of the Customer, with a visualization that focuses on the emotions experienced:

example of a customer journey map, ranging from negative to positive experiences
Heart of the Customer

Here is a nice concrete example for visitors to Smithsonian Museums:

customer journey map for smithsonian museum goers
Customer Bliss

A common anti-pattern seen with artifacts that are built via effort and expertise, including customer journey maps, is that once they are built they tend to remain static – even in the face of contradictory information and observations. How can businesses avoid this trap?

Related Article: Customer Journey Mapping: Navigating a Course to Better Customer Relations

Using Metrics and Data with VoC and Customer Journeys

Note that VoC insights and customer journey maps are abstracted and built from current understanding. They oftentimes represent hypotheses and assumptions derived from limited sets of data. Eliminating bad assumptions and falsifying hypotheses are natural next steps to make these artifacts more valuable and actionable. Measuring specific outcomes and results along a customer’s journey is what allows us to do that.

Learning Opportunities

Many popular product development metrics frameworks place individual measures into a common flow — you might say a journey — that a customer goes through.  Dave McClure coined an acronym and catchy title for his framework which follows a general flow: he calls it Pirate Metrics, because what does a pirate say? AARRR!  AARRR stands for Acquisition, Activation, Retention, Referral and Revenue. 

Pirate Metrics are a great place to start for general customer acquisition and purchase behavior. Remember, Pirate Metrics are a framework for individual measures —e.g., under the “Referral” category you might be measuring NPS and Viral Coefficient (average number of referrals your customers make to you).

While I am clearly advocating for the use of data and measures here, a caveat worth mentioning, especially because of the empathetic and emotional nature of VoC and customer journeys, is this should not be confused with devaluing or ignoring aspects which are difficult or impossible to measure. As sociologist William Bruce Cameron said, “not everything that can be counted counts, and not everything that counts can be counted.” Similarly, UX and CX experts have done an excellent job at helping technical people understand that qualitative, not just quantitative, data is valuable and actionable. 

The bottom line is this: not every touchpoint, response, emotion or idea represented in VoC or a customer journey map needs to be tied to a metric, KPI, OKR, etc.

An important outcome when using metrics together with VoC data and customer journey maps is the refinement of those artifacts when real-world data contradicts them. Data can replace speculative hypotheses with “the real story.”  

So what team behaviors and approaches encourage this?

Related Article: Pinpointing the Magic CX Metric That Drives Growth

The Secret to Effectively Steering Product Design and Delivery with VoC and Customer Journeys

There is a mindset in some design circles which might be termed Participatory Design, or “Design as a Team Sport.” This approach has been championed by the likes of Jeff Gothelf, Josh Seiden, Jared Spool and Scrum.org. The mindset takes the cross-functional team ideals of Agile, and extends the functional footprint beyond just build, test, architecture, technical writing, etc. to include design and designers (UX, CX, research specialists, etc.). This approach does not devalue specialization or expertise, but aims to explicitly and effectively put that expertise into a context it already needs to work within regardless: that of a product development function which goes beyond just design. (Note how this is similar to the ideals of QFD mentioned earlier.)

This style of design works by subtly shifting people with expertise away from doing everything and answering every question as it relates to design, and towards the roles of visionary, facilitator and consensus builder. But how does this relate to effective use of VoC and customer journey maps?

Three important things happen when working in a truly cross-functional team that result in better artifacts, and more importantly, better results:

  1. True Teamwork — Everyone working on the product is not only on the same team, they’re doing the same work – i.e., sifting and winnowing through ambiguous ideas, contexts, markets and requests to deliver a concrete product that makes customers happy. Arranging yourselves as a cross-functional team makes this explicit, encourages collaboration, and fosters shared accountability (as opposed to a “throw it over the wall” mentality). This is effective both in terms of team dynamics and day-to-day work. Could developers help designers understand different ways to gather usage data that relates to a customer journey metric? Do developers need to know something about the emotions experienced by a particular persona as she uses a product? Yes and yes.  
  2. Artifacts Are Co-Owned and Malleable — When artifacts are built by a group through effective facilitation, there is shared ownership. An architectural diagram is no longer “Archie the Architect’s problem,” and you no longer hear things like, “I’m not authorized to change that.” This is good for the integrity of the artifact, because assumptions can be observed to be incorrect and hypotheses can be falsified by anyone, with information coming from any source — they are not solely the domain of experts.  
  3. Shared Understanding = Cohesive Product — The co-ownership of artifacts is also good for the designer’s desire to actually influence what gets built. I have seen designers struggle with influence and compliance to their ideals in the same way I’ve seen architects struggle. Handoffs of artifacts that are “written in stone,” where the receiver has no knowledge of the whys, constraints, or trade-offs that went into the ideals and decisions represented in the artifact, never work.  They inevitably result in a lack of ownership and influence on the receiver, and therefore frustration on the part of the giver, and lack of cohesion in the resultant work product. The solution is to involve people in the context building and decision making, and to move away from a command/control, handoff-driven stance to a more collaborative, participatory stance invested in shared understanding and shared ownership. This is how a team delivers a cohesive product, one which fulfills the product vision, fits within multi-dimensional constraints (architecture, design, compliance), and truly makes customers happy.

fa-solid fa-hand-paper Learn how you can join our contributor community.