Customer Experience (CX) Mapping

What is CX Mapping?

CX mapping is a process for focusing the work of a team on outcomes–day to day, week to week, and quarter to quarter. It’s amenable to both qualitative and quantitative evidence but it is strictly focused on observed customer behaviors, as opposed to less direct, more lagging observations.

It starts with an unpacking of how a customer goes from knowing nothing about a given Value Proposition to exhibiting all the observable behaviors you’ve defined as a successful outcome for that Value Proposition. I like to use the definitions you see here:

These particular terms, this particular funnel framework, isn’t that important. However, there are three things about your approach to CX mapping are important to get right–specifically, that it:

1. 1. Has Pipeline Definitions that are Complete and Mutually Exclusive
      Regardless of how you describe a user going from never knowing about a product or feature to exhibiting all the behaviors you want for your business model, the terms should be as complete and as mutually exclusive as possible.
   2. Describes a Single JTBD:VP Pairing
      A given CX Map can describe a single JTBD: Value proposition pairing–for example, ‘Getting Replacement Parts to a Job Site: Parts Ordering Application’ in the case of HinH. Given that you can factor JTBD at various levels of abstraction, this still leaves you a lot of discretion about scope. However, particularly if you have a product suite with a lot of discrete VP’s, it’s not necessarily the place you should capture topline metrics like monthly active users or gross revenue. The main job of the CX Map is to help isolate and unpack user behaviors in context vs. provide a single business-wide view of what’s happening.
   3. Describes a Single User
      You can top down this or bottom up it, but these definitions apply to the behavior of an individual user.

From an intuitive explanation of these various stages of the CX, the team that sketches answers to the following questions for each one:

1. How do we observe this? What’s the DV?

This come next after we answer the question (call it question 0): What does this mean? Without that, obviously, it’s hard to establish the right measurements (though not for lacking of trying in many cases). More is not more here: the goal is to come up with a focal single metric (maybe two), a ‘dependent variable’ (DV) that tells you how a customer has behaved in a given phase of the CX (ex: Acquisition, Onboarding, etc.).

This should be a rate or ratio. Let’s say you had 1,000 new sign-up’s yesterday- is that good or bad? It’s completely ambiguous: if you spent no money on advertising and had 20,000 visitors, it’s great. If you spent $10/click through for 100,000 visitors, it’s a lot less good.

2. What is the cut off for a transition?

Not super exciting, but extremely important in actual practice, the idea here is to establish the cutoff for deciding whether a user has progressed from one phase to the next or abandoned/churned. For some items like Acquisition, this is fairly obvious: a visitor to your site is probably going to decide to sign up for a free trial or not within a few minutes. But what about actually starting to use your application, a process we’ll call ‘Onboarding’? If they don’t do it in two days, a week, a month, are we ready to consider them abandoned/churned? This will vary from product to product, but if you look at your current actuals it’s relatively easy to establish a working cut off and doing so is crucial to keeping a CX map current and actionable.

3. What is our ‘Line in the Sand’ threshold?

Popularized by the book ‘Lean Analytics’, the idea here is that good metrics are ones that change a team’s behavior (decisions) and for that you need to establish a threshold in advance for decision making. For example, if the current Onboarding CX works for 40% of your users, is that OK for now, or something that where you should prioritize new discovery and testing?

4. How might we test this? What new IVs are worth testing?

This is (hopefully) the most dynamic part of your CX map and it’s perfectly OK not to have all your ideas ready on the first draft. The ‘independent variables’ (IV’s) you might test are basically just ideas for improving the DV. For example, let’s say you want to test offering live chat during the Onboarding process: that would be a new IV you’d test relative to the DV of how many customers make if from Acquisition through Onboarding.

5. What’s tricky? What do we need to watch out for?

This material is for grown-up’s, so I’ll freely offer this: the process won’t work perfectly the first time, or probably the second time. Don’t get me wrong- it will mostly work and just working toward good answers for the CX map will be extremely healthy for your team. Also healthy is scrutinizing the map and whatever analytics tools you’re using to get the observations it requires- and that’s what this funny little section is for. Whatever you want to double check or keep an eye on, or whatever you’re just plain unsure about how to do, make a notes of that here. It’s OK- it’s not a presentation, it’s lattice for asking and answering the right questions at the right time.

