Megan is the Principal UX Researcher at Trifacta, a software company that helps organizations wrangle data from multiple sources. She’s consulted and worked at a variety of organizations in different research capacities, some of which required her to learn how to build research as a function from the ground up. Megan recently spoke to us about her experiences while sharing plenty of tips for teams looking to scale research. Let’s dive in:

Sofia: Why don't we start with what you do and what companies you’ve worked for?

Megan: I have always been interested in the intersection of people and technology: how technology can help people, how it can hurt people. In undergrad, I double-majored in political science and computer science, which everyone thought was nuts at the time. But for me, technology was always idealistically a tool to empower people. I strongly considered getting a PhD in political science and focusing on innovation and technology in the military, but I realized I didn't want to be a professor, or at least I didn't want to deal with a lot of the stuff that comes with academia. So I ended up working at a tech company, doing internal product management—that was EMC Dell.

I also worked for a government R&D company for a while, which was incredible. They have some downsides, from an ethical perspective, but they are often on the cutting edge of HCI and human factors and ergonomics research. I got a lot of great experience there, with rigorously thinking through things, working with different kinds of stakeholders, having a big impact, all sorts of fun stuff like that.

Then, as I started considering my next steps from that job, I knew I would be doing a lot of user research-y type things, user acceptance testing, requirements, all that fun stuff. That was something I had an interest in, like HCI and the more human-focused side of computing. So I did some exploration and eventually ended up going back to grad school.

I focused on social science methodology. My degree is technically in environmental conservation, which is something I'm passionate about. One thing that motivates my research is seeing an impact in the real world. The environment is certainly something I care about deeply, so it's not surprising that that was the area I focused on for a while.

While I was in grad school, I started consulting on the side, particularly for startups, and eventually moved out to San Francisco. I was consulting for startups and I specialized in getting people up off the ground and teaching them how to do good UX, product strategy, and good research.

Then I worked at Salesforce for a bit as the head of research in their industry group, which is a set of products that are aligned around industries. They hired me because of my startup expertise—the products were relatively new and they were doing new things in terms of Salesforce's strategy. I worked on their survey product, which I think is now actually integrated into all of Salesforce. I worked on the healthcare product, the financial services product, also retail. That gave me a lot of exposure to a lot of different people. I had the opportunity to interview CEOs and CIOs of Fortune 500 companies. I think that’s the point when I started specializing on the enterprise side.

And now I work for Trifacta; I run research here. We're a data company focused on data preparation and data exploration. I sit on the product team and work with UX and product, but pretty much work with everyone in the company at this point.

Sofia: Can you tell us about the structure of the product team and your first research when you started at Trifacta, and how you're going about it?

Megan: The product team reports to the VP of Product and she runs both the UX team and the product managers. I also report directly to her. There is a UX director who has three or four designers. The PMs each report directly to that VP, although there's some hierarchy in the PMs now, and we're hiring three more. We actually need a lot more capacity on our product management side. And then there's myself. I have an intern, a graduate student at UC Irvine, and she is amazing.

When I started, I had to do things not only to educate people about what research is, but also build a culture around listening to customers and thinking of it as a requirement for any product development process. I also have had to choose what tools we need as well as design scripts and templates for others. I've often found that I’m enabling other people to do research too, particularly since I’ve often been the only researcher. You need to give them the tools to do research well, because most people are not formally trained in research.

I was also trying to understand the culture of the company and customize all of the strategy around that. Because it turns out that something that works for one company is not going to always work for a different organization. There are lots of discussions with large numbers of stakeholders, really pretty much all the way from the executive team down to support. It requires a lot of engagement.

I also essentially do internal research to improve our processes. Earlier this year, I ended up doing a project where I was “researching research”, to figure out what our needs were, what gaps people thought we had, how I can serve them better, which I think was actually the best way to go about it. Because if you're just giving people things without listening to them, it's not gonna work.

Sofia: You started with this idea of doing research on the research that people needed in general. Did you have a strategy or vision of what you specifically wanted to achieve in this company?

Megan: One of the big things that I realized early on was that we didn't have shared understanding of our users. I think that's still an ongoing problem and probably motivates much of the work that I'm doing... trying to get a widespread understanding of our users and encourage the whole company to empathize. It’s also critical for us to use the same language when we talk about our users. You might talk to one person and then another person, even on the same team, and they think about our users in very, very different ways.

So I've been doing a lot to get us to that baseline shared understanding. If you don't have it, it's almost impossible to engage in research. For example, when you reach out to Customer Success and say, "I want to talk to users with these problems or users of this type," if you don't have that shared understanding, you're gonna get different responses. People are not going to be engaged.

One of the first big projects I ended up doing was around personas, which ended up being wildly successful, way more successful than I thought, which, I guess, backed up my hypothesis that we needed more understanding of our users. They're used in public marketing materials, in sales pitches. The product team now refers to our personas frequently. I have mixed feelings about personas, but as a tool to get people on the same general page, I think they can be useful.

Sofia: So you're doing personas and realizing that they’re valuable, people can use them as artifacts to get their understanding. What challenges did you face in that process as a researcher, and also as a person trying to build a general function and understanding of research in the company?

Megan: I think it ended up being a good project to uncover some of the gaps, but the persona work ended up being delivered very quickly. I've gotten to the point where I can do that kind of stuff very rapidly and using existing materials. I didn't have a lot of time to go out and do new persona interviews. So one of the things that I uncovered was that all of the information we had was in about 5,000 different places and formats. There's no shared or standard way of recording a use case or even talking to users and collecting information about them. So when I was putting together the personas, it was tough because I didn't even know where to look.

