#146 - Building a UX Research Team From Scratch with Julian Della Mattia of the180
E146

#146 - Building a UX Research Team From Scratch with Julian Della Mattia of the180

Julian Della Mattia [00:00:00]:
The key tip to success is to really, and this is a research project in itself, really understand the context and your team really deeply. And I talk about, okay, asking the right questions during the interview process, like asking the right questions during the onboarding. So understanding where you stand and also understanding where you want to go to is definitely going to set you up for success. Because if you don't ask, especially when you start, if you don't ask the right questions and you don't understand where you're going, you can then start building many things, but then you just build a rocket that then sits in your garage. So probably the understanding bit is something a lot of people overlook and they just chow. Yeah, because they're excited, because they want to prove their value, because they want to have impact right away sometimes. I mean, there are many, many reasons why this can happen, but really, really spending time understanding everything when you join a company as a first researcher is the way to go.

Erin May [00:00:51]:
Hey, this is Erin May.

Carol Guest [00:00:53]:
And this is Carol Guest.

Erin May [00:00:54]:
And this is awkward silences.

Carol Guest [00:00:58]:
Awkward silences is brought to you by.

Erin May [00:01:00]:
User interviews, the fastest way to recruit targeted, high quality participants for any kind of research. Well, Ben, it was great to have you on. First of all, thanks for having me.

Ben Wiedmaier [00:01:15]:
Yes.

Erin May [00:01:18]:
But great to have Julian, our guest as well, and talk about starting a research team from scratch, which I think is something a lot of people, certainly working in startups, have had the opportunity to do or maybe are interested in doing in the future and can be really intimidating. So great to kind of talk through a framework for how to think about it and the things you might want to think about knowing. Of course, the approach is going to vary a lot depending on the situation you're entering.

Julian Della Mattia [00:01:43]:
Yeah.

Ben Wiedmaier [00:01:44]:
And I think for folks who might even find themselves at big enterprises, it can sometimes feel like you're a team of one if you're very, you know, spread out or dispersed globally or internationally or if it's very siloed. I think a lot of the things that Julian talks about in this episode you can apply to your team, even if you're not yet a team of one. Really great strategies around building bridges, engaging stakeholders. He has a nice breakdown between insight hubs and repositories. I love when, when someone's got a specific definition for those sorts of things because it, again, helps turn these things we hear so much about into, like, practical to do list items for folks.

Erin May [00:02:18]:
Awesome. All right, let's give it a listen. Hello, everybody, and welcome back to awkward silences. Today we're here with Julian della Matilla he's the reop specialist at the 180 and a senior UX researcher at Meister. Today we're going to be talking about something that I'm pretty sure is relevant to most of you or has been in your career or will be in the future. And that is building research teams from scratch. So lots to cover here. Julian, thanks for joining us.

Julian Della Mattia [00:02:51]:
Thanks for having me. My pleasure.

Erin May [00:02:53]:
And we've got Ben here, too.

Ben Wiedmaier [00:02:54]:
Hey, everybody.

Erin May [00:02:55]:
Awesome. All right, so you've done this multiple times. So you know what you're talking about. That is building a research practice, research ops from scratch. We're going to get into a lot of detail, but just kind of starting off, what's a good approach to even think about how to get started for people who find themselves in this boat?

Julian Della Mattia [00:03:12]:
Well, probably the first thing I would say is you need to approach it with the right mindset. And for me, or the way I perceive the first researcher should be, I was using sport analogy here. So it's, instead of being a striker or someone who wants to score, you need to be kind of a playmaker. You need to change the way you approach research. And the reason I use this analogy is because many researchers, when they're the first one, they think, okay, fine, I need to jump straight to hands on work. I need to tackle projects. I need to then do stuff. Sometimes it's the case because maybe the company hire you because they had a pile of projects they needed to work on.

Julian Della Mattia [00:03:49]:
But if you just focus on the hands on work, you might be missing out on the opportunity to actually work on setting up the practice and actually, you know, alleviating your work down the road. Plus, when you are the only researcher, it's just you, right? So you need to, then there's probably a lot of requests around or a lot of research happening. Sometimes, like, let's say the traditional research or what a researcher would consider research or formal research or maybe not to the standard, but there's probably some, something's happening. You have probably a team, like trying to do a survey or some people talking to customers. And when you come in, it's important to try to instead of absorb all that saying, okay, fine. How can I, as the first researcher, help that become better? How can I help the rest of the team step up their game? That's why I usually use the playmaker analogy. Okay, fine. I have some teammates.

Julian Della Mattia [00:04:43]:
I need to help them play better. I have to organize the player. I can help them overall learn better and perform some research better. So the first thing I would advise is this little mindset shift? You know, the. Being the first researcher is a very special type of challenge, so to say.

Erin May [00:05:00]:
Right. So being the only researcher, the first one there, you're going to have to score some goals, but you're not going to do research alone. And you want to be setting your future self up for success, but also working with the team to make great things happen.

Julian Della Mattia [00:05:15]:
Yeah, exactly. Exactly. I mean, of course with what I'm saying, I'm not saying, okay, you should not conduct any hands on work or not research. Of course not. There's probably part of your time that will be dedicated to that. And that's great because you also need to score some goals and show some victories here and also some wins that you can show the team, okay, this is how research works, or can work or could work, and this is the value research can deliver. So you, of course, need to do that bit. But sometimes folks kind of get lost in this part and then they don't work on the rest.

