Share this content
Journey map

Why customer journey research has gone awry - and what to do instead


Mapping end-to-end customer journeys is increasingly utilised to help understand customer needs and deliver products that resonate. But could the way that these customer journeys are researched be causing more harm than good?

18th Oct 2018
Share this content

I often meet with potential clients who are struggling to design and build successful software products. The root cause of their struggle can be a combination of different factors: from bloated processes that make it difficult to build software that’s deployed quickly, or simply not understanding customer needs and building a product that doesn’t resonate. 

A common solution deployed by organisations is using end-end customer journeys to define product development initiatives. This is often used by organisations keen to communicate the end vision to stakeholders, and help ease the fears of risk-averse decision makers. But do these practices reduce or exacerbate risk? 

What is a customer journey today?

A customer journey highlights the steps customers make to engage with companies, products, and all related touch points. It is sometimes drawn as a series of sequential steps and activities.

For existing products, some research can identify these touchpoints and is a useful exercise to highlight areas that may require attention or simplification.

But there are some common pitfalls with end-to-end customer journeys:

  1. Outsourcing research. Using a design agency or a separate team to research the problem space and identify customer journeys is not helpful for the product team that will inherit the initiative. It's imperative for the product team consisting of product managers, designers, and developers to understand the problem space and to empathise with customers. Getting laser focused on solving customer problems is really hard when you simply do not have the context. When this research is performed without product teams, expect mediocre results. 
  2. One-time research. Performing research in one go is risky. You end up making quite a leap of faith that your research was conducted correctly, your insights are valid and that your solution will solve customer problems before you have written a line of code. Assumptions built on top of assumptions. Like building products research should also be iterative. Understand customer pain points and how they are currently trying to solve for that problem. Mock together low-fidelity prototypes to see if the problem is understood and if the solution solves for it. 

How to get started

Wat’s the alternative to researching end-to-end journeys upfront? A concept used by successful product teams is ‘just enough for now.’ The concept refers to research, design and development. The idea is to keep the build - measure - learn cycle as short as possible and work to release value to customers as soon as possible. 

My top tips here are:

  1. Great products are made by teams that create empathy for the customer. Gather a small team consisting of; a product manager, a product designer and a developer. These three disciplines will ensure the team looks at any potential solutions from a desirability, feasibility and viability lens.
  2. Timebox activities to a few weeks.
  3. Gather assumptions, what are the leap of faith assumptions that must hold true for this initiative to work?
  4. Prioritise assumptions by the riskiest assumptions.
  5. Gather information both qualitative and quantitative to validate and invalidate assumptions.
  6. Understand the problem space and check how customers are solving needs currently. How satisfied are customers and how important is this problem to customers?

By this stage the team will have a list of customer problems ranked in order of priority. They will have a good idea of how big these problems are and the opportunity they present to the organisation if solved better than current solutions.

Note it may not find an opportunity that is worthy of investing in. That’s actually great and far better than spending months identifying end-end customer journeys. It's far more cost effective to spend two weeks disproving a multi-million dollar initiative than spending six months investigating every touch point of customer journeys that will never come into fruition.

If some problems are found worthy of investing in, the team can now ideate together to find solutions to those problems. 

There are a number of techniques which help to facilitate ideation in a cross-functional team, including design studios and low fidelity prototypes. Always speak to target customers and validate a solution’s ability to solve the problems identified. Hypothesise, prioritise, and ideate as a team. This won’t be end-to-end, and it won’t be a one-time activity, but the team will more likely to get to a point where they are solving real problems and fast. 

Overcoming the need for a plan

Here’s how to make the argument to a stakeholder that really wants to see that end-to-end vision: If the idea is to get value out to customers as fast as possible, does it make sense to explore every customer touch point?

The time spent doing intensive research could’ve been spent building and delivering an MVP for customers and get them excited. Repeating this cycle gets the team to “learn by doing” and is actually a faster way to truly understand the customer’s end-to-end journey. It’s also a lot more engaging work than research and makes the team stronger.

Replies (0)

Please login or register to join the discussion.

There are currently no replies, be the first to post a reply.