The image below shows a working CX map for a company (HVAC in a Hurry) that services commercial heating, ventilation, and air-conditioning systems. And this particular CX map is for the specific ‘job’/task/problem of how their field technicians get the replacement parts they need. More on this in the section below on how to CX map, but I thought an example would be helpful for understanding the process:

How does it work in practice? Well, picture this little vignette: You’re a PdM of an enterprise software product and you’re walking in to meet with the person who manages all your products’ users at one of your big customers. You ask her how things are going with the new tool. She says, “Not great.” Do you have background data to at least know where things went wrong? Did only a few of the users try the tool? Did they try it but find they weren’t able to do anything with it? Did they actually give it a good try and use it for a while and then stop using it?

This is crucially important to figuring out how you’re doing and where a given team needs to focus. In practice, what it requires is that both in terms of qualitative understanding or ‘ground truth’ as well as specific metrics, there’s a minimum of ambiguity about which state a given user has progressed to–Onboarding, Engagement, etc. With a basic digital analytics set up like Google Analytics, this is usually pretty self-evident and doable with the exception of Outcomes- and we’ll get to that in the section below on ‘How?’.

Why do CX Mapping?

Just taking it from the top, I’m going to assume:

1. you’re working at some for-profit venture
2. you believe organic growth is important
3. you think customer-focused innovation is the best way to do that
4. you’re come to understand that means you need to focus on customer outcomes vs. company output
5. you want to operationalize a focus on customer outcomes whereby every person in every product team understands how their outcomes contribute to the company’s top line objectives

How do you know if these things are happening at your company? I can offer five tests you can use to generally assess how well you’re operationalizing against customer outcomes.

1. How well are OKR’s (or a similar metrics-driven framework) working?

If teams are metrics driven in a systematic way are those metrics consistently easy to identify and actionable? For example, if you use OKR’s, is it easy and natural for product teams to define and assess their objectives and key results, or is it a mad dash at the end of the quarter that’s starting to make everyone cynical?

‘Cascading’ OKR’s or any management-by-objectives framework is the hard part. How do you go from something like ‘become the world leader in {x}’ or ‘reach {x billion in revenue}’ to the work of an individual team, let alone an individual contributor. It’s hard, it takes work, and it won’t deliver 100% of the time, at least from everyone’s diverse perspectives. But the alternative is to have teams that are misaligned with the company’s objectives or (maybe worse) investing a fraction of their available creativity and energy in their work because they don’t connect with the company’s bigger picture. If there’s a lot of churn on what management says is important, that’s another red flag here.

Does CX mapping fix all this?  Not all by itself and not automatically, but given how much work it is (not that much), it’s a pretty good way to more intentionally unpack how a team’s work aligns with the underlying value proposition they’re delivering. Specifically, it pushes a team to contextualize what constitutes success both in terms of more intuitive qualitative observations about customer behavior and then to pair that with specific behavioral metrics, which are important for driving to crisp, intentional decisions about where to focus.

2. Is the company’s primary focus being on-time and on-budget?

The issue here isn’t that you want to be off-plan and over budget, but instead that while achieving good project management in the traditional sense is comforting, with innovation it is zero guarantee that what a team achieves is economically significant. This is not true if your output is a known commodity, but, as I mentioned above, I’m assuming this company (or at least the part of it that’s considering CX mapping) is focused on organic growth through innovation. If this is the case, if, for example, you offer a software application, then new code can be worth zero if customers don’t engage with it, or even less than zero if it furthermore encumbers the core product (creating UX debt and tech/engineering debt).

And yet, there’s a reason it’s so hard to change from an output focus to an outcome focus: managing well is hard and doing it at scale is even harder. What I like about CX mapping on this one is that it creates the basis for an equally rigorous and actionable point of view on what constitutes success- a way to manage against customer outcomes at scale.

3. Are there are too many feature requests and are some of them bad?