Julian Della Mattia [00:05:46]:
And the rest has many. It's a wide space. It's just building the practice, building the knowledge, the culture, understanding how other people interact with research, setting up, for example, participant management. So it's a little bit of, as you said at the beginning, it's a little bit of operations and research itself. So it's kind of like you have to wear many hats as a first researcher. So there's definitely. Yeah, what you said, this is a bit of both scoring a goals and helping the team play.

Erin May [00:06:14]:
So how do you recommend you've got the right mindset? Right. So that's good. That's always essential. How do you get started? Prioritization is always going to be a priority in business for anybody, but particularly when you're one person, it's very, very important. So how do you think about the different vectors of prioritization? About I'm stepping into this kind of organization which is different than this kind of organization. Where do I use my time best? Say that 1st, 30, 60, 90 days or to get started for success.

Julian Della Mattia [00:06:44]:
Okay. The first piece of homework actually starts during the interview process when you're interviewing for this role. So really, really, before you ever sign a contract, you should kind of ask the right questions so you know exactly where you're walking into and what's, what's the challenge, what's the company like? How are people understanding or thinking of research? What do they want to learn, what are their priorities and so on. So probably, since it's the interview process, you probably don't have won't be able to know most of the things because, I mean, you're still not part of the team, but you can assess more or less what kind of flavor of a challenge you're dealing with. That's the first bit, because then when you join, I'm going to say something very researchy, which is it depends. Some organizations have the first bit that influence. That is, okay, are you being hired or broadened by design lead or a research lead or a vp of product? How large is the organization? It changes a lot. So there are many reasons why they could bring in a researcher.

Julian Della Mattia [00:07:39]:
So that's the first thing to consider. And when you come in and you have to prioritize, again, it depends on what the company is facing at. Maybe they hired a researcher because they had many things they wanted to learn and they have many big projects upcoming or many big ideas. And, okay, we want to, you know, make better decisions in this way, or maybe they hire researcher because it was trendy to hire one. You know, you can have both worlds, both ends. So within, let's imagine, okay, they bring you in and they know more or less you have a couple of allies that know what research is and how research work. I normally try to separate the hands on research work versus the operational work, and I try to a lot capacity for both. Maybe when you're starting out, probably you won't have like 50 50.

Julian Della Mattia [00:08:30]:
Sometimes you have maybe one quarter focus more on operational side and maybe another one more on hands on work. But I try to make space for both. And from the hands on perspective, maybe you have some projects that are waiting for you. That's why I said it's important if they bring you for something or maybe when you're talking to people, you can really quickly understand or gosh, okay, this is what they're looking for. This is what they need now. So you can tackle those right away. And of course, you always prioritize based on company objectives and what they're trying to achieve and potential impact and so on. Of course you don't want to.

Julian Della Mattia [00:09:03]:
Sometimes if the buy in research has is really low, you can go and tackle that usability testing that doesn't sound so appealing. But sometimes, you know, okay, if you have many things that you could pick, maybe you go for stuff that has a little bit more juice and that's more potential in the company's strategy or the company objectives or what they want to achieve. And then the operational bit, I always try to assess where we stand in that regard, what are the things that we can improve so we can map up, for example, the research process and find some potential pain points there by also talking to people to understand how, if there's any research being conducted. What kind of research, how, what are some, like our teams maybe doing differently? Because maybe you can map, okay, the design team is doing this now, but maybe, I don't know. Customer success is also talking to customers in a different way with a completely different tool set or so accessing that is one bit. And then once you have first understanding of where do you stand in terms of operation, then I always try to chunk stuff into smaller pieces so you can tackle them bit by bit. And what do I mean with this? Sometimes when you want to work on something that is operations, it might be a large project that involves many parties. Many of these things maybe take time.

Julian Della Mattia [00:10:19]:
So you need to allot some capacity and then do step one and then next quarter, maybe do step two. And then, so you start because maybe, and I can give an example of this, for example, building a participant panel is a common thing. It's a common topic in operations, right. And yeah, you have many, many steps you need to do. You need to probably set up your terms and conditions. And we set up the mailing list, maybe even a landing page. So these are many steps. And then you also need people to sign up.

Julian Della Mattia [00:10:49]:
So it's not so straightforward. It's okay. Find this. It also depends on many teams. Maybe the mailing tool lies or sits under CRM, so you need to then have different stakeholders. So doing this into chopping this into smaller pieces helps you fit it better when you have to prioritize work. So it's okay. Fine.

Julian Della Mattia [00:11:09]:
Now we just work on the tnCs, this queue, because I also have all these research projects here. Then next queue, I go this way. So you also make time and space for that to happen.

Ben Wiedmaier [00:11:18]:
Julian, I'm struck by how for some companies, when they hire their first researcher, they might also only have a handful of engineers and maybe one product manager silos, as we think about them at a larger.org might not have been established. You hear from research operations and user researchers that they're combating some of those silos when they try to get their insights actioned or buy and budget. Do you think that you being a UXR, if one has an opportunity to build bridges with your partners and stakeholders? I mean, I know that's a key thing of what we'll probably talk about later with research shops, but I guess at a high level, how do you think about building those bridges when you've been brought in as a researcher of one on a team. When you're asking about those projects that the PM's want to work on, are you also taking a moment to say, and here is how I'm going to, you know, work against that problem and why, like, are you taking those moments for education? How are you making it, I guess a team sport?

