Sales leadership said customers hated the product. Product Management said we had to build it to compete.
The product was a standalone scale-out storage appliance, and at the time Veritas was taking some heat from smaller, more nimble competitors. They were building simpler products and painting us as the big, slow, complicated legacy company. Product was under pressure to respond.
Sales was hearing something different. Some of our oldest and biggest enterprise customers had spent years building highly centralized backup environments. Backups were managed, monitored, auditable, and generally kept under one roof. A standalone appliance that made it easier for individual application owners to manage their own backups did not look simpler to these customers. It looked like another rogue system their backup team would eventually have to explain to an auditor. Simply put, they hated the idea.
But Product Management had evidence too. Depending on who you talked to, customers either wanted exactly this kind of flexibility or wanted nothing to do with it.
I’d worked with both teams and had done research with many of the user types involved. Nobody appointed me to settle the argument. I just found myself in the middle of it. Product Management was a regular research client, I knew the Sales team well, and both sides trusted me enough to listen when I shared feedback from one side to the other.
Somewhere along the way, I started feeling a little less researcher and a little more mediator.
I’ll come back to that.
Whatever we were calling ourselves at the time 
My first title at Veritas was Software Developer, but no, I wasn’t developing software. I had a graduate degree in Human Factors Psychology and had been hired to do something the company did not yet have a name for.
We churned through plenty of names after that. We started with one of my favorites, the Usability Team. We were also Veritas User Engineering, then Symantec User Research Engineering. Later came Experience Design, Product Design, UX, CX, and probably a few others I’ve forgotten on purpose.
The names evolved along with the organization and whatever language was becoming more common in the field. “Usability” eventually felt too narrow. “UX” captured something broader. Later, “CX” reflected an even larger scope around the customer. Sometimes a broader name genuinely reflected how the work had evolved. Sometimes it was simply the language the organization was moving toward or aspired to.
The names helped with recruiting too. People want to join the team doing whatever seems important and interesting at the time, and nobody particularly wants yesterday’s buzzword on their résumé.
What changed less dramatically was the underlying work. Who are we trying to understand? What are they trying to accomplish? What gets in their way? What do we need to learn? What decision are we trying to make?
That’s part of why the current discussion about where UX ends and CX begins initially struck me as a little strange. For most of my career, I didn’t spend much time thinking about it. If there was a useful customer or product question to answer, we tried to answer it.
The people coming to us for help rarely had a taxonomy problem. They had a decision they couldn’t make.
“We need a usability test”
A lot of my work functioned like internal consulting. Sometimes a client would come to us and say they needed “a usability test.”
Sometimes they did. Sometimes “usability test” just meant, “I need help getting feedback from actual users.”
We learned to start the intake discussion further upstream. What are you trying to accomplish? What are you seeing that makes you think there’s a problem? What do you already know, and what are you assuming? Most importantly, what decision could the research actually change?
Only then did we get more tactical. Who should we learn from? How quickly do we need the answer? What resources do we have?
The clients who knew a little about UX could actually be trickier because they were more likely to arrive with a method already selected. Then we had to figure out whether the usability test they requested would answer the question they had, and whether their question was the right one in the first place.
We practiced this. We experimented with intake questions and trained researchers to use techniques like the Five Whys to get past the visible symptom and closer to the underlying
problem. The question leads to the decision, and the decision gives the question a reason to exist. It also determines who you need to talk to.
We learned that lesson all over again when we met consumers.
Then we met consumers
After the Symantec acquisition, we began working with Norton products and studying consumer users for the first time.
For years I had been talking to system and database administrators, storage administrators, architects, and other highly technical enterprise users. During one of my early consumer studies, we were exploring concepts that combined security and data backup. I started talking about the backup functionality when a gentleman raised his hand.
“Do you mean the button you click to go back to the last page?”
I might have laughed if I hadn’t been so caught off-guard by the question.
Consumer research changed almost everything about research context and recruiting. Recruiting enterprise research participants had always been one of our biggest headaches. Finding enough of the right specialized users could delay a study or leave everyone arguing afterward about whether we had talked to the “right” people.
Consumer users were everywhere. We could intercept people near stores, meet them at a coffee shop, or buy someone a pizza and sit in their living room while they showed us how they actually used their computer.
I even redesigned part of our usability lab. We kept the traditional desk, monitor, keyboard, and yes, the one-way mirror, but added a couch and coffee table and whatever else we could afford on our meager budget to create a much less formal space. The participants changed, so the research environment had to change too.
What didn’t change was the fact that research for one product could involve studying several different human roles. Enterprise software had already taught us that. Consumer research just rearranged the cast.
We met plenty of people who had a Norton product installed but knew almost nothing about it. When something went wrong, they called a son, uncle, friend, neighbor, or whoever they knew that happened to be “good with computers.” That person might be asked to recommend software, install, upgrade, or troubleshoot it.
Internally, we started calling that person the informal system administrator and built personas around the role. A familiar enterprise concept had reappeared in somebody’s living room, just with fewer servers and more unpaid technical support.
One woman using the latest version of Norton Internet Security answered almost every question the same way.
“Oh, I’m not too sure about that. You should ask my son, Jesse. He’s the family Geek Squad guy.”
So when we talked about “the user,” the useful questions became more specific. Who actually uses the product? Who chose it? Who installed it? Who gets called when it breaks? Who decides whether it stays?
In a consumer household, two or three people might divide those responsibilities. In an enterprise, you could need an org chart.
Who’s your user?
A large enterprise might have architects, administrators, application owners, security teams, procurement, executives, and budget owners involved with the same technology. Those weren’t merely different job titles. Each role changed what that person knew, cared about, and could influence.
The administrator might spend every working day in the product and have almost no say in whether the company bought it again. I’ve talked to plenty of those people. Some were deeply frustrated by products they had no authority to replace.
Move higher or sideways in the same organization and you could hear a very different story. An architect might care about whether today’s product fit the technology direction planned for the next three years. A risk officer might care about surviving an audit. Meanwhile, the storage administrator wanted a tool that worked every day without making routine tasks unnecessarily difficult.
A product could work very well for one of those people and still frustrate another. That isn’t contradictory research. They’re evaluating different things.
To make things more unpredictable, the cast of characters kept changing too. Enterprise software moved from boxes of physical media to downloads, portals, subscriptions, SaaS, and cloud services. Every shift changed some combination of who evaluated the product, bought it, deployed it, managed it, and actually used it.
All of this creates a problem for anyone who casually says, “The customer wants…”
There may not be one customer opinion waiting to be discovered. Sometimes there are opposing interests inside the same account.
That’s what was happening with the storage appliance.
Everyone had customer evidence
To the application owners, decentralization meant speed and autonomy. To some backup administrators, it threatened the very model they were responsible for maintaining. These were people’s jobs, authority, and professional responsibilities. You could hear the tension during interviews, and it was a subject we learned not to treat casually.
Sales was hearing resistance from some of our oldest and largest customers. Product Management was watching newer competitors gain attention by promising something simpler and more flexible. Both sides had customer evidence. The evidence was almost directly opposed because the customers themselves had opposing interests.
I had become one of the people who could move between the teams without being seen as belonging to either camp. Over several weeks, I used many of the same techniques we used in research more broadly: clarify the question, isolate assumptions, keep discussion focused, and make disagreement specific enough that it could actually be investigated.
In other words, I treated the broader situation like a research project.
What outcome are we all trying to achieve? Where do our assumptions diverge? What question, if we could answer it, would change what we do next?
Then we tried to agree on the measurement before seeing the result. If the answer is A, what does that mean? What would we do? What about B or C? What evidence would actually be enough to change our minds?
The logic reminded me of SMART goals. Make the objective specific. Decide what evidence is measurable. Keep the research achievable and relevant to the decision. Put enough time around it that “we’ll keep looking” doesn’t become an escape hatch when the answer is inconvenient. The conversations became much more productive, and it looked increasingly likely that the product would need significant changes, a delay, or both.
Then Huawei happened.
They were our hardware partner, and the project was killed for reasons that had nothing to do with our carefully structured slice of the debate. So I can’t give you the satisfying case study ending where research resolved everything and the perfect product emerged. Enterprise technology rarely cooperates that nicely.
What stayed with me was more useful anyway. Sales wasn’t wrong. Product wasn’t wrong. The customers weren’t wrong either. They were answering different questions from different positions inside the same system.
Sometimes contradictory customer feedback isn’t a research problem. Sometimes the contradiction is the finding.
But you only get there by asking the right questions of the right people. And the fragmentation didn’t stop with the people we researched. The experience itself was divided across teams too.
Our org was showing
Enterprise software could be ridiculously complicated to buy, install, configure, use, upgrade, and support. Each part of that journey might be shaped by a different team inside the company, but the customer experienced it as one continuous relationship.
Marketing might shape the first impression. Product and Engineering shaped what customers eventually used. Sales and Support owned very different but equally memorable moments. Then there were portals, licensing, documentation, downloads, and all the other pieces customers encountered without caring which department built them.
We created a program called First 24 Hours, or F24H, to look across those seams.
For an F24H session, we brought together representatives from the teams involved in creating the experience and built as realistic a customer environment as we could. Then we worked our way through the experience from the user’s perspective, from first contact through installation, configuration, early use, and whatever else the product required.
We had a persona named Dexter, and somewhere along the way we made WWDD, What Would Dexter Do? bracelets. That question became a useful reset whenever the room started thinking too much like the people who built the product. What would Dexter do here? What would he expect to happen next? Are we assuming knowledge or training he probably doesn’t have? Who would he need to involve to keep going?
Every issue was documented and assigned an owner, but some of the most valuable outcomes weren’t defects at all. Participants regularly told us how valuable it was simply to meet people from teams that owned adjacent parts of the experience, or to see the complete installation process end to end for the first time. That always amazed me.
We had extraordinarily complex products assembled across a global organization that was heavily siloed in places. The customer was often the first person to encounter all of those pieces as one continuous experience.
F24H became valuable enough that eventually the CEO mandated it for major releases across the company. That created a serious new UX research problem: ours.
We simply didn’t have enough researchers and designers to facilitate such a large and sudden influx of new clients. So we documented the process, created supporting materials, and taught people across the organization how to run it themselves.
Was F24H UX research? CX? Service design? Product quality? Internal consulting?
I don’t remember anyone asking, and I don’t know that answering the question would have improved the work. What mattered was that it allowed an organization divided into functions to see the experience as the customer experienced it.
The names eventually caught up with me
For much of my career, I had the luxury of treating boundaries as permeable. If an important question crossed from product use into purchasing, support, customer relationships, or another part of the experience, we could often follow it until we reached somebody with the expertise or access we did not have.
But once disciplines mature, definitions become useful infrastructure. I know because eventually I had to build some of it.
I started my career with a title that didn’t describe my job. Years later, I helped revise the user-research career framework at Symantec and then built a new one for the reestablished Veritas organization. That meant defining levels, expectations, scope, skills, and what progression actually looked like for researchers. It also meant working with leaders of adjacent disciplines to make sure our roles were distinct enough to be meaningful without creating unnecessary overlap or important gaps.
Apparently I went from having the wrong title to helping HR define the right ones. And by then, getting them right mattered.
Titles affect hiring, compensation, evaluation, and advancement. Organizational boundaries matter too. If UX Research, Marketing, Support, and Sales all have access to different parts of the customer, some clarity about responsibility prevents duplicate work and makes collaboration easier.
So where does UX end and CX begin?
I don’t think there is one universal answer.
UX tends to sit closer to interaction with the product. CX tends to widen the lens across the customer’s relationship and journey. Those distinctions can be useful. They help us
organize teams, teach disciplines, recruit talent, establish career paths, and decide who should lead what. But they’re abstractions laid over a much messier reality.
The user may also be the buyer. Or not. The administrator may hate a decision the architect loves. Sales may hear one version of the customer while Support hears another. A usability problem may turn out to involve installation, training, policy, or something outside the product entirely.
Looking back, I don’t remember us spending much time debating where UX research ended and CX research began. The names certainly came up. Every reorganization seemed to create another opportunity to ask whether we were really doing usability, UX, CX, Experience Design, or something else. Sometimes a broader name genuinely reflected how the work had evolved. Sometimes it was simply the language the organization was moving toward or aspired to.
By the time I was building research career paths, I had a very different reason to care about those definitions. That probably explains why I find the UX/CX discussion more interesting now than I once would have.
I also think there’s something pretty great about the fact that we’re having the discussion at all. I started my career with a Software Developer title because there wasn’t a better one. We spent years explaining what this kind of work was and why companies needed it. Now there are enough researchers, teams, disciplines, and career paths that we can argue about where one ends and another begins.
That feels like progress.
I understand why we want definitions. They help us build teams, careers, and organizations.
I’m just not sure the work itself will ever sort quite as neatly.
Other (please describe)