Whether it’s internal IT or a high profile product, the company and product teams’ handling of feature requests is a leading indicator on whether a product is improving or decaying its product/market fit. In a low-functioning product, all feature requests are duly logged and fussed over- prioritized three different ways, for example. In an even lower-functioning product, they’re ignored.

In a high-functioning product, all the requests are carefully considered, but the team has the initiative on learning about the ‘why?’ of the requests, proposing alternatives to the user where applicable, and can crisply distinguish investable features from bad ideas. And yes- I’ve found cx mapping helps with this. Specifically, it helps keep products and teams focused on a set of user behaviors they care about, which provides a robust mechanism to stay ahead of feature requests.

4. Do individuals tend to make decisions solely on intuition because your analytics are after the fact?

This is a big thing with the larger body of work on Hypothesis-Driven Development (HDD) and it’s integral to the CX map’s focus on being hypothesis-driven. The whole idea is that you start with a testable framing for your ideas

CX mapping is not about ‘analysis paralysis’ and waiting for complete certainty before taking action. Particularly in tech, fortune favors the bold. CX mapping starts with the proposition that customer behavior is hard to predict. The untold story of just about every successful startup is that they had to kill or ‘pivot’ from lots of ideas before they got the outcome they were after. If the age old take on new ventures is something like ‘let’s build a lemonade stand’, then CX mapping and HDD just amend that a little to something like: ‘let’s build a lemonade stand at the intersection of 4th and Main this Saturday and if it makes over $50, we’ll consider that a win.’ This is, of course, the way actual science works (when it’s done right) and increasingly it’s a standard practice for innovation.

5. Is churn too high?

Truly the opposite of sales, this is a central topic for any serious product team and the reverse is also true. That said, new wins are a lot more fun than dealing with the bad spots of a customer experience that doesn’t fully deliver- after all, maybe this next customer won’t have all those issues?  This is particularly challenging with enterprise (B2B) products where the renewal cycles are long and there’s usually separation between buyer and user of your product.

Here again, there’s a widespread fallacy of neglecting churn not because we’re terrible people, but just because fundamentally we’re a bunch of hairless apes that just want to be loved. With the right tools, though, most of us are capable of some discipline and that’s what CX mapping offers here- a cohesive, regular, systematic foundation for taking a complete view of CX and making intentional (if unappealing) decisions about where a team should focus.

When should you do CX Mapping?

The short answer is always and often. If you already have a product or feature underway, great- you probably have a head start on the qualitative and quantitative observations on CX that you’ll need and it will help you focus and prioritize your work. If you’re starting something new, this is a great way to balance and prioritize your work to maximize learning and progress and minimize waste. Naturally, if you’re struggling with any of the five items above, that’s a great reason to do CX Mapping.

Who should do CX Mapping?

If you’re familiar with the practice of writing user stories, the answer here is pretty similar: Someone (probably a product manager or similar) should take the lead, but involve as much as the team as possible. The reasons are twofold: First doing so will improve the team’s engagement with the practice of managing to user outcomes vs. blindly creating output. Second, they’ll almost certainly improve and sharpen the CX map itself.

How do you do CX Mapping?

Above all else, you practice and get better at it. If you want to just dive in, here’s a link to a template on Google Docs: Hypothesis-Driven Development Template/CX Mapping.

That said, if you’re sitting down to do this (by yourself or with a team) here are {n} steps I’d recommend. It’s not a board game and, of course, you can do the steps in whatever order you like. Furthermore, you should be asking hard questions about the map weekly and updating it- and for updates there isn’t really a fixed order. That said, for each of these steps I have offered some ideas on how the various items relate to each other and help with transitions.

1. Frame the Job-to-be-Done and Persona

The scope of a CX map is a single ‘job-to-be-done’ (JTBD) and a single value proposition. If you’re not familiar with JTBD, the basic idea is to frame the user’s underlying need/job/habit/desire independent of your particular solution. For example, with HVAC in a Hurry the JTBD is ‘getting a replacement part to a job site’. The current solution is for them to call their central dispatch and the digital team wants to test a different solution where they use a self-service application.