Julian Della Mattia [00:12:18]:
That's, that's a really good question and I think it's not a question of, okay, how should you start? It's actually your only choice, to be honest. Got it. You need to build those bridges. And I also want to make a little, a little note here. Sometimes you are the first researcher and then you're meant to scale the team. So you're the first one to step in and then, okay, fine, you will be the first of 5670, who knows? But sometimes it's not just, you're not only the first, but you will be the only one. And that's a little, it's a little different. And that's why I say that building these bridges is actually key.

Julian Della Mattia [00:12:52]:
So the way, and going back to this, we can change the playmaker to a connector if you want. Basically you need to also help connect the knowledge of all teams and help teams learn better. Because I think learning about the user, the problem space, the market is something that, yeah, we can be the specialist and of course there may be also market researchers, we can be the ones taking the lead on this. But I think that overall learning as a company would make the whole company make better decisions and therefore make better products in the long run. So if you start talking about how this starts with the decisions that you need to make and what are the things you need to decide on, how can you be sure? You're never 100% sure, but how can you reduce, you know, the, how can you make your certainty increase to certain extent that you can make better or like more solid decisions? When you start putting this in motion and you talk to people and you explain it this way, you know, it doesn't happen overnight. It's not that you just do a project and this is how it works, but, you know, you need to slowly start building that in a case when you are like, you have 01:00 p.m. And engineers. I think one key thing here, and I go back to when you just start as researcher, when you land, I think the onboarding bit, you know, the first 30 days are a golden opportunity for researchers.

Julian Della Mattia [00:14:08]:
Well, mostly you have a golden opportunity for other roles too, but now we're talking about just researchers. So when you just arrive, you have this aura, and you can get away with asking stupid questions if you want. And you get to talk to a lot of people, you meet a lot of people, and you can ask them, okay, what do you think about research? You have experience with research. Why did you make this decision? What do you base your decisions on? All these things? And I think that understanding this while onboarding is great because this will then guide you or serve as a roadmap. This is how we need to approach this. So to build this culture, you need to start, okay, you need to understand where you stand as a team or as a company overall, what does a company and the team stand in terms of research? How do they perceive it? What are their doubts? What are their concerns? Do they trust research? Will they come later on and say, you only talk to two users? Maybe this kind of questions, one, two. I would even question two, I mean, to five or ten, you know, but yeah, this is something that, building these bridges is something that is key for your success.

Erin May [00:15:14]:
So, Julian, I hear you saying, regardless if you were a first and maybe last researcher in your organization or the first of many, building these bridges is going to be essential to your success. And before you even join an organization, you want to kind of start with, well, a, is this an organization I want to join for whatever reasons might be on your list, but what kind of business problems can I help solve right away once I get started? And then you're going to kind of continue understanding that once you do get started, in part through these stakeholder conversations, which includes not only further understanding that kind of business problem situation, but also on a meta level, where are we with research? What research is happening, what's working about it or not? What's the op situation? Is everything a mess, or is it already sort of organized for what it is? And then you can kind of move forward. It sounds down really two paths, one on the op side and one on the execution of research side, and then we get into prioritizing. And you talked a little bit about this, but maybe we could talk a little bit more about how you think about is it 50 50, 60 40, and how that might change over time in your organization.

Julian Della Mattia [00:16:28]:
That's a great summary of what we discussed so far. Yeah. In terms of prioritizing ops versus hands on research, the first conversation you need to have is with leadership. Okay. What are plans in the future? Because it changes really a lot if you are building a team and you are just the first one, and you then need to onboard five researchers first of all, what are the hiring plans? Because if we say, fine, I join in January and then we will hire four researchers in April, maybe that's going to really change my roadmap in terms of hands on work versus operations unless we just go with it and see how it goes. But it's not really a good idea when you have to build infrastructure for all those researchers first, probably talking to your manager or senior management, depends on how your organization on your chart, basically how many levels you have, but the highest you can go and say, what are the plans for research was the budget? And so assess a little bit, what's the overarching idea? Then also asking for the research side, what are the company priorities now? What are the plans? Maybe the business wants to go or the product, where we take in the product in the upcoming horizon or even year. So assessing that and working backwards from that can also help you. Okay, these are the things we need to actually find out.

Julian Della Mattia [00:17:48]:
And it comes back to decisions. What are the key decisions that you need to make? This queue, next queue. This h one, h two. So you can have this conversation. And then from there, see, okay, these are the things that are a must. These are the things that maybe are not so relevant. And then you can then start balancing. And when you have both and you know both, you can then see, okay, fine, you need to work considering time.

Julian Della Mattia [00:18:10]:
I said there are some things that will take time to build if you need to build, if you need to set up participant management. And one of the things is building a panel. I'm coming back to the panel again, but it's a really useful example for all these things. It will take six months to maybe even eight or nine to have it filled and working. So you start early on some of the steps and you let it then grow like a plant. You water it a little bit every queue and then it grows. So you also need to play with time. So what do you need to get from here till h one, h two and then work backwards from there.

Julian Della Mattia [00:18:42]:
So connecting both sides, plans and company.