One realization that has become a big initiative across the company, is that we need to be more rigorous and more centralized about storing the information we have about our customers and users. I did a wide range of things, including putting together the world's largest spreadsheet with every possible dimension about our customers. We didn't end up using it, but a lot of the fields ended up getting imported into Salesforce. I started trying to create templates and also work with other teams to get them to collect the data because I'm not always the one in front of a user.

In the end, we realized we needed a better user research repository, which led us to EnjoyHQ. It took a little while to get there—it wasn't overnight. We played with a lot of different things. When you're dealing with so many different stakeholders, and so many other people who are not researchers are doing research, it becomes so fragmented that the knowledge just needs to be centralized somehow. Otherwise, it doesn't even get shared.

Sofia: Can you talk a little bit about why you think empowering anybody in the organization to do research is a good strategy? And what are some typical mistakes that they make when they do that research, so other people can learn how you deal with those issues?

Megan: It's certainly an ongoing process. I'm still learning more about it every single day. But I think it's an important strategy because the blunt truth is that you never have enough trained researchers. A lot of places are lucky to have any researcher, much less more than one. Given how critical understanding your customers is to the success of a product, and I fully believe that is true, if a dedicated researcher can't do it, then somebody needs to do it. Additionally, if people gain more empathy by doing the research themselves and interacting with users and customers more, that will benefit the product as well.

So it's a combination of resource capacity but also direct empathy, because there isn't anything that can replace interacting with users and seeing what their problems are. Having the people who are actually building the product—PMs who are prioritizing features, engineers who are implementing solutions—having them involved in the process and more educated about users improves everything across the board.

Also that means, as a researcher, I can prioritize the projects that are going to benefit most from my depth of skill.  I'm happy to do usability testing and individual feature level stuff, but I end up prioritizing projects that are more strategic because I have more bandwidth to do so.

As for non-researchers doing research, one of the biggest issues is people going in with assumptions about what a solution is, particularly if they've investigated the problem and have been listening to it for years. Some of our PMs have been in the industry for years, so they're very familiar with the domain space. Going into a user session or interacting with users without humility they might think they know their problems already, which essentially contextualizes the entire conversation. They might not ask deep enough questions or might lead the conversation in a particular way. It’s much more challenging to step back and just listen when you have another agenda. This is why I'm a big fan of open-ended interviews.

One way I deal with that is to sit in on sessions with PMs and give them advice after the fact. I think that has helped and started to get them out of their heads. Coming up with questions and goals ahead of time, reviewing them and asking them to step back a little bit. Doing a consultative/collaborative process around what they're going to do ends up being a really useful tool.

I also encourage them to not stick to a script. I know people are big fans of scripts for interviews, but I try to teach them to go deeper, ask why, have topics in mind, but not necessarily exactly an A, B, C, D script to go through.

Another issue with non-researchers doing research is what I would categorize as the impact of research. Particularly in a startup, unsurprisingly, we have a million things to work on and it's difficult when you have conflicting priorities from sales, from customer success, and from actual users themselves. Our team has struggled with where we rank user feedback compared to, say, the head of sales telling us he needs this feature to close a deal. That is a huge issue.

Some of this comes down to the strategic vision of the company. Some of it even comes down to the approach and humility of the people making the decisions. This is one that's a little harder to shift, if you're a researcher. A lot of it comes from culture. It comes from individual humility. It comes from a willingness to test your assumptions, even if that makes you uncomfortable. I don't think this one has an easy solution, unfortunately.

Sofia: Implementing change and driving the change process isn’t easy. You get a lot of backlash and people not wanting to cooperate because you're changing the way they’ve been working. How do you deal with difficult conversations?

Megan: I do have a lot of tough conversations. My job is not always easy and the parts that are difficult are usually not the research parts: they're the politics and culture change. So you're spot on in identifying that as one of my biggest challenges. I'll get into the details of how to do that in an organization, but I think personally, the way I deal with tough conversations, is, A, to have work-life balance; and, B, mindfulness and feeling joyful. Because I found that, if I’m emotionally invested in an outcome or those difficult conversations are tied to my emotions, I am really affected by it—I essentially feel shitty all the time. It’s one of the downsides of having a strong empathy muscle.

If I have healthy habits and I'm eating good food and I'm meditating and working out, those kinds of things make me more resilient to doing difficult stuff at work. I am absolutely better at my job when I'm feeling well and centered.

And then the other part is empathy, which is such a big buzzword. In this case, it really is trying to understand the other person's perspective. You might not agree with it. Empathy doesn't mean you have to agree with something. You try to understand their perspective, why they're doing what they're doing, but you don't have to like it. Empathy doesn't mean you have to like something.

But understanding someone else means you're able to connect with them more. And the reality is that other people have values that are different from mine, particularly someone like an executive who has sales targets. I care about business impact, but at the end of the day, I measure my value by improving users’ lives.  So, I try to find a way to meet in the middle and reframe what I'm working on so that they’ll benefit the other person who has different goals than I do.

Another example: I'm not a super linear thinker. That's been a challenge in working with people who are much more like, "Give me point A. Give me point B. I need a schedule from A to Z." So I have to think, "All right, how do I get my point across in their language?" They're much more likely to be receptive than if I stay in my little box and do things my way.

Lastly, allies are incredibly important. People who you can just vent to or learn from or say, "You know, I have this problem. Do you have any ideas about how I can solve it?" Having internal allies who are on the same page as you—or even not: sometimes it's good to have an ally who has very different ideas—that helps you through the difficult moments. They know what you're going through because they're going through the same thing.

Those are probably my main techniques for dealing with the difficult stuff, and you’ve probably noticed that none of it’s a research skill that you get trained on in graduate school.

Learn how EnjoyHQ can help you centralize, organize and share research insights easily with the entire organization. Start a Free trial today here 👉 14-Day Free Trial