Dollars to Donuts: Frances Karandy of Citrix

Dollars to Donuts logo

Today’s guest is Frances Karandy, a senior manager within the Customer Experience Group at Citrix. We discuss doing product-focused research in a company with a large number of products, what to look for when hiring researchers, and how to select projects that not only support the business but also help team members to develop.

Design goes hand in hand with research.. it’s about solving complex problems. How do we improve not just the UI or the screen, but also the product itself? – Frances Karandy

Follow Dollars to Donuts on Twitter (and Stitcher) and show us some love by leaving a review on iTunes.


Steve Portigal: Thanks so much for being with us, Frances. I’m looking forward to speaking with you today.

Frances Karandy: Thank you, Steve.

Steve: Let’s just start at the high level. Maybe tell us about Citrix at a broad level, and what your role is, and what that involves.

Frances: Yeah, great. Citrix, if you don’t know the company, is an enterprise software company. We create virtualization, device management and collaboration software. What that actually means is that employees can be mobile and working from anywhere, on any device, securely.

We’re most known for GoToMeeting, you might have heard of that application, and for providing Windows applications at any endpoint. That could be a laptop, a thin client or even a Mac or iOS tablet.

I’m senior manager within the Customer Experience Group. I lead a team of user researchers who primarily support our application and Desktop Virtualization products.

Steve: Do you have counterparts that support other products?

Frances: Yes. I would say, in all, we have maybe two dozen or so user researchers and we’re supporting different business lines in different areas of the product. In addition to that, there’s also the Customer Insights Group that we work really closely with. There’s probably about another dozen or so, maybe a dozen and a half, on that team that we work closely with. Yes, we’re aligned to different product lines.

Steve: What’s the size of your team?

Frances: Four people. And then, myself would make a fifth.

Steve: Is there a specific type of customer for those product lines that you’re trying to learn about?

Frances: Yeah, actually, I would say not just our product line that we work on, but most of the enterprise product lines within the full Citrix suite. Really comes down to three segments that we’re often looking at or working with, within an organization. When we go in and we partner with a customer, pretty much it comes down to three types of users that we’re working with.

First one being the buyer. Who’s the buyer within the organization? Typically, that tends to be a C-level or IT executive. They would be the one signing the check for the technology solutions. There’s also the IT administrative team or staff. These are the folks that are responsible for setting up, deploying, rolling out, and maintaining the Citrix products within their organization.

Then, we also have what we call the end users. That would typically be the employees who are within the organization and accessing their applications, their data, really through Citrix. It’s these three segments that we could be focusing on at any one time.

For the most part, a lot of the work that we tend to do falls towards building out the administrative consoles, as well as that end user experience. We also have a small team that looks at the end user experience of our products, as well.

Steve: Let me just follow up with that a little bit. You’re looking at these different users, but you have a focus, your team has a focus on a specific set of products.

I’m wondering how the work that a different team is doing, that looks at a different set of product… users and organizations might be dealing with a whole range of products from Citrix, but organizationally, it’s divided up. I’m wondering if that comes up, that you have the challenge of some of what would be helpful for what you’re doing falls under the purview of another team.

Is that even a scenario that you deal with?

Frances: I think one of the interesting things that Citrix has been able to work through, finding the customers and sharing customer access, one of the things we’ve had to look at is who the customer base is and where they’re coming from.

Citrix has grown via a lot of acquisitions. When we bring on a new company, there’s that set of customers. As we expand and sell more of our other product lines into that customer, or vice versa, then it’s reaching across those product teams and lines, too, to say, “Hey, are there folks within your teams or contacts that you have in your organization that we could leverage?”

I think it comes down for us, finding the right sales or account person that has the connection with the customer that we might want to go do research with. More often than not, a Citrix customer will have more than one product deployed. It doesn’t tend to be too difficult to find out who has what and to be able to share that contact list. If that answers your question?

Steve: I like how you framed it, because I think there’s two aspects here. One is, in an organization that has multiple products and multiple individuals having relationships with customers for those products, just from a Citrix point of view, there’s a finding participants issue, which I think you’ve spoken to.