Erin May [00:18:44]:
Objectives awkward interruption this episode of Awkward Silences, like every episode of Awkward Silences is brought to you by user interviews.

Carol Guest [00:18:53]:
We know that finding participants for research is hard. User interviews is the fastest way to recruit targeted, high quality participants for any kind of research. We're not a testing platform. Instead, we're fully focused on making sure you can get just in time insights for your product development, business strategy, marketing and more.

Erin May [00:19:11]:
Go to userinterviews.com awkward. To get your first three participants free.

Ben Wiedmaier [00:19:16]:
Julian, you've mentioned now panels twice, and I hope we can dig in a bit more as to why you think participant panels are really useful for smaller, scrappier teams. You're talking about a lot of different things. Again, as any startup or early stage company, the employees are balancing roadmap strategies, trying to figure out if they'll get budget for another year. And researchers no doubt are balancing all those things, too. In your experience, though, is there a system or a process or something that teams have won or small research teams ought to be building or should be building at the outset, but they often don't because of time. Is there something that they could be doing in those early stages that will really pay dividends if and when they get, you know, they get more budget or their team grows or they're given a big meaty project? What, from your experience, are some of the things that you would encourage folks to think about building as they're, you know, again, building the rocket, flying the rocket, figuring out how to buy fuel for the rocket, etcetera?

Julian Della Mattia [00:20:13]:
Probably the thing that I would say is really worth investing time and effort in is connecting insights from across teams. Participant panel is also something useful. A repository is something useful, but this is a little, this is something that actually exists and is connected to the capacity you have as a resource team of one or as a sole researcher. You know, as researchers, we are, you know, finders. We dig out. Let's say we find information we dig out, but at some point we are really limited to the capacity we have and the hours we have. But we are not the only ones talking to customers. We're not the only customer facing team.

Julian Della Mattia [00:20:51]:
There are other teams. They're really a goldmine. If you have customer support, customer success, sales data, there's so many touch points that you can actually have or take insights out of. And also they could also use, because sometimes we go back to the silos, sometimes they're not connected. So maybe sales doesn't know what customer success know and they don't know what research is doing and they don't know what product actually plans on launching. So maybe they're not connected. So connecting or creating an infrastructure to connect all this is going to make a big difference. It won't be easy because you need to get everybody on the same page and explain why we're doing this.

Julian Della Mattia [00:21:28]:
Why are we collecting information in one place? So it's a little bit of a tough sell, but once you get the buy in, it really makes a lot of difference because you start building channels to make your understanding and your learning better. We go back to what the goal, I mean, in my perspective, where research should be about is learning better, understanding the user, the problem space and the market better so we can make better decisions. So then from there we can then find different channels and we can say, okay, fine, we do more work ourselves, but if you want to do it at teamsporas, you want to make the most because there are many people talking to customers. So if you want to make the most out of that and you want to make your insights juicier, you want to triangulate and you want to have different sources. So creating these streams can really make a difference. And this is something I would encourage people to start talking about from the start, from the get go.

Erin May [00:22:20]:
Julian, it sounds like that could be its own episode easily. But maybe we could talk just a little bit about how to start to tackle this question of connecting those dots across organizations. Cause it is a juicy meaty topic and I'm sure one a lot of people are thinking through, whether they're on small or large teams. But any quick tips there to help people execute on connecting those dots?

Julian Della Mattia [00:22:43]:
Okay, the first thing that I will say, it needs a lot of conversations and it needs a lot of politics too. This is the, probably the unhappy part is, okay, fine, we need to, sometimes you need to do what you need to do. So the first step is to identify and map which are the customer facing teams or the teams that could produce some sort of findings, insights, you name it. So understanding who they are and who are the points of contact and then having individual conversations with each team and explaining, ok, this is what I want to do. This is what I need to build. The reason is this, because I want to create this, this common understanding and kind of overhaul the knowledge finding and the curation of knowledge. I want to be the curator of knowledge and then understanding what kind of information they can provide, what kind of information they would need and the frequency so the cadence, if you want. So for example, you go and you talk to customer success and say, okay, fine, tell me a little bit about how you talk to customers, how often, what kind of content, what kind of questions do you ask? For example, do you go over support tickets and you create a report every month, every to weeks, and then you can probably go, okay, they do a re because most teams do find they do voice of customer, they do voice of or cs something.

Julian Della Mattia [00:24:04]:
So they always have their reports. Sometimes it's monthly, sometimes it's quarterly. So you can probably say, okay, fine, this is fine. If we do it once a month, it's okay. And then you ask them, because this is a two way street. So if you want to create a process that collects insights, not only teams need to provide those insights, you also need to give them something because they usually say, what's in it for me? And that's the reason why silos exists. Okay, fine, I do my job. I put the report on slack or I send a newsletter and that's it.

Julian Della Mattia [00:24:34]:
And what's in it for them? And, okay, what are the insights they could use, for example? And one clear example of this is sometimes sales doesn't know exactly what happens in the product world. Now, for example. So if you can then start connecting both ends, they could say, okay, fine, we can give you all the reasons why we win or we lose deals, customers, we're losing leads because we don't have this, or because we're lacking this, or because we're losing to this competitor, or we won because we're really good at this. It's like, fine, can you give me that every month? And then you can also connect. And then you go to product and say, how can you give me visibility on the product world map? And so you start connecting all this. So basically the conversation was also around three points. What can you give me, what do you need and how often can you give me? And how often do you need? So four, actually. And then you can start building everything.

