Change Dependency Map

 

Many of the elements and situations that are blocking improved customer- centricity are often intertwined. Since many of our internal pain points feed each other, there will be changes that must happen before some other problem can be solved. For example:

• You might need to reconfigure departments and hire stronger people onto those teams. But we might have trouble attracting and retaining key CX staff while our processes around CX strategy and tasks are ugly. Candidates might not want to join or stay in that environment. While we are hiring, we will have to fix other things that are interconnected.
• You want to improve relationships between teams and the processes they are using. However, if the KPIs and metrics coming down from the top are customer-peripheric, we could be using new processes but still creating customer-peripheric PSE.

Before you try to create change, break down some walls, and rebuild them, you should map out and consider blockers that could prevent that change from happening. You might be able to predict these, or they might come up as you go. Map these with their appropriate dependencies. I call this a “Change Dependency Map.”

For example, we might imagine that training is the main ingredient needed for change. Let’s send everybody to Debbie’s training so we will all be ready to improve customer-centricity! Sure, but there will still be blockers.

• Do we have enough CX Researchers available to do all of the research that being customer-centric requires? If not, the change could stall or fail. We will first need to hire some people or shift personnel around so that even just one or two teams are ready to try new ways of working.
• Are our teams empowered to break out of how we do things now and try new processes, methods, and approaches? If not, all the training in the world might not produce the desired actions or outcomes.
• Did we plan extra time to try new ways of working? It’ll probably take us longer than our old ways, especially while new processes are experimental.
  • Did we estimate this time and update our roadmaps? Did we change our release schedule so that nobody is surprised that the new project is taking longer than usual?
  • Forgetting to plan extra time to try new ways of working could block our goal of successfully experimenting with more customer-centric processes. Estimating time, updating roadmaps, and changing the release schedule are dependencies under “planning extra time.” This is why the Change Dependency Map is a tree or hierarchy; fixing one or more problems unblocks a higher-level problem.
• How will we measure if our customer-centricity adventures are starting to work, or where we need to improve?
  • Do we have KPIs and OKRs in place? Are we ready to track and measure everything that we need to?
  • Does the team believe we are tracking or obsessed with the wrong numbers? Are teams under pressure to deliver customer-peripheric KPIs? We will have to shift or fix these to remove obstacles that can block the change we want.

Some companies bring in expensive trainers assuming that if we train everybody on this topic or method, we can then use this method, which will solve our problems. The example map reminds us that trainers alone rarely solve a problem or create a transformation because we haven’t cleared the blockers and dependencies.

Map anything that will block desired changes and outcomes. What must change before we can create the final or larger change? Work on changes at the lowest level of the hierarchy first so that teams are freed up and empowered. The lowest level of your map might be root causes blocking other changes. Mapping these out visualizes and socializes obstacles so that we can plan to eliminate them.

The sample map above has a broad and high-level goal of being more customer- centric. We can use a Change Dependency Map for a change at any level: project, team, department, or company. Our desired outcome might be very specific or a broader vision.

Empathy – Knowledge – Action™

 

Empathy (Alone) Doesn’t Solve Problems

Step 1: create empathy. Just have empathy for users. Design thinking is about empathy. UX work requires empathy. Empathy, empathy, empathy. Design for empathy. Design with empathy. Empathic design. We hear it so much that it’s losing its meaning. We can all talk about empathy. Write it on infographics. Hold group exercises to “create empathy.” Get certificates in having, facilitating, recognizing, or growing empathy. We can drown in the cottage industry of all the “empathy styles” models out there. Have we undertaken research so that we have strong data about target customers, or are we guessing or assuming? Are we filling walls with sticky notes while creating products, services, and experiences that aren’t accessible? Are we lacking ethics while claiming we really empathized with users? This reminds us that we need more than empathy to find and solve problems. Meet the Empathy – Knowledge – Action Model.

Add Knowledge and Action to Your Conversations About Empathy

Empathy and Action Without Knowledge

You guessed or assumed and called it “empathy.” You skimped on or skipped CX/UX research claiming that you “know everything about customers” and “you already know what users need or want.” Without data and knowledge to back that up, your “empathy” is a lie. What we believe about customers must be based on what we know about them. Facts. Not guesses or assumptions. Your actions were most likely a mismatch to customers’ real tasks and unmet needs. You got something done, but you might be surprised later when customers complain.

Knowledge and Action Without Empathy

Acting based on customers’ known realities could be great. Seeing their world through their eyes would add an important dimension. A common mistake here can be overfocusing on quantitative metrics without pursuing more qualitative data. We know that 77% did this, 23% said this, and our NPS was -34, so we acted. Without digging more deeply into the perspectives of users/customers, and learning more of the hows and whys, our course of action might be going in the wrong direction.

Empathy and Knowledge Without Action

You had good info/data. You feel for the customers’ pain points and needs. And then you did nothing… or something that didn’t fix it. Having empathy based on research-based knowledge can be meaningless without action. If you know that customers are frustrated by a product or feature, but your response is one of these:

• “We can’t prioritize/budget for that fix right now.”
• “They’ll figure it out or they’ll contact customer support.”
• “It’s probably not affecting too many people.”
• “Engineering needs to work on new things rather than keep going back to old things.”

Then your inaction or incorrect actions render your empathy and knowledge meaningless.

Evolve Beyond Product-Led to Value-Led

 

Will we be a product-led, engineering-led, or sales-led organization? Will we be values-led, as in led by our company values?

We will be value-led: how much value we can frequently create for potential and current customers.

Wouldn’t that be a product-led organization? Being product-led is supposed to be about attracting and retaining customers through high-value PSE. Some “product-led” companies decide on features based on guesses, assumptions, or things they want to push people to do. That might be product-led, but it wouldn’t qualify as value-led. How to execute on being value-led is throughout the book.

A highly qualified and experienced UX Researcher from my community was recently laid off after his company announced internally that they would be “product-led.” Some companies define “product-led” as allowing anybody to do research, no matter their skill level or experience, and no matter the quality of the research or its outcomes. We’ll cover this in detail in the “Common Research Mistakes” chapter. But being product-led should inspire us to grow research teams, not lay off our best Researchers.

We might say we are a sales-led organization, but ultimately, we are selling PSE (products, services, and experiences), which must be an excellent PSE-market fit. Sales will struggle with turning trial customers into paid, turning leads into conversions, and retaining and growing existing customers when our PSE are low value and fail to meet target audiences’ standards.

I have also seen customer-led, but our teams are pushed to move fast and create what we hope is “good enough” for customers. Could we call this speed over quality approach “customer-led”? We might be led by what we want to build for users and customers, absent of research or reliable evidence on customers’ problems or needs.

 

We will have to choose which is more important to us: speed of getting projects done, or the quality of getting them done well and having good outcomes.

Guessing what customers want isn’t value-led. Aiming to improve business metrics and assuming that whatever the customer gets out of that is “good enough” isn’t value-led. Neither is “the least we can do,” the fastest we can go, or something we know is minimally viable.

Trying to do each other’s job isn’t value-led since value is most likely to be created by people good at that task. A Marketing expert is more likely to create quality and value for customers than a non-Marketer trying to do some Marketing work.

Pretending AI bots represent our customers and can speak for them isn’t value-led. Observing humans will always be the best method for researching potential and current customers.

Once you prioritize quality and outcomes over speed, moving fast, shipping fast, breaking things fast, etc., then you are headed toward being value-led. While your teams prioritize speed over quality, you are more likely to still be led by Engineering, Product, Sales, or executives.