I’m wondering about the parallel piece, which is just that you are focused on product A, and you are visiting a customer, and there’s obviously different ways that you can look at what their experience is. One of those is to restrict it to their use of product A (I can’t remember what I had product A now) but given the kinds of work that you’re enabling, I’m wondering, and maybe I’m just digging into something that doesn’t exist…I’m wondering if, as you’re talking about that kind of work, the things that you’re going to hear, the opportunities you’re going to uncover, or the breakdowns that they’re struggling with could possibly span multiple products, given the breadth of offerings that you have, and this really large focus on how work is being done in these different kinds of work contexts, I’m wondering how focused your lens is given how broad the company overall is? Are you trying to strike a balance between what you’re learning, and how you can apply it within Citrix?

Frances: Yeah. I think it depends on the type of research study that we’re doing too. Certainly, we have opportunities to go out from time-to-time and actually sit down and visit with our customers and watch their users use our product, whether it’s the employee, or the administrator, or whatnot.

I think in that case we’re trying to be as broad as possible to really understand, what is their workflow? How do they do their work? A lot of times Citrix is that invisible back-end that’s enabling them to get access to their apps or data. They may or may not know that it’s actually Citrix running it.

When a company deploys a Citrix product, they might click on an icon that might be a Citrix icon, or that might be hidden. I think we have to be very broad on how we probe users and ask how they go about their workflow. On the data capturing end, we’re trying to look for what applications are they using? What are they experiencing? How is their work setup? And really come back and share that broadly within the organization.

Because, you’re right. We might find out about a user’s workflow could apply to not just our immediate product line, but other products that Citrix has. I think it’s a matter of trying to be as broad as possible and comprehensive, when we report that story or that set of findings back.

However, when we’re doing more narrow, I guess you could say more narrowly focused release research, or we’re trying to do usability testing on a particular workflow, that tends not to extend so much in those cases, unless either we specifically probe for that or the customer or administrator brings it up for example.

Steve: That helps. That’s great. What’s in place inside your organization culturally or process wise, for that first example where you are going to share things to the broad audience that can make use of them? How does that happen?

Frances: We have a couple of opportunities that we created to share research within the customer broader experience organization, and one of that is like a weekly sharing session. Anybody in the customer experience organization can come together. We’ll highlight a project, or a talk, or a topic. There’s that opportunity.

We also have a meeting specifically for researching customer insights that we hold once a month as well. That’s just yet another opportunity to maybe take a look at it from more of a research angle, or a techniques, or approach. We might bring a research question to share with the others and get feedback on. There’s several different avenues.

Then there’s All Hands Meetings that we hold on a monthly basis as well for the broader organization. There’s quite a few opportunities if you want to make the results of your work available within the customer experience organization, and of course beyond that to product teams and engineering teams that we work with on a regular basis.

So it’s usually those opportunities where, if someone hasn’t reached out to us that wants more details on our research or would like to be part of that, we’ll find out then if we haven’t identified them as part of that process to begin with.

Steve: Maybe one last question on this. I don’t want to bore you or everybody else. Those folks that express interest…you’re supporting specific product groups or specific teams with what your main assignment is. But through these kinds of sharing sessions, you may end up engaging with people outside that.

Frances: Right. I think maybe one clarification that might help with that is, going back to the portfolio of products that Citrix has, they have been acquired and have been intended to complement each other. So it’s really looking at the portfolio from a solutions sense.

We support the products and apps on desktop, but a lot of times our customers are running NetScalers, which is on the networking side of our business. Having a customer deploy multiple products inherently means that there’s in many cases a shared customer segment there or base, and that we’re going to hear feedback about other products, just because that’s so critical to setting up and deploying an environment, and making sure that these products talk and work together correctly is part of the setup process to begin with.

Inevitably we’re going to get feedback on other products and it’s just a matter of either sharing that broadly and/or reaching out specifically to teams to say, “Look, we did this research. They mentioned some things about the product,” or “Here, you might want to take a look at this a little bit further,” so we’ll be proactive about that, in addition to just sharing it broadly and see who else might be interested or how they might want to take that research forward and adapt it to whatever objective they have as well.