Julian Della Mattia [00:25:26]:
Probably you won't be able to bring everybody on board because then you will have an avalanche of insights from all teams. So start with the teams that you have that you probably build the relationship the earliest or that are keen on doing this. So try to find those allies. And then once you have two, three teams on board in this process, then it's easy to showcase to do that. Look, with customer support or success and sales and product. We're doing this little thing here, so look at how we benefit from. Look at our insights are triangulated now so you can mark this game from support and we connected it with this research insight and then people will actually come on board. It takes time, but it's super effective in the long run.

Erin May [00:26:10]:
Julian, so I hear you saying you're kind of facilitating in this role the communication of insights learnings across these different departments, which might involve a repository down the line or different meetings or reports. I'm sure this could take many different forms. Hopefully it becomes a little more, if not automated, routine over time. How this is all working, where does user research fit into this and projects that you're running as a team of one or more and surfacing and bringing those insights to these teams. Is that part of the same system or do you think of that separately?

Julian Della Mattia [00:26:45]:
No, that's definitely part of that system. And that also helps give usability to your work without going to each team and say, yeah, this is what we found out. So one example, you can build this. I'm really very, very basic. You can go on Miro or you can go to Figjam and you can create a board and you can ask teams to pull stuff there. You can have a separate detection for UX research and then they can also see, okay, for example, these are the insights that we got from this set of interviews, 15 interviews for this project. You have them there. I think it's another source and it's another channel of another customer facing team.

Julian Della Mattia [00:27:20]:
So I don't think it has something different. The only difference maybe for me, is I start from there to connect the insights. I start from the insights that I got and then I look for other things to triangulate maybe, and the other way around when I maybe want to suggest proactively a research project. So I go and check the other way around. Okay, fine. What happened in other teams? Is there something here? Can I spot a trend or can I spot something like a thread that I could pull? Okay. And then I go and research about that. So it goes two ways, but for me it's either the end or the start.

Julian Della Mattia [00:27:51]:
That's the only difference. But I'm the researcher, so of course that's my take. But yeah, it's definitely another source. Yeah.

Ben Wiedmaier [00:27:59]:
And Julian, I'm in prepping for our conversation. I was looking at some of your other writing and you write a lot about repositories and I'm glad that Aaron mentioned it because it sounds like throughout this conversation you've been talking both about the raising of awareness, the education around research, but a lot of what you're describing, at least now check me here. I hear in, you know, sometimes we call them insights hubs or sometimes participant panels can have these repository effects, but you have written about research repositories. So I'm wondering if you could connect, if there is a connection. The things you're talking about were in identifying priorities, linking insights that you found to other teams question points. Could a research repository or an insight hub do that? And if so, how does a small team or a team of one go about building that? How have you linked those things in a centralized way? Because again, I'm hearing from a lot of even senior researchers that that's what they spend a lot of their time working on. We have great projects happening and no one knows about them. So you're talking a lot about visibility, transparency and those bridges.

Ben Wiedmaier [00:28:58]:
To what extent does a repository help you in that?

Julian Della Mattia [00:29:02]:
Repositories are either very related to this or could be a completely different thing. So it depends how you want to, it depends on your context and depends on overall how the team works. Sometimes I like to keep them separate. I prefer for example a research repository where I can go deeper and then it would be for the research team and then have this insight hub just for the other teams. Then we can have two separate processes depending on how the company said. And if you have maybe for example designers, product managers and other people conducting some sort of research, then this inside hub could also become some sort of repository if you want.

Ben Wiedmaier [00:29:42]:
So I guess how would you define each of those things? Because it sounds like they have different functions. So how do you define a research repository and then how do you define an insights hub? And is one of those more relevant to the work you're describing as like a UXr of one? These early stage moments?

Julian Della Mattia [00:29:58]:
Okay, the inside hub for me it moves faster and it moves like, it's like, it's like imagine like a river or like a lake. We have different streams from different rivers. A repository is more like a well if you want. So it's somehow similar because you need to put water there and it comes probably from one stream but it's a little, it's a standalone thing. You know, I think that repository is the way also they're, they're constructing many teams sometimes leads to its own failure. That's another point. I mean I'm opening another box now. Ok, our repository is useful or not and how do you set them up for success? But in terms of differentiating these two, it also depends on how detailed the information that you got from this insight have is what happens sometimes or what I believe is a good way to connect them.

Julian Della Mattia [00:30:47]:
If you could triangulate insight from different teams and you have a triangulated insight because you don't want to create like a mess of okay, we just put tickets and that's it. This is the inside. Maybe you want to curate a little bit and you want to give some that you could take into the repository. So probably one distinction that we can make is probably in the inside hub everybody can get their hands dirty and maybe in the repository you don't want everybody to get their hands dirty because then you have different levels of information or it's incomplete or have different standards, and it can get super dirty super quickly. But that's just my take. Maybe some others were like, yeah, we want everybody to access and do everything everywhere. So.

Erin May [00:31:26]:
Yeah, but it sounds like, and these could potentially live in the same software, but be different areas of the same thing. But it sounds like there's different use cases, which is the researcher who needs a lot of information and context and raw material to do their magic with, and then the rest of the who doesn't need and probably shouldn't have all of that most of the time. So really knowing the use case internally in the user and building around that.

