My Initial Layout of Customer Journey Integration

Remember: the end user is not always the customer on a journey

Remember: the end user is not always the customer on a journey

In my last piece I laid the groundwork for the 14 Customer Journeys necessary to understand customer experience completely. These 14 journeys are based on the list of consumption chain jobs found in Outcome-Driven Innovation® (ODI); although I have modified and added to them slightly. In Jobs-to-be-Done, the Job and each Step are designed to describe an objective, or an achievement. They are also named in a very similar fashion best practices found in the process modeling world. And one more thing, they do not use mushy words that are inconsistently defined.

A process guru’s take on using mushy words:

“They are easy to use, so they give the illusion that progress is being made, but they really don’t tell us anything. In other words, what is actually “achieved” when we use the term Monitor Shipment, Administer Application, and Track Project?” — Sharp & McDermott (2009)

While ODI does not always map out consumption chain jobs when studying core market innovation (problem-space), once a market opportunity is found, and a winning solution concept is established, the various services that must accompany a solution during its lifecycle of ownership inevitably need be established. These services exist in the solution space, and since I will be dealing with universal models, there will inevitably variations for a particular study. However, a universal map is a solid starting point for understanding:

1. The collection of journeys that must be studied

2. Who takes the journeys (it’s not always the end user)

3. The scope of a specific journey

4. The success metrics you can use to take to establish specific themes of design requirements and specifications

In this piece I’m going to talk briefly about how to leverage best practices from the process world in order to put some necessary rigor around customer journey mapping. I’ve already received comments that 14 journeys may be overkill. But as I stated, not every product will require all 14 journeys.

While I agree that rigor should only be developed until we reach the law of diminishing returns, the sort of rigor we generally see in the journey mapping does not provide the actionable detail I would like, and neglects some applicable key learnings from the process world. We should strive to find a middle ground to move this discipline forward.

The Wrong Level of Abstraction

Customer journey studies tend to focus on three (3) areas: buying a product, using a product, and getting help with a product. Sometimes we see them mapped separately, and sometimes we see them bunched together. While I’m certain there are exceptions, these journeys tend to focus on an end user persona. While there are usually multiple personas, each of these personas attempts to reflect a market segment, and I would contend that journeys should be designed for specific segments due to the vastly different needs found in a proper needs-based segmentation scheme.

While it’s often expedient to design, or redesign, a solution based on a common set of needs (underserved and overserved), a case can also be made that they should be focused on specific segments of opportunity (underserved or overserved). In my view, when I talk about customer types that take specific journeys, these are not different personas in the traditional sense. They could all be the end user, or some might be professionals that are hired to provide a service; and thus, takes a journey related to providing the service to the end user.

Read my take on personas here

When journeys are mashed up, and use stages labeled with single-word terms like Awareness, what we end up with are extremely non-actionable assumptions, because they’re simply too broad. In cases where services must be designed for a new product or emerging technology, this simply cannot work with any level of assurance (it doesn’t currently exist).

When we’re looking at existing products we’re assuming, of course, it’s a winning product concept. Either way, there is not enough granularity to surface actionable data points that can be relied upon over time when attempting to provide necessary service design inputs.

What exactly is a persona trying to achieve with mashed up journeys? What are their objectives related to Awareness, for example? In the process world, and in the Jobs-to-be-Done world, “journeys” are always expressed as objective-oriented statements, and so are the steps within them. Generally, if you cannot get a group to define these consistently, and/or you cannot identify a discrete achievement, success measures are almost impossible to define, and the value of the data is therefore highly questionable.

Local Optimization

A wise man once said “Local optimization leads to global sub-optimization.” This generally means that if you focus on improving a step, or a sub-process, or even a single process in a chain of other core processes, you are likely to make the overall set of processes weaker. Here are a few ways to look at it:

1. If a department takes shortcuts that benefit themselves, it is likely to deliver a malformed output to whatever process consumes the output. This means the receiving party must often reconfigure the input to work in their process, and this takes additional time, and effort that was unintended.

2. If you have a chain, and wish to make the chain stronger, making a strong link stronger does not make the chain stronger. The entire chain must be studied to determine where the weak link exists. Improve the weak link.

3. If you have a process that has adequate capacity, do not improve the capacity if the subsequent process is unable to process the output at a similar capacity. This could lead to excess inventory, delays, etc.

If this is starting to sound like a recital of the Deadly Wastes of Lean, it’s not. It’s simply a contributor to the deadly wastes. Why wouldn’t this apply to customer journeys as well? If there is an increase in demand for product support, should you focus on the buyer journey? If you are in marketing, you’re going to focus on the area you have authority over. However, understanding the entire set of journeys, and adequately prioritizing them is critical for a provider to understand so they can focus on the journeys that are causing frustration in the lifecycle of product ownership.

One Journey or Many Journeys?

It has been noted by experts in the workflow modeling world that people often conflate multiple processes into a single process. Sometimes they will see three processes when there are only two. While I established 14 customer journeys for customer experience, they are all integrated with each other at various points (in relevant contexts) just like a family of processes and sub-processes. In some cases, an end user will hand-off to a service provider; similar to a shared service in the corporate world. The need for a service provider is highly likely to be determined during needs-based segmentation at the core functional job level and associated with a specific segment.

Shared services can often take-in outputs from multiple instances of a parent process. In that case, a M:1 relationship exists; which is a clear indicator that the processes are separate. The handoff back to the parent process is 1:M, an obvious indicator of the reintegration back to the parent process.

When this occurs, the initial journey actually pauses. This handoff/pause will have its own set of consistent success measures. When the service returns a result to the initial process, there is another integration point with a set of success measures. The initial journey can then continue, and as you see depicted below, so can the other journey — which can easily extend beyond the scope of traditional journeys). In fact, this is an example that shows why some people see three processes when there are only two. The same thinking can apply to journeys.

Universal Journeys are examples only, and subject to change

Each of these journeys has an actor that takes the journey. I’ve generically called them the BUYER and the DECISION-MAKER for this example. These could both be the end user. Or, neither of them may be the end user. In Enterprises, the end user is often exactly that, the end user. The decisions are not made by them, nor do they actually make the purchase. Yet these activities do have an impact on the end user because the end user expects that the product meets their functional needs, is in good working order when they need to use it, and can be customized to their personal liking, etc.

In consumer goods, it’s very likely that you can look solely at the purchase journey, but the success measures you establish for the key integration steps should consider the areas specified by the more specific selection journey. Be that as it may, more breadth, depth, and focus should be brought to the way we look at these journeys; if we are to help customers achieve the experiences they need, desire, and want by developing highly actionable metrics. More on that, down the road.