This is important because in the innovation world we’re focused on new ways of doing things but only for underlying needs that actually, specifically exist for a user. Furthermore, you don’t want to start from the solution- you’ll get much better mileage from your CX mapping if you stay focused on how we’ll you’re delivering for the user’s JTBD vs. how well they’re relating to your solution, even if those seem like the same thing.

For more on JTBD, here’s a tutorial: Needfinding with JTBD. Or, for something more reputable, check out Clayton Christiansen’s seminal article on the idea in Harvard Business Review: Know Your Customer’s ‘Jobs-to-be-Done’.

2. Storyboard from the CX from Trigger to Action to Reward/Conclusion

You can’t do good analytics on a process or CX you don’t understand, or at least define in testable terms. In data science, we actually have a term for this: ‘ground truth’. For a team, there’s one thing I’ve seen consistently work here: storyboarding. For most, it’s awkward at first since most of us don’t draw, but creating art is not the point. The idea is to explicitly, intuitively describe where you’re user is and what they’re doing as they engage with your proposition.

If you feel like skipping this step because it feels weird and you think the answer is obvious and universally understood, consider trying this: have everyone on your team separately write down the steps a user takes to go from Acquisition to Retention in the CX map (no storyboard) and just compare notes. You’ll probably see a lot of variation. Regardless, it’s super useful to have some working storyboard as a reference for your CX map.

Here’s an example (notice the bad drawings- they’re fine) along with some notes on the various steps:

Note: If you’re familiar with Jeff Patton’s excellent work on user story mapping, then yes, this is process is very similar to the first step he uses in that process.

3. Describe each Phase of the CX Map

After storyboarding, this should be relatively easy: fill out the first row of the CX Map (‘What does this mean?’) with a simple, intuitive explanation of what the user is doing. Pay special attention to how it starts and ends since that will be integral for framing your DV. You’ll likely find you need to go back and revise these- that’s normal and fine and you shouldn’t hesitate to do it as your clarity improves and you start to exercise the CX map.

4. Frame a DV for each Phase of the CX Map

For each of these phases, describe a specific DV that is a rate or ratio. For example, for HVAC in a Hurry on Acquisition, it’s ‘Number of Signups/Number of Visitors’. The denominator is all the visitors that show up at the site and the numerator is the number that actually sign up. With this, they have a comparable view of what’s working on Acquisition regardless of whether they have a big traffic day or a little one.

As you progress through the phases, the numerator of the prior phase will generally be the denominator of the next phase. For example, population we’re considering for Onboarding is the population that made it through Acquisition- users that signed up.

5. Set a Cutoff for each DV of the CX Map

This is crucial since without this you technically won’t be able to accrue any observations. If you’re not sure, take your best guess and adjust later- otherwise, you’ll probably never start. For example, at HVAC in a Hurry, they’ve learned that if a tech doesn’t try out the tool within a day, it’s unlikely they ever well and so they place them in the churned at Onboarding bucket. For other applications, this might be different and you probably have some data already to do an estimate. Finally, the idea isn’t to incorporate every user into this measurement. For example, if HVAC in a Hurry has a few outliers that tool a week to Onboard but then used the tool, but 90% of the users Onboard (or don’t) within a day, they’re best off setting the cutoff at one day.

6. Identify IV’s for Testing

Even though this is where most of the action will be over time, this is the point where if you want you can be done and still have a working CX map. For example, you can just set up the measurements and start establishing a baseline, new or historical depending on whether you have the observations you need or you have to add them to your app or analytics suite.

That said, when someone has a great idea, THIS is the place to frame it. For example, the answer to “Wouldn’t it be cool if we {did something}?” is “Yeah, what DV on the CX map do we think that would affect and how do we test it?”. You can see some examples above in the CX map for HVAC in a Hurry.

7. Make Notes on Potential Rough Spots and Issues

These will exist and they’re OK! If you’re not sure if or how you’re going to collect and given observation or metrics, just make a note on how you’re going to figure it out. Not sure about the cutoff for an observation- no sweat, just make a note and keep an eye on it.