Julian Della Mattia [00:31:53]:
Yeah, definitely. I think it's definitely that. And as you said, you can go and maybe the findings or the insight or the input you get from, I don't know, sales, maybe it's not polished. So you want to be the one then curating it, triangulating it, and putting it into the repo. That's probably. And then it can live. Then it can live longer there, and you can then track it. Okay, this was implemented here.

Julian Della Mattia [00:32:15]:
This led to this product change. The other one is a little more liquid and a little bit like a playground. So you can then whatever you don't have, okay, we can throw it away, we can change, we can move. That's also another difference, I'd say.

Erin May [00:32:29]:
Julian, do you think that people from your experience or you yourself in the past, tend to over index on the executing research or the research op side? Is there a natural inclination there that is maybe not the one you would recommend based on your experience doing this multiple times?

Julian Della Mattia [00:32:47]:
What do you mean exactly with over indexing?

Erin May [00:32:49]:
Yeah, like spending too much time executing on research or spending too much time on the research op side.

Julian Della Mattia [00:32:55]:
Yeah, definitely. Yeah, that's usually the case. And I think it goes on both sides. Like, both on the reops and on the research side? Yeah, I think that when you are also, when you are the first researcher, you cannot really afford to do that much otherwise. And we go back to, okay, fine, you need to wear different hats, and you need to not only do the work, but also help elevate everybody's work or help the company understand research better and build infrastructure. So you cannot really afford to say, okay, fine, I'm gonna spend 80 hours on this little thingy here, because you just cannot do it. Yeah, yeah, yeah.

Erin May [00:33:35]:
When I think about. I guess I would imagine many people probably don't do enough ops early enough, but when I think about doing it too early, I think about, get a few reps in and know what you're trying to operationalize before you do it. Right. Otherwise you've built a system that has no value to plug into. So, so don't do it.

Julian Della Mattia [00:33:53]:
Yeah.

Ben Wiedmaier [00:33:53]:
Thinking of a beautiful spreadsheet that's got, you know, tags and organizations and it has like two rows because you've only, to Julian's point, had two usability studies come up. Yeah, that's a really good point.

Julian Della Mattia [00:34:04]:
Yeah. And like in this regard, what I also saw in many cases, I mean, researchers tend to actually do that and because they love the end photo repository will look great. So I'll spend all this time doing the taxonomy right away. And it's like, how many research projects have you done? Well, two, but we will get there.

Erin May [00:34:23]:
Right.

Julian Della Mattia [00:34:24]:
So you need to kind of like find a middle, like a middle ground between building something that will then set you up for success in the future and overkill in the first month. And same with spending. And we can also go for that. We can open that box too. Okay, fine. When you want to get tooling. Okay, fine. Yeah, let's get this one.

Julian Della Mattia [00:34:42]:
And then you spend a lot of money and say, okay, most of my budget went here and then now we have this really expensive repository tool that nobody's using. And I said repository could be other things. Sometimes you also need to take a look at the end photo, but then see and track back what are the steps that you need to take before you get there. Right?

Erin May [00:34:59]:
Yeah. Where would you put your tool budget first? Recognizing it, of course, depends. But what are some common good uses of whatever budget you might have early on as a limited team?

Julian Della Mattia [00:35:11]:
Probably a tool for unmoderated testing would be my first thought. A repository, you can even build on Google sheets if you are scrappy enough and probably if you have CRM or any email marketing tool. I think that's something that also spend money on just because if you want to then reach out to customers here in Europe, we also need to be mindful of GDPR, so we need to have all the automations in place and have everything tidy and clean. So investing there is also something that I would recommend right away, unless you can then share budget with another team and say, okay, fine, we get this good tool. Those are my two no brainer. These are the first thing I would recommend. And then we can see, depending on each case, if you want to go here, you need a repo tool, one transcription if you want to do something with AI now or there's so many things you can try, but that's more case to case kind of basis.

Ben Wiedmaier [00:36:10]:
Julian, when you're a team of one or a team of fewer than five, scale is something that we hear a lot about researchers capacity. We've been talking about it with prioritization. In your experience, though, how do you, what are the things that you've done to try to scale up the work that you're able to deliver, the insights that you're able to deliver? We've alluded to, well, we said outright that research can be insight, informed decisions can be a team sport. Do you find yourself tapping in colleagues and stakeholders? What's your blueprint if you're still a scrappy team and you want to scale up a bit?

Julian Della Mattia [00:36:47]:
Well, in that sense, we have no choice but to touch on the research democratization topic. So when you land a company again, what's our take here? What can the company do? What can the team do and what is the team willing to do and how do you leverage that? And what are also your recommendations as a researcher? Because you brought it as a specialist here. So do you recommend, okay, everybody can do research. Only this team can do research. Only this team and this team can do this type of research. This also something that you also need to kind of assess. I mean, there's so much about research democratization and different models and so on. But for me, it pretty boils down to who else if you're a team of one, I mean, you don't have much of a choice at some point, unless you want to do like deliver this bit of work and then go from there.