Steve: I could see that creating something quite charming about how this process or how talking to customers can help the company. If I’m someone that’s on a product team and I have a group assigned to me who’s my go-to research people but I’m interacting with all kinds of other research groups based on other things that they’re learning, to me it starts to suggest I’m waving my hands to show some kind of network diagram, where stories about how people are using things are flowing in a lot of different directions.

Frances: Yes.

Steve: Because you started off describing something deliberate and structured, but as you are revealing more about how it works, it seems like this multidirectional sharing is I guess I’ll call it a cultural element of how you guys are using insights at Citrix.

Frances: Yes, and I think we have to for a number of reasons. Maps, journey maps are one area that we’ve invested in as well Journey mapping the customer experience and what that means from the onset, for example, of even before they’ve purchased a Citrix product all the way through setup and deployment and then how customers stay on and advocate for products longer than that.

So we’ve taken a look at a very, very broad perspective of not just looking at it from one product line, but what is that customer experience really from start to finish, if there is a finish? That’s become one way to communicate. The intersection of how our products come together, and not just Citrix products but also other technology products that they have to deploy to set that ecosystem up.

Maps and visuals are a great way to do that. The other purpose that that serves, in illustrating and mapping out visually how the products intersect, is that Citrix and a lot of enterprise software is really sophisticated or complex, so to speak. There’s a lot of different moving parts that have to come together to make that work.

For us, coming into user experience or the customer experience group, a lot of us don’t have that technical background that our engineers do or someone who’s a subject matter expert in networking does, where they speak and they code and they write this and they sell this all the time.

One of the things that we’ve had to really focus on and think about is, when a user experience person comes into Citrix, how do we on board them so that they have some level of understanding about the product? That, for example, as researchers we can have a useful conversation with our user base or customers or partners and be able to facilitate the kind of research that we do?

But then, also be able to go back and work with product and engineering and suggest, really help effectively shape, recommendations and product enhancements. We have to have some level of at least conceptual product knowledge, and that’s where visualizing and mapping and journey mapping and diagramming and working with our designers has helped tremendously.

You can read a hundred-page technical write up and whitepaper on how the technology works, but if you can get a designer to map that out, you know that “a picture is a thousand words”? It is so much easier.

Steve: You’re talking now about on-boarding other researchers?

Frances: Yes, I am. But I was also talking about how diagrams and maps become a really important output for our research, but then they also become a communication tool in teaching others about how the products work and how that comes together. Visualizations and visual diagrams take on definitely multi-layered meanings here.

Steve: That’s really interesting. You’ve alluded to a couple different kinds of projects, something more evaluative like usability testing, which I think was tied to a release cycle. Then, you described this looking at workflow, maybe more generative.

Are there other kinds of projects? What’s the overall mix of work that you’re doing look like?

Frances: Right now, we are looking at…We do a mix of generative, evaluative, summative work. At any one point, we might be having projects in any one of those categories, or, depending on where we are on the release cycle, emphasizing one over another.

The generative work, let’s say ideation, a lot of the customer visit work, a lot of the stepping in and let’s just understand the problems base or how our customers use our product in a very broad sense, maybe, for end users, how are they adopting tablets within their organization? What’s their bring your own device policy, for example?

Some of those questions that we explore, there tends to be maybe 20 to 30 percent of our work goes in that bucket. Then, as we move through and work towards release deadlines, there’s a fair amount of evaluative work that has to happen, too. Because, again, when you launch and release an enterprise software product, it’s typically, at least in our case, while we do have some SaaS and Cloud based services, for the install software product, that tends to be a longer product cycle.

Also, a lot of different screens and components that could make up the product itself, so a lot of sub-components. A lot of testing and design enhancements go into that work. There’s a fair amount of work that goes into that piece. That tends to be, at any given point, maybe 60 percent of the work that we do. 50, 60. Then, we’re also looking at, more recently, how do we measure the impact of our releases? How do we measure the user experience and the experience enhancements that we made to the product?

We’re also looking at ways to survey and benchmark based on some of the customer experience dimensions that we would like to be able to measure ourselves on, and ensure that, release over release, we’re actually building and testing a better product. That’s reflected in our customer sentiments, of course.

Steve: Do you have a road map or some plan that says, “Here’s what we’re going to be working on for the next period X in time”?