Julian Della Mattia [00:37:31]:
And the company's fine with that. But if you wanted that and we go back to the playmaker kind of approach that I said at the beginning, if other people are conducting research, any sort of research, how can you help them improve or step up the game? How can you set boundaries? How can you set up the right, how can you help them elevate the game? Because at some point you won't be able to conduct five service because other teams are doing them. And what can also happen is that if you, even if you don't go there and help them step up the game, maybe the service going out anyway. So that's also the case sometimes, like, okay, we're still doing, we're still talking to customers anyway, whether you help us or not. So I think that's something that you, that you need to say. For me, the best way to tackle it heads on is, okay, fine, what can, who's willing to do stuff or what kind of stuff is happening right now. Who's willing to help out? There might be some people who are not interested. I faced so many designers who are like, yeah, I don't want to talk to people.

Julian Della Mattia [00:38:21]:
It's like, I want to go into Figma and just stay in my Figma world, which is completely fine. I mean, it's their choice, it's fine. And I find other people like, yeah, please, I want to do it. I want to see, I want to test, I want to. So you need to also worry people who are actually willing to do so. And then you can then assess your actual, like, not only the, like, the research team's capacity, but also the overall company capacity to learn from the customers. And we connect this to the Inside app so we can have this 360 view of it.

Ben Wiedmaier [00:38:52]:
You do hear so often that teams of one or small user research teams are themselves also ops teams. I think too often we get trapped in this idea that Ops is for a more mature or a bigger organization. I think one of the big reasons we wanted to have you on is because you, you are both a researcher and an Ops person. And maybe you think of those titles in the same way, but I think everything that you've talked about here, so much of it is ops. Right? Empowering people through rigorous research, ensuring that there are guardrails so that they're not launch blocking, but you're also enabling them to do things. Everything that you're describing is typically within the purview of a research operations pro. So in your journey to becoming someone who's got both researcher and ops in your title, was that something that just had to happen? You were joining enough companies finding that like, well, gosh, I need to come up with some best practices around screener questions or what not to ask in an interview so that it's not leading or that we're not violating a particular information security policy, could you walk through how that identity, you sort of became the researcher and the reops person?

Julian Della Mattia [00:39:52]:
That's actually, I mean, the reason I became both is because of my experience as a first researcher. So I've been the first researcher in many companies and I was not the first one. I was one of the early hires. So I never work in a team larger than eleven people. So I kind of went always small. And at some point I think, I mean, one time it was chance, second time, well, maybe a bit. And the third time is not, I mean, it's not coincidence. And I'm picking these kind of challenges when I change jobs.

Julian Della Mattia [00:40:18]:
Plus I also worked with many companies that wanted research, I wanted to create a research culture, and they had no researcher in house. So in the end, I mean, I had no choice but to learn how to put things in place for myself at the beginning. And then I said, okay. At some point later in time, I learned this is called research ops, to be honest. So it's like, okay, fine, I don't have a research process. How do we put this together? How do we prioritize? How do we reach out to customers? Where do we store the things that we. And it was kind of like reading articles or talking to people. But the term ops came later on.

Julian Della Mattia [00:40:52]:
And at some point, if you ask me, I feel like the way I feel myself as a research op specialist is specialize in smaller contexts. That's why everything I create is related to first researchers, small teams, teams of one, because that's been my context most of the time. So, yeah, I agree that when you're the first research, you're a bit of a hybrid because you have all this bit that is research, and then you have all this bit that is operations. If you're lacking one, you will be swimming in requests and swimming in projects, and you'll be like, okay, fine, where do I. And if you go the other way, you will not have the company learn much, you know, in comparison. Or it would also prevent your spreading the word, efforts to actually, you know, to impact deeper, because people say, like, fine, you talk about how cool is research and how we should be all doing this, but where's your work? You know, it's like, what have you done here? You know? So, yeah, a bit of both. Yeah, yeah.

Erin May [00:41:47]:
It sounds like a good rule of thumb is no matter what, you want to be doing some research, you know, generating some insights, but you gotta figure out that exact ratio based on where you are and where your company is. Before we move to our rapid fire section, are there any closing thoughts on building a research team from scratch you want to leave folks with? Definitely do this. Definitely don't do this. Anything that we didn't cover yet.

Julian Della Mattia [00:42:12]:
The success. I mean, for me, the key tip to success is to really, and this is a research project in itself, really understand the context and your team really deeply. And I talk about, okay, asking the right questions during the interview process, like asking the right questions during the onboarding. So understanding where you stand and also understanding where you want to go to is definitely going to set you up for success. Because if you don't ask, especially when you start, if you don't ask the right questions, and you don't understand where you're going. You can then start building many things, but then, you know, you just build a rocket that then sits in your garage. So probably the understanding bit is something a lot of people overlook and they just chow. Yeah, because they're excited because they want to prove their value.

Julian Della Mattia [00:42:53]:
Because I want to have impact right away sometimes. I mean, there are many, many reasons why this can happen, but really, really spending time understanding everything when you join a company as a first researcher is the way to go. Because this is so context. Depending. Most of the answers that of the questions that you asked me are like, okay, depends. It depends on this and depends on that. So this, it depends really exists. So, yeah, actually knowing what you need to, what you need to tailor for is actually going to set you up for success.

Erin May [00:43:21]:
It depends was on the short list of titles for this podcast, if you can believe it.