Frances: We’ll typically look at the year out ahead and coordinate with the release managers, product and engineering to understand what the timelines and the drops are for, let’s say, design lock-down or code lock-down.

If we’re doing release related research work, then we need to work backwards and identify the windows of opportunity that we can do testing, for example, or do earlier research. There’s a stream of research that we do that maps to the product release, and we have input into that checkpoint process, which is great.

But then there’s also a stream of research, and this tends to be the broader themes or bigger pillars that we want to go and address that might span multiple releases. If we want to look at a bigger topic a little bit more in depth, then that can be done in parallel to release research.

We take the opportunity to do both types and make sure that we’re resourcing in both areas so that we’re not just looking at the release ahead, but we’re also looking, like, how can we solve, let’s say, a broader opportunity for our customers or do the necessary generative research and fit that into the timeline?

We have a fair idea year out of what’s coming, but then we also have a closer view of the next couple of quarters, and then we tend to tweak from there.

Steve: How do you think about, within your team, applying resources to the different things that you’re planning for?

Frances: That’s a great question. It comes down to a couple of different factors. Having grown our research team in this area over the, I guess, last year and a half, I’ve done a lot of thinking about this. It comes down to mapping the researcher’s experience level and where they want to focus on in terms of growing their skills to the opportunity.

Where do I see need to maybe dive into a specific skill area, for example. Then, also there’s an aspect of, not just in terms of research methods and techniques and mapping that to the right level and giving folks the opportunity to grow from a research perspective, but also the product knowledge as well.

When I think about aligning folks to the different types of projects, I’m trying to think about, will this expand their level of knowledge about working with customers, getting to know the audience, getting familiar with the technique? But, also, how much product knowledge do they have now, and could this be a way to introduce them to different aspects of the product so that they can take on a bigger and more strategic project the next time around?

As I mentioned before, one of the areas that we want to look at carefully is, how do we get non-technical folks up to speed on a technical product? That comes in a variety of ways. You can certainly do online training and go through courses that we provide to do that. But some of it’s also exposing them to the right project at the right time in a way that they will learn via way of speaking with customers and partners themselves, and picking up on how our products are used in our customers’ organizations.

It’s a mix of probably those two factors. Then, there would be a third, of course, and very important, is aligning it with the business strategy. What’s our strategy and our goal and our mission for the year going to be? How do we make sure that we’re focusing on the right business questions and the projects that line up to that so we can start to move the needle in addressing those questions and accomplishing, as a company, what we’re trying to accomplish?

Steve: You said you’ve been thinking about this for the last year and a half with this team. I’m wondering if you can describe the team’s evolution, or how you think about the kinds of folks and the kinds of skills that you need to have on a team like this.

Frances: When I look at the types of skills that we need, I look for a couple of things. Is there an aptitude, of course, to want to solve complex problems, and really dive deep into a space and work on something that might seem intimidating at first?

Certainly, when I first came here, I remember one of the first conversations I was listening to that a researcher was doing with one of our customers. This person was a Windows IT administrator, and they rattled off so many terms that I had never heard of or not paid attention to.

I know if you’re a Microsoft system administrator, you would know what some of these terms mean, but I didn’t. It took that time to want to be able to go do the extra work to look up what that meant and go ask questions and, again, leverage the folks internally to say, “Please explain this to me. I don’t understand it.”

Why is it important that we’re providing this capability, for example, and what do I need to know and understand about it so I can ask the right questions? But when I look at bringing folks on the team, it is, A: Do they want to solve complex problems, and is that something that interests them?

It’s also, too, I look for critical thinking. Obviously, critical thinking is core to our work. We’re always knee deep in analyzing the data and figuring out what’s going to be our approach to answering the questions, and how do we want to highlight the most relevant insights. Working with the constraints that we might have and trying to figure out, how do you do your best research work within that? Then, too, I’m also looking for folks that have an intuitive sense of data, how data and methods and tools are used.

Sampling, for example. All of these things become really important when you’re trying to identify the right method to use. The right question to answer, number one. Number two, the right method to use. Then, how do you go about doing that? Even if I come across a researcher interviewing for a role that may not require a lot of experience quite yet or may be out of college, I’m still listening for that intuitive sense to know, here are the conclusions that you can draw from this information, and here’s what you can’t conclude.

How they think about the question and how they think about the data becomes really important. Too, along with wanting to solve complex problem spaces, is always looking for that passion. What you might call the fire in the belly is really, really important.

We all want to be doing work that we love to do, and that’s not any different when it comes to research. Having that fire in the belly to go after and go beyond, let’s say, what the scope of the work is, and wanting to push themselves to learn more and be able to share that back with the organization.

That fire in the belly is a little bit more elusive sometimes. It’s sometimes the hardest to find, because it’s really personal and it’s intrinsic to individuals. But then, when you see that motivation and you see someone come in and light up and talk about the work that they do and why they’re energized by it and how excited they were to solve that problem, that becomes really, really valuable.

Because that also is that sustainer for working through more complex problem sets, being able to put in the extra work to make sure that you’re going to get the results and impact from the work that you do. That makes a huge difference.

Steve: I want to reflect back, you said many great things, but one thing that struck me was characterizing a researcher as someone who solves complex problems. I love that definition. It makes me think about people that I meet, and I’m sure you’ve had this experience as well, who are interested in research, but don’t have any experience. But they find it compelling, and they are very interested in growing their skills there.

Usually, people in that stage of their life tell me that they’re curious, they’re interested in people, it’s a hunger for learning and gaining information and observing. I’ve never heard it characterized as solving problems, let alone as solving complex problems. That’s much more of an action word than learning or discovering or understanding. It’s about doing something with it. I love hearing you frame it that way.

It gets me excited about thinking, “What is it that we do?” And checking myself, is that what I do? Am I solving problems? It’s a great frame on it.

Frances: I guess I would say to that, design, and design goes hand in hand with research, is about solving complex problems. Depending on the maturity level of UX in an organization, typically, most companies today have some design function, at least around here. You don’t come across too many companies that do not have that, even in start-ups. The first level is looking at, how can we improve the interface? But as you expand that to think about, how do we improve not just the UI or the screen, but also the product itself?

In our case, documentation and the information experience is as much a critical part of how a user learns and absorbs and manages our product. That becomes really important. Then, beyond that, you can develop and ship a product, but you have to understand how that connection happens to the marketing and education of that product in the first place.

Then, how do you tie those research and insights back into what happens when a customer experience is something unexpected in your product? How do they go about resolving that? Really thinking about that end-to-end experience and journey. When you think about launching a product, there’s so many different factors that contribute to its success, and you have to know where those touch points are within the organization and make sure that your research identifies and is relevant to those groups that might take advantage of that.

What we’re learning about our customers, let’s say, in a usability session or an onsite visit, could be very relevant to our product marketing teams, or maybe how we want to position that on the website. It does become a complex problem, because shipping, especially shipping an enterprise software product, it requires a lot of teams to put that together.

You have to understand how the business operates and how you go to market to understand the value that the research and insights that you’re getting from our customers could benefit so many different areas of the company, and how that entire product experience comes together. It’s complex on different levels, not to mention that it’s very sophisticated technology as well.

Steve: Can you step back a little bit and describe some of the history within Citrix of customer experience, and user research specifically? Because you’re describing a fairly rigorous and big picture view of what everyone is doing together, and I wonder what the history of that is or the genesis of it has been.

Frances: Great question. Research and the history at Citrix is a very fascinating story. Our Senior Vice President, our SVP of Customer Experience, her name is Catherine Courage. She joined the company, I believe it was 2009. She came on as a VP of Design.

At the time, there was a fairly small group of designers and maybe one or two researchers that were working out of our Florida offices. For a couple of years, they had been focused on UI, icon design, a usability test here or there. But she was brought on to expand the role of design within the company, to provide that road map for, how can Citrix bring design to the forefront so that we can differentiate ourselves from competitors and shift the way products are developed so that we’re building better products and we’re building better product experiences around that?

What’s interesting is that Catherine has a research background. Her career early on was doing research, so she intuitively and from experience knew how important that was to developing great products that people love, even if they are more technical. It starts with that deep understanding and empathy of your customers and how they do their work.

She got backing to put a lot of the executives and leadership through Stanford’s, the design, the boot camp. That was very instrumental, because that exposed them to design thinking and the power that that can bring into creating products and services that your customers are going to want to buy and really love.

From there, it cascaded and blew open the doors for everybody. Almost everybody in the organization has either heard about or gone through some level of design thinking workshop and training themselves. I also made the point that it’s not just the product design related folks or product management or engineering or folks that touch product development that have gone through the training.

But it’s actually been pockets of the organization like finance, like facilities, operations, groups that you would never necessarily expect, and other teams that you would never necessarily expect in a company to want to understand and embrace this as a mindset. But that’s been really amazing, because what that did was also bring a design thinking approach to internal projects.

Or, let’s say if you are on the education team and you want to redesign how we deliver video training to folks. Now, that team that might have gone through that training now knows to say, “Hey, let’s start with the users,” and identify what are the pluses and minuses of how it works today, and really understand their needs and go from there.

There’s been a lot of not just product design focus in terms of how we can bring a research and user approach to that, but also other non-product areas as well. That’s led to a cultural mindset shift and changing the DNA of the culture to embrace design, and have folks and teams across the organization have a shared understanding of what that means and even how to practice that.

Steve: If I’m in an organization that doesn’t champion research, as people sometimes say, what would you tell me to take away from the Citrix story that could help me?

Frances: Thinking about how you start with the customer and empathize with the customer first, or user in this case, they may not be our customer. It’s something that, it’s a mindset shift, and that philosophy can be shared and taught with others. If getting research for a particular product or project is not creating the strides that you want, then find ways to introduce the concepts or the approach and that mindset to the folks that may not have bought into that.

For that, there are always projects going on around the organization or maybe some that you’re a part of that maybe you could apply that approach to and say, “Hey, let me help you solve this problem. Let me show you some techniques that I’ve used to think through that problem space.”

Create a workshop or figure out how you can teach the process, as well as maybe help them achieve results through that. The approach, the mindset there is that it was really eye-opening to see that folks across the organization really embraced that. They said, “Wow. Design thinking, I get it. I can interview my counterpart next to me and ask them what challenges do they have going about their day or using their phone. That’s not something that only researchers have to do.” Proving that out in practice and showing by example can be a really powerful way to change somebody’s mind.

Steve: It makes me think of a bigger, more abstract question. What does research do? We’re talking about research, but of course we’re talking about much, much more. You’ve hit on design and culture change and teaching and making products and shipping products. But we’re starting, in this conversation anyway, our ground zero is research. I guess to throw to you, in the big picture, what does research do for a company? What is it? What’s its benefit?

Frances: The first thing that we have to do is really try and understand… put a lot of time and thought into extracting what those key objectives are and helping people understand, when we go to research the problem and find out the problem, we might want to go a little bit broader in scope, for example, and see what we find. There’s that aspect of research that helps shape the direction of how you go about solving the problem.

Then, as researchers, too, we have to be thoughtful about what methods and techniques are we going to select to best get to that answer, and what type of data could best answer that question, or combination of methods and techniques? That’s where, we may collaborate with other non-researchers in that process, of course, and keep them moving along with us, but that’s where the researcher skill comes in and says, “I’m going to try X, Y, Z techniques and maybe make sure that I align with certain parts of the organization for that to come together.”

In a broader sense, that’s part of what we do. Again, the role of research is to, as we’re going out and speaking with our user base or customers, to be sensitive to not just the immediate questions at hand that we’re trying to ultimately address and answer for the business, but also pay attention and listen very closely to what your customer or user is saying.

Because oftentimes, they’ll reveal something that you had never thought to ask. It’s being patient and open and being flexible in some way to get more than what you came in asking for.

When I think our role has a lot to do with curation, we often come back with scores of data or really interesting stories and information about our customers on any given topic. But, yeah, that’s a lot of information for our stake holders and our audience to hear and so we have to be thoughtful about going through that synthesizing the information and really curating it for your audience.

There is definitely a heavy aspect on communications there that, I think, is a large part of what we do. That, I don’t think, maybe… I would say… I don’t remember that being a course in my graduate studies, for example, OK.

I think that’s one of things that when you come into an organization, you get your first few projects or it’s your first job, you immediately find out that, “Hey I learned all these techniques, I can do a usability test and I can launch a survey because I learned it in school or I did it before.” Depending on what you do with that information, what you do with that results makes all the difference. That research can go somewhere, everywhere, or nowhere.

I think one of the things that you have to learn…sometimes the hard way is really kind of how do I make sure that I select, first of all, that identify what the insights are. I think insights are different than findings on some level. Being able to communicate that in a very compelling way that gets your audience’s attention. It is really relevant for them. You have to be thoughtful about, well, I do the scrape work but how I share it with…what I choose to select to let say share with the marketing team might be different than what I share with the engineering team. Or take a different spin or angle on that.

I think as you get in to the details of the work or what customers did or what they were experiencing. your conversation with the designer might be very different than your VP of product development, for example. Being able to be flexible and adaptable to how you think about what’s relevant for your audience is super important. I think…

I think my view of what research does in an organization is…our role is to bring the market and the customer perspective into the business. I know that sounds very broad.

We do that via a number of techniques and approaches, but I think we also have to have alignment and a voice with the other parts of the organization that also have access to customer feedback and data and really think through, “What does this mean from a business intelligence perspective?” A lot of folks within the organization talk to customers, and they have their perspective and approach.

I think we also add something to the mix, too, especially when it comes to interpreting that for let’s say product design, that I think our role is to really inform the business strategy, product development, service development, whatever your company is providing its customers.

I think it becomes really important because, as you and I know, we do research and we talk to customers, and we find out what’s really important to them. If you’re not doing that as part of your business charter strategy, then you certainly run the risk of developing products that don’t ultimately or fully meet customer needs. Then, from there, that could lead to eventual erosion in your market leadership position, for example, or healthy growth over time. I think it’s really important that this becomes a fundamental part of how you market and launch and build products. I don’t know if that makes any sense whatsoever.

Steve: Yeah, it’s wonderful. I like how you ping-ponged back and forth between looking at research as an organizational function and looking at it as an individual’s, almost, a way of being, I think, professionally. You’ve talked about the researcher and the business action of research. You’ve blurred them.

You’ve articulated a lot about both, but I like that your answer encompasses both the individual who brings this thing and then the thing and what it does for the organization. I guess it makes me want to ask you, you as someone who lives the life of a researcher, who brings that to their world and their work.

I wonder if there’s something about you that is your way of being or in your background that just…What do you think makes you great about what you do?

Frances: [laughs] I think it’s the variety of positions and roles that I’ve had in my career and the fact that I’ve worked across a number of industries and domains. Early on, it was not in a UX capacity, at all. Just my own trajectory, I went to art school. I always wanted to go to art school and ended up going and majoring in illustration, getting a BFA, because that’s what I had had my heart set on for years and years, ever since I was in grade school. I did that.

At the end of that four years, I realized, “Well, I don’t exactly want to do illustration. I definitely don’t want to be living paycheck to paycheck as a freelancer.” I think, in some ways, I didn’t know how to pitch and market myself. They definitely did not have any marketing courses as part of the program at the time, except for “Here’s how you put a portfolio together.”

That’s not enough. I think there’s a lot more to the sales and branding aspects that I think I certainly didn’t know back then. Coming out of that, I had actually stepped into the hospitality industry, just by accident. I spent a number of years in hospitality. From there, I went to magazine publications. These were a variety of customer-service-oriented functions.

Also, sales and catering and event planning, and then moving on to publications where I was in marketing roles. Design had always been a siren to me, but I didn’t know where my niche was. I eventually had this calling to come back to say, “I’m going to get back to design in some capacity. I don’t think that I want to be a sales executive for a hotel chain.”

I thought to myself, “How do I get back in design? Let me just figure that out. I think I want to go to business school, as well, because I’ve done so many different types of roles and worked in different types of departments and functions and companies.” That was very interesting to me. I’ve always taken, in some ways, a horizontal approach to the work that I do and really learning and understanding and empathizing with folks across the other teams that you work with. I think that’s probably just how I approach my work, naturally.

Then, I discovered this field. Someone told me about human factors, and I thought, “I’m not sure what that is, but I’ll go check it out.” It seemed to make sense. Now, here was a way that I could apply my “customer service” background and marry that with design. That really led me to quit my job. I went back to graduate school and got a human factors degree and a business degree, as well. That always seemed like the right choice to do.

I thought to myself, “Even if you’re influencing the design of a product, you ultimately can’t do that with understanding how the business functions. How does the business take a product to market in the first place? How do they develop it? How do they sustain that? How do they grow the business? Why is that important?”

Even though you might be working on one product line or an aspect of a product, it doesn’t matter. All of these functions need to happen for the business to be successful and for your product to be successful.

The more you understand and have insight into how those processes and organizations work, I think that becomes really important in your role as a researcher, because now you understand, “Who do I need to go talk to within the organization? Who needs to see the research? What can we do about it, collectively?”

I think that’s really just a product of my approach and growing up in my career and taking on jobs that I thought were really fun and interesting, but weren’t necessarily always on a UX path. I guess, in retrospective, it was.

Steve: That’s a great story. It’s obviously going to continue to be written, as you go on to do other amazing things. Just thinking, looking at our time here, I think we should probably try to wrap up. I wonder if there’s something that I should have asked you about that I didn’t.

Frances: You asked the question, “How do you get leadership support?” I feel like most of the time we already have that leadership support. It’s just a matter of directing it in the right way by checking back with stakeholders, making sure everybody’s aligned with the objectives and opportunities, and we’re doing the right research aligned to the projects.

For the most part there is not a lot of resistance in that way. I was thinking about that question because I thought, “Where have I encountered resistance before in the past? What was my approach and take on it?” I think one of the things that people don’t want to hear sometimes is, “It may not be the right time for your project.”

When I look back on some of those projects where I really wanted to get that research done right at that time, I thought, “This was the right thing to do. We’ve got a product launch coming up. This is the approach that I’ve laid out. We really should do this study first, then this one, and this one, and we are going to put it all together. It’s going to tell a great story. It’s going to answer all your questions.”

I think as researchers we tend to get excited about, “Yes exactly, this is the way to go about it.” Sometimes when you don’t get that funding and support right away, its like, “I knew it was the right thing to do.”

I think what I’ve learned over the years is that sometimes that could actually be a blessing. There really is a right time. Timing is everything. I think one of the responses to that question is that sometimes you just have to be patient. Getting support for your research is not just about your conviction and your timeline for doing that. You really have to understand what the competing priorities are and be sensitive to that, and understand that.

I also think that you want to plant that seed regardless. There will come a time where that research is still relevant and there is still an opportunity to do it. Even if you have to wait a couple of months or a year, if the research need is still there it’s going to be obvious. It’s going to come to a point where others can’t ignore it. That’s usually the right time that you can go in and pitch yet once again.

I’ve also learned over the years that organizations shift. There is a lot of organic growth or projects change, people change in their roles. Sometimes that timing or that confluence of events coming up could really set you up to even more success. Whereas, maybe six months before it just wasn’t the time and you couldn’t get the budget for it. I don’t know if anybody has ever reflected on that before but when I think about…that’s a question for you Steve as you hear about these coming out questions like, “Yeah, we’ll create a better pitch deck,” or something…

I think sometimes you really have to assess what’s going on in the organization. Wait for the right time and also socialize with so many people as you can. Even if you don’t sell it the first time around, at some point, someone’s going to turn around and say, “Hey, it would be great idea if we could do this.” And you are thinking, “Yeah, exactly.” [laughs]

Steve: It’s even better when it comes back, it’s not attributed to you as your idea, someone else recommends it.

Frances: That’s the best. Because that’s when you know you personally pitched it a long time ago or maybe it certainly could have been your idea and you take get the credit for it but actually that’s not the end game. The end game is success – the success of the research and the results and the impact that it has on the product of business. If you’ve got a champion and sponsor that and is willing to put that forth and they think it’s their idea, by all means it’s going to go farther.

Steve: I think it’s time to wrap up. Frances, thanks so much for your time. Your great stories and examples, I think it’s really just super helpful, really interesting stuff for everybody. Thank you again.

Frances: Thank you Steve for the opportunity. This has been really a pleasure to speak with you as always. I look forward to more opportunities for that.

Steve: Great. Thanks again.


About Steve