Ben Wiedmaier [00:43:27]:
I was thinking this episode could be titled it depends really does exist. That is such a great reminder that research is comprised of methods and frameworks and types of evaluative tools, but those don't make a research practice. All the things that you've been talking about do good stakeholder relationships, understanding of the business model, where the company does or does not want to go. And then, like, you've really done nicely here today, Julian is describing where you, the researcher, can bring that expertise. And that is actually one thing I wanted to close with is, or one of the final questions I had for you is I think researchers can sometimes be a little hesitant to make a recommendation or to sort of influence the organization. And it sounds like from your experience, when you're brought in early, there is an opportunity there to do these sorts of things, both to learn, as any good researcher seeks to do, uncover the context of this place I find myself in. But then to say, right, you brought me in because I know how to link feedback, that we're getting these other data inputs to a recommendation. So I think it's a really great opportunity for folks who are listening who might not be teams of one.

Ben Wiedmaier [00:44:28]:
Remember that you have expertise and that you can make those recommendations and shape that context.

Julian Della Mattia [00:44:33]:
Yeah, definitely. I think that you become sort of the orchestrator of insights and giving a recommendation because you are the expert at some point. So also don't shy away from recommendations and try to say, yeah, okay, this is the way recommendations, whether to tackle a project or not, the way you approach a project and what you should do with the outcome. Okay, this is what we learned. This is what I recommend you doing of course, then this then is taken into a discussion. And maybe this, like the product team with designers, engineers, you know, this gets then play with, but don't, I mean, step up and don't be shy to do so. So I think positioning ourselves as some sort of counselor, there's this doctor, Ari Zalman always talks about this role called the concierge or the counselor. So you need to position ourselves in terms of this.

Julian Della Mattia [00:45:18]:
And he talks about being the anchor that delivers the news, if his content is great. And there's a lot he talks about in this direction. So, like giving recommendations with the right tone and with a strong voice. It's really important for researchers, whether you're a team of one or you are part of a larger team, I think that's something we should never shy away from. Awesome.

Erin May [00:45:35]:
Let's hit that rapid fire. Three questions for you, Julian. First one, and you can say, it depends, but then I'll ask you for further clarification. Favorite research question or method.

Julian Della Mattia [00:45:50]:
Okay. I would say it's more a prompt. So tell me more about that. I love saying that in interviews. Okay, so tell me more about that because it really opens up the game. Or just nodding is also fine, but nodding and tell me more about that. Definitely.

Erin May [00:46:05]:
Yeah, tell me more about that. I get it. It speaks for itself. Always a great one and open ended and inviting and warm and shows interest and all those great things. Thanks. A few resources that you recommend to folks either on the topic we talked about today or research in general, blogs, books, et cetera.

Julian Della Mattia [00:46:25]:
It depends. No, no, we can go. In terms of research ops, I always recommend, I always point to the research apps community because they have such a large number of articles, they have the community. You can reach out to people there. So if you want to learn about operations, you can definitely check out there. In terms of research, I mean, I have a lot of people that I follow apart from, I could recommend some books and so, but there's some people that I follow and whose content I feel super, super valuable. Bezel Sirianni, for example, General Ward. These are Ruby prior.

Julian Della Mattia [00:47:00]:
These are people that I follow, and they have really valuable insights. So I recommend you can follow them. Some of them post on LinkedIn. Some of them post on their blogs. Some of them post on some companies blogs as guests, writers. And so you can find them online. But definitely, I would definitely recommend to follow them because they're really also sort of inspiration sometimes when you're like, okay, how would they. And I tried to put myself in their shoes.

Julian Della Mattia [00:47:24]:
How would they approach this? How would they think about this? So definitely recommend it.

Erin May [00:47:29]:
Awesome. We had Ruby on a couple weeks ago. Nice color. Yeah. Where can folks follow you? LinkedIn? Twitter? Somewhere else?

Julian Della Mattia [00:47:38]:
So they can follow me on LinkedIn. I also have a newsletter, well it's blog newsletter at the 180 cc and they can also listen to my podcast that actually launched not long ago which is called from finders to builders so you can find it on Spotify and YouTube.

Erin May [00:47:53]:
Amazing. Thanks Julian. Thanks so much for being here today.

Ben Wiedmaier [00:47:56]:
Thank you so much Julian.

Julian Della Mattia [00:47:57]:
Thanks for having me. Great time.

Erin May [00:48:06]:
Thanks for listening to awkward silences brought to you by user interviews theme music by fragile gang hi there awkward silences listener thanks for listening. If you like what you heard, we always appreciate a rating or review on your podcast app of choice.

Carol Guest [00:48:31]:
We'd also love to hear from you with feedback, guest topics or ideas so that we can improve your podcast listening experience. We're running a quick survey so you can share your thoughts on what you like about the show, which episodes you like best, which subjects you'd like to hear more about, which stuff you're sick of, and more just about you. The fans have kept us on the air for the past five years.

Erin May [00:48:49]:
We know surveys usually suck. See episode 21 with Eric Erica hall for more on that. But this one's quick and useful, we promise. Thanks for helping us make this the best podcast it can be. You can find the survey link in the episode description of any episode, or head on over to useriterviews.com. Awkward survey.

Episode Video

Creators and Guests

Ben Wiedmaier
Host
Ben Wiedmaier
Senior Content Marketing Manager at User Interviews
Erin May
Host
Erin May
Senior VP of Marketing & Growth at User Interviews