Your tools aren't broken, your processes are with Zontziry Johnson

The more that I was talking to researchers, the more that I realized it's not so much a hesitance and a fear for their jobs as much as they've been oversold these— overpromised these tools. And when they go to use the tools, they're like, this isn't doing me any good. This isn't doing what I thought it was going to do. I was told that this was going to create so much more time in my day, and it's not. I was told that it was going to, like, take all this stuff off my plate, and instead I'm having to check all the work and I don't see the time savings that I'm supposed to get out of it. So I call it this well-earned mistrust of tools that they're facing. Hello, fellow insight seekers. I'm your host, Molly, and welcome to The Curiosity Current. We're so glad to have you here. And I'm your host, Stephanie. We're here to dive into the fast-moving waters of market research, where curiosity isn't just encouraged, it's essential. Each episode, we'll explore what's shaping the world of consumer behavior, from fresh trends and new tech to the stories behind the data. From bold innovations to the human quirks that move markets, we'll explore how curiosity fuels smarter research and sharper insights. So whether you're deep into the data or just here for the fun of discovery, grab your life vest and join us as we ride the Curiosity Current. Welcome to the Curiosity Current. I'm Stephanie, and today I'm joined by Dhanteri Johnson, Head of Learning and Research at the Insights Career Network and founder of MRX Explorers. Z is someone who steps into complex, ambiguous environments and builds structure where there isn't any. She's led 90-person teams through digital transformation, helped global research teams adopt tools that they invest in, and built operations infrastructure from the ground up at places like Microsoft and Reckitt. Her work sits at the intersection of customer, product, and operations, and increasingly at the intersection of what the research profession has been and what it's becoming. Today, we're exploring what it means to evolve as a researcher right now, the shift from execution to orchestration, the tools that reshape how insights get created, and what a strong career in this field will actually look like when the ground is moving under everyone's feet. Gonna be a great conversation. Z, welcome to the show. Thank you so much. I'm excited to be here. We're excited to have you. To jump right in, you describe yourself as someone who, I love this, drops into chaotic, ambiguous, environments and turns them into something structured and scalable. And increasingly, that is starting to sound like the job description for a lot of researchers, especially research leaders. Was there a moment in your career where you realized that you were more drawn to kind of fixing broken systems rather than to delivering insights per se? Yeah, so I was thinking about this and realizing The thing that happened was really when I was delivering insights, I found myself being impeded by the systems that were in place. And so in order for me to deliver insights, I was fixing the systems that were keeping me from delivering those insights. And as I was fixing those systems, of course, fix it for myself, fix it for others in the process. And I just found myself that I had this skillset for fixing those systems. And it was one where oftentimes I find that when people are trying to fix systems, there are complicated solutions that are put into place. And 9 times out of 10, that's not like necessary. It's usually something much, much simpler that needs to happen. So, an example, data science team and market research team not talking together, not working together, super siloed. And what I found was they didn't know what the other one did. There was no shared language. And so there were lunch and learns that I created where each of them got to present to each other. And in that process they were like, oh, oh, that's what you do. That's why you can't take my data and just like go treasure hunting from the market researcher side. Right. And the data science team going, Oh, you thought that's what we could do. Oh, that's why you kept asking us to do that. Okay. And so in the process, it's like they just learned about each other and they developed this shared language. So it wasn't a full program that needed to be put in place. It wasn't a full thing. It was just this system that it was like, we just needed them to talk to each other and learn about each other. Right. And in that process, they ended up just naturally working together. Because they understood each other better. So that's where I found myself like merging over into fixing systems more often than delivering insights because it just, it just became natural for me to do. Got it. And I love that the example you shared that it's such a simple solution, right? Like just talk to each other. Just have some touchpoints. Yeah. Understand each other a little better. Yeah. Yeah. Yeah. And they're so often not in the same room together. And so just getting them, like being deliberate about putting them in the same room really made a huge difference. Totally. No, I can absolutely imagine. We have a, a real culture of that at, at AYTM simply because we have advanced analytics that are automated on the platform. And so there's just a lot more talk, you know, and describing to clients. And so everybody has to be well-versed and yeah, it just makes like all of the things that the data team wants you to be thinking about during design that you might not be as a researcher, those things that you start to learn those things, right? And then those frictions go away. Yeah, exactly. Yeah. Makes a lot of sense. Yeah. I kind of want to switch gears because I love this next sort of line of questioning and we hinted at it in the, in the intro, but we hear a lot or I'm hearing a lot about this idea that the role of the researcher is shifting from execution to orchestration. And I think that's true, you know, obviously on the brand side, it's true on the supplier side too, though. And it sounds right to me in theory, particularly in the context of generative AI. But from where you sit working directly with teams kind of going through this transformation, how far along is that shift really? And when organizations are, when you see that they're staying stuck a little bit in the executional model, even when there's a mandate or a desire, to move into this, you know, role of execu— role of orchestration. What do you think usually, well, what is your diagnosis usually? What is it about? Is it resistance to change on the part of the researchers? Is it change, poor change management? Is it tools not meeting needs? Like, where are the gaps? So, what I have learned increasingly is it's yes to all the above. It's never just one thing. And that I think is what makes this so complicated for organizations. Yeah. So, I used to think that it was, oh, researchers are really fearful for their jobs. And so, there's resistance from them to adopt these tools. But the more that I was talking to researchers, the more that I realized it's not so much a hesitance and a fear for their jobs as much as they've been oversold these overpromised, these tools. And when they go to use the tools, they're like, this isn't doing me any good. This isn't doing what I thought it was going to do. I was told that this was going to create so much more time in my day and it's not. I was told that it was going to like take all this stuff off my plate and instead I'm having to check all the work and I don't see the time savings that I'm supposed to get out of it. So there, I call it this well-earned mistrust of tools that, that they're facing. But then there's also on the change management side, a misunderstanding and a misalignment on the, what the tools are supposed to deliver and the way that the tools are being rolled out. And so teams are being told, just go find something with AI, right? It's not, go find something that's going to help us do XYZ, it's go find something with AI, right? Which it's not solving a problem. It's not increasing efficiency. It's not doing anything but just FOMO. It's complete fear of missing out. And so there's, I think, you know, with all of the reports that come out about organizations are adopting and not seeing output from this, the ROI isn't there and No company wants to be the 90% that's not seeing ROI. They want to be the 9% that does. So, there's increasing pressure from the top to be part of the group that is seeing ROI. So, they're putting pressure down below. Why is there no ROI? And the people who are using the systems are like, because they don't work. Because you're telling me that I'm supposed to be able to do all these things. And that's not how it works. So, there's disconnect. The tools aren't delivering. The people are being pushed to do things that they can't. And management is getting really frustrated because they're not seeing the delivery on what they have been told the tools are supposed to deliver. So, there's misalignment all over the place and And that's where it's a little bit of everything that is really contributing to this problem. Yeah. I wish that you could have told me, oh, it's just this, and so we know how to solve it. But I mean, I suspected that was the case, and it has certainly been my experience as well. So it makes a lot of sense. Yeah. I have a slightly more concrete question in the same vein, maybe just digging in a little bit more. But you've worked closely with teams as they're trying to adopt these new tools that we were talking about that are sometimes oversold. And not just select them, but actually embed them into their workflows and how they work. I work in a similar vein of, albeit for, for one platform, AYTM, right? But really trying to help bridge that gap. But I think there's something that is psychologically interesting about that gap between like, oh, we chose, we adopted the tool or selected the tool, but the adoption is not there yet. And I'm curious, like, where do you see breakdown most often? And what are some of the approaches you use to close that, you know, adoption gap, let's say? Right. So, I think the adoption really, it's the breakdown is in the process. The process didn't get rewritten correctly or didn't get rewritten at all. At all. Yeah. It was a, we brought in a tool and we assumed that you would be able to just plug it in, in the place of a tool. That you were using previously, and we didn't realize that the inputs into that tool maybe are going to stay the same, but the way that the tool works are going to be completely different. The outputs are going to be completely different. The time that it takes is going to be completely different, or the inputs that are coming in are going to now need to be reformatted so that they work in the tool. Yeah. Or they're going to need to be different altogether. So that they work in the tool. And then the, you know, it's like when you test a tool, you test it in isolation too often. You don't necessarily test it with all the rest of the tools that you have in your toolkit. And so now you're looking at, well, this tool worked great in a vacuum, and now I need to make it work with everything else that I work with. And oh no, now I have Tool X that needs to work with this, and they're not meshing together. And now the output that I have from this needs to go this way, and it— that, that's not working. And so the adoption ends up creating more friction than it was supposed to alleviate. So it's this process of we didn't necessarily take a step back and look at all of the processes that this particular system was going to impact. So this, this tool, what are all the processes that need to be evaluated where this tool actually has an impact? And now let's analyze which of those processes now need to change if we're gonna be implementing a new tool. And in some cases, we're implementing a new tool where a tool didn't exist before. Right. And in that case, we're having to create brand new processes that we haven't created before. And we're just like slapping a tool over the top and saying, well, now you just enter a prompt and go. Right. And you're like, no, you, you do, you don't, you actually need to like think through what are the use cases and then what are the prompts and then what are the outputs and then how is it going to actually work and when should I use it and how should I use it and where do I push it to. So. It's all in that process step where it's really falling apart. That makes a ton of sense. And I, I was thinking as you were talking about that, like, you know, so testing or maybe not testing, but like the difference being you're testing in a vacuum versus testing in, in the context of your, the rest of your tool stack. But also a lot of times when we're testing platforms, we're testing like a theoretical business case, right? Like, oh, well, you know, and the person who's showing it to you was always using a theoretical, you know, use case. But it's like when you get down to those real thorny business use cases, it's a whole different ballgame often. Yes. Yes. Yeah. It's the tight timeline. It's organizing all the stakeholders. It's everything that goes into that, that suddenly it's like, well, when you have this nice tidy little dataset that goes in and it's cleaned up specifically for that test case, then it's like, oh yeah, it worked great. Right. It looks so good. Yeah. For sure. Well, to that point, you've developed frameworks around tool selection, right? Because that's part of it too, right? Is that it's, it's being able to assess some of that during the tool selection phase rather than post, you know, purchase. Yep. And I, I understand that you do this with a particular focus on like AI functionality, data security in mind. When you're evaluating a new tool, what features, what signals do you pay attention to, to assess whether it's going to be able to create genuine change or value versus just adding another layer of complexity on the tool stack? So, the biggest thing that I look at is actually that inter-functionality. It is, what is it that it's actually going to need to plug into and where is it that it's going to need to work? What systems is it going to need to work with? The other thing that I look at is what does it look— how often is it going to be used? And what does the learning curve look like for learning to use it? So if you have a tool that it's great, but it takes a couple of weeks to really get used to it. And that couple of weeks is you're using it every day, but you're only going to use that tool 3 times a year. Guess what? The 3 times a year, you're not going to take 2 weeks of using it every day before you use it. Yeah. Each of those 3 times. Yep. So when, and that's, that's part of the thing is you're testing these things and you're not necessarily thinking, how often am I going to be using this during the year? And if it's taking, if the learning curve is this in order for me to use it, oh no. What? Okay. I need to have a really good guide step by step so that when I do need to use it, I can go through this guide. So that I'm not having to go through that learning curve, or maybe that's not the tool for me. Maybe I need something that is a lot easier for me to learn, is much more intuitive for me to use. So there's that, but the inter-functionality is really where I see things fall apart because it's like, okay, does it have ways that you're going to be able to tie it into your other systems? Does it have APIs that you can just plug it in? Or does it sit alone? And then can you export the data? Can you not export the data? When you need to leave this system entirely, what is that going to look like? Right. Are you going to be able to up and leave, or is everything now stuck on that system? And that's going to be a nightmare trying to get all your data off of that system. So it's things like that, that it's like thinking long-term. What does it look like working with that system, working with that tool that, again, we often don't take into account when we're evaluating. There was something else that you were talking about that really resonated with me, which is around this, like, you might only use this tool a couple of times, but it's a tool— a year, but it's a tool that, you know, takes some ramping up on. And like, from the supplier side, the trick of that to me is that You know, sometimes we'll have organizations come on board and it'll be a lot of users, 50 users, right? Yes. But each of them is only using it 2 or 3 times a year. And so— Exactly. Like, it feels like we've got a bulk of people and we're going to train them all. But in reality, you've— it's a lot of individuals who are doing each, each of them are doing a little bit of work on your platform. And so it really does come down to, you know, on the supplier side, the best we can do is make the time to value super quick for them and make sure that it's— they're able just to get in and do the work that they need. And I've often thought that on the, the brand side, that maybe there should be a little more specialization in terms of who your power users of a specific tech are, right? And so, you know, you have somebody who's maybe doing programming and analyzing, you know, 8 to 10 surveys a year as the executional type of role rather than a, right, you know, to save everybody else the, the time. Yeah. I mean, in a perfect world, you would have a person who is the expert in that tool or who is the expert in the, in all of the tools, who then becomes the person who has open hours that you can go and ask questions of. In reality, that's not going to be the case because we're dealing with smaller teams, smaller budgets. Everyone has so much on their plates anymore. So what that translates into is I think suppliers and brands need to work together a lot more to create those playbooks and those guidebooks so that when it does come time to use them, it's not so much of a learning curve barrier that they're faced with. Instead, it's a step 1, step 2, step 3, and super laid out so that it really is easy for them to get into the platform and use the platform. Ziyi, you've worked brand side. Supplier consulting side, and the research technology side. You've seen how the insights ecosystem essentially operates from these three very distinct vantage points. Each side has its own priorities and its own blind spots, obviously, but I'm curious, where do you see like the biggest disconnect in how these three types of players in the insights ecosystem understand each other? For me, the disconnect is each one thinks that they have more time than they actually have. So the supplier and the res tech oftentimes don't understand that the brand professional, the brand insights professional doesn't actually sit there every day with a lot of time to look at the data, comb through the data, come up with the insights. They're actually spending the majority of their day wrangling stakeholders, listening to what the stakeholders need, trying to get the stakeholders brandholders to actually sit in the dang room for 5 minutes so that they can understand what the business question is. Totally. Yeah. And review the survey. Please review the survey before the deadline. And suppliers are like, why can't you get to the deadline? And brands are like, because I have 10 people I'm trying to wrangle to get to review this. They're like, why is it 10 people? Because it's 10 people. I can't tell you why. It's just 10 people. It started with 1. It turned into 10. Everyone heard about this. Everyone wants to have a say. So, and then the brand is looking at the supplier and saying, why is it taking you so long? And the supplier's like, you don't understand that we have multiple different teams that have to orchestrate together in order for us to be able to deliver everything to you. It's not just one person wearing all the hats. We have to figure out our programming team and our panel team and our Right? It's multiple teams. And then the rest tech side is like, why aren't you just using our tech all the time? It's like, because we have multiple projects running at the same time and those projects, we're not running a survey every single day. So, there's this, this, like everyone is operating in this silo that they don't recognize what everyone else is doing. And because of that, they don't really sit back and understand, oh, okay, so the brand doesn't have time to look at the data. That's why they expect me, supplier, to know the data inside and out and my business so that I can actually make those connections. And the supplier is looking at the res tech or the brand is looking at the res tech and saying, res tech, you kind of need to do the same because I need your tech to be super easy to use. Low barrier, low entry, cost effective, and actually deliver what I need it to deliver because I've got it, like, I've got no time, folks. I need to actually just push the button and make it go. So, push the button and make it go. Which is just, that work. And so, it's that disconnect between all three that I see happen all the time. And more often than not on the res tech side, You have people who are tech-focused and not research-focused. And so then you have an even bigger disconnect because I can't tell you the number of brand-side people who are just so frustrated when they get a salesperson from ResTech who knows nothing about research. And they're like, I can't talk to you. You don't understand what I do. You don't understand my timelines. You don't even understand basic market research terminology. Yeah. So, I'm not going to be able to talk to you anymore because you just don't get it. You're just trying to sell me a piece of technology and you have no idea how it fits into my day. So, that's an even bigger disconnect for some of those companies. For sure. And I think even, you know, beyond sales and into like support roles and enablement kinds of roles on the platform, we talk about this a lot. I say often that like, a client showing up is not going to differentiate between a technical question and a research question. They're all just questions to them. You know what I mean? And so, you know, there are certainly places like chat support where we're going to put a truly like platform-focused resource person who's that first line of defense. Hopefully it's a technical question and we can answer it. But as soon as we see that, you know, there's an entanglement here because it's an entanglement of technical and research questions. Together. It is. Then you've got to get somebody who has that both backgrounds to help solve the problem. Yes. Yes. And it's hard to find people who understand the tech and the research together. Yeah. And I think we're, we're starting to find more that do because of how long now we have Resnick around. Oh, around. Yeah. Yeah. I know I used to, when I was hiring, would be like, I mean, do you have, have you ever worked at a research technology company and just like hoping for anything, but realizing that probably I wasn't going to get someone from that background. And now it's so much more common. So, yeah, yeah, yeah, that is— times are changing for sure. I want to talk a little bit about the concept of agency, and I personally think of that as, you know, seeing a problem and feeling empowered to just go fix it. I've heard you call it a bias to action, and in a market where job descriptions are getting blurrier and expectations are expanding for researchers, that does feel like a critical differentiator for people. How is that instinct, if that's what it is for you, this bias to action, how has it shaped your career in research? And I'm curious, how do you cultivate agency both for yourself and for the teams that you work with? And I say that assuming that it is not a fixed trait and that we can actually move it. No, I think we can. And I think there are a couple of things that need to be in place in order for it to be nurtured. And I think from a management standpoint, you need to tell your teams that it's okay to fail. That is the biggest barrier to agency and the biggest barrier to that action happening, because all too often employees are really terrified to fail because they're worried that— they're scared. They're not worried. They're scared. They're scared that if they fail, they're going to end up with a poor review, they're going to end up with something that is labeled against them. They're going to end up missing out on opportunities because they're going to be labeled as the fail, the failure. So as management, it is so important to model failing and learning from failure. It's not just, you can't just say, it's okay to fail, guys. You have to model yourself failing and learning from failure. Because then your team will go, okay, if my manager's failing and okay with failure and learning from it, then okay, maybe it is okay. It's going to take a few iterations of that before your team actually feels like it's okay, because let's face it, we've grown up in a world where failure was not okay more often than not. Right, right. And I think especially in a field like research where it, you know, especially for a long time felt like our primary role was mitigating risk. Risk, right? And so just this very exacting focus on ensuring that we're not wrong, right? And that everything is pristine and perfect and there are no errors, right? But that's just not where we are as an industry, and that's not what we want insights to be even. Like, that's boring. Yeah, yeah. So that's from the management layer. When that's in place, then you are able to have people actually experiment. And I like the ability to say that it's an experiment instead of anything else, because that puts you in a mindset of, I'm not necessarily going after something and failing. I'm going after something to try it out. I'm going to see if it works or not. Yeah. And when it's an experiment, you are setting it up as it has the potential to not work out and that's okay because experiments in our heads, the scientific method, always has the option for it to not work out and that feels safe. Yeah. So when you put it that way, then it starts to be like, okay, I can experiment with this. I can test things out. I can see what works, see what doesn't, learn from it, try again, learn from it again. And then you start to create that behavior of experimentation and learning from it and understanding what is educated experimentation, right? So it's not like I'm just gonna go do something because I think it sounds cool, is I'm gonna do something because I understand what the potential for the outcome could be. Yeah. And I understand where the risk level is and what risk I can work within. So I think that is what I have learned can help people actually develop that agency and develop that bias to action. For me, it's been instinctual. I have just been a person who just goes and jumps in with both feet first and suddenly wakes up and goes, uh-oh, where am I? What have I done? And I'll say sometimes it's gotten me into trouble and sometimes it's worked out, but I have had to learn that because for a long time in my career, I was like, why doesn't everyone just do this? And then I realized as I became a manager, the reason why is because people are scared in their careers to make mistakes and to fail because they're scared that if they do, they're going to be labeled as failures. And they're going to be demoted and not get opportunities to take on new challenges. Yes, absolutely. Yeah. And there's, I think also from a management perspective, just to piggyback on what you're talking about, giving people like a sandbox to do that experimental work in, right? So that the stakes are just a little lower than, you know, our largest clients, quick turn projects, right? That's not the time to experiment necessarily, but— Yeah, creating those circumstances where it is safe for them to experiment. Yeah, absolutely. No, that's such good advice. OK, so this is more of a practical question, but I'm very curious to hear your response. Based on all the experience you have kind of working with organizations to get their tools and their processes and their people into alignment, and not just on paper, but like really functioning in alignment. What is one small change that an organization can make that will yield a big impact for them? I think the— I don't want to say the biggest change because it's a small change, but it is a very impactful change— is listening for what is not being said. People will say a lot of things. Because they are oftentimes trying to put a solution out there. They're not necessarily saying what the problem is. They're trying to tell you what they think the solution should be. They're trying to say that everything is okay, even though it's not necessarily okay. There are undercurrents that you can tell are happening in an organization before things start to go off the deep end. And if you're tuned in to what is happening under the surface and you're actually listening for those things that are— you're tuning into the things that are not being said, I think there's more there than you realize that you can actually build on. So when it comes to pulling people into alignment, pulling organizations and teams into alignment, it's the Okay. These teams are not necessarily getting in alignment. They say that they don't have, you know, that, that they're, they just don't want to. Well, let me look at their schedules. They're saying, they're constantly saying they don't want to. They're constantly saying they don't want to. Well, are they always, maybe it's that they're always busy. Have I put too much on their plates? And that's why they don't want to. It's a, I don't want to. Because I have no time. I don't want to because I can't put another thing on my plate. It will destroy me. Right. You know, there are things that you can start listening for that I think will help you figure out what are the things that are actually getting in the way of alignment and paying attention to the, and if, you know, there's just, there's something there that I think we miss out on when We're moving so fast, we're not taking the time to actually sit with what's happening in the organization that we're in and understand what's actually going on. We don't put all the pieces together and see the entire puzzle for what it is. Yeah. So, when I was, when I was actually working with that 90-person team on the digital transformation, you know, it was why Why isn't everyone focusing the same direction and on digital transformation? And what I found was everyone had a different definition of digital transformation. It wasn't that they didn't want to be headed the same direction, is that they had no idea what the direction meant. Uh-oh. Yeah. So, you know, when I, when that happened, it was like, oh, okay. And then when I started to put training in place, it was like, well, some, this one team suddenly was like, We don't have time. There's no, we don't want to. And it turned out they, it's not that they didn't want to, is that they didn't have time right then for it. Yeah. If I moved it out a month, they had time, but right then they were crunched because there was deliverables for that entire team. So it's those things that it's like, you just look a little bit, you peel the layer up just a little bit and suddenly you see, oh, the thing that is blocking the alignment is not the thing that they're saying. It's something just a tiny bit deeper. It doesn't take that much. It takes just a little bit to peel it back and find out what it is. Truly, truly. And I too have almost always found that, that I don't— the resistance to doing something when you look underneath it is, is often due to bandwidth issues. And it, it makes me a bit sad that people feel comfortable saying, no, I don't want to, but they don't feel comfortable raising the white flag and saying, I am underwater, like to a degree that I couldn't possibly do this thing on top of it. Yeah. Yeah. Yeah. So do, do you typically find that you're encouraging that kind of like more honesty between, like more frankness to just bring this kind of stuff to the, to everyone's awareness and visibility, or are you just kind of solving it behind the scenes? No, I'm encouraging, especially if I'm in a management role, I'm encouraging my team to say, tell me, tell me that you are underwater. Tell me that you don't have time because I cannot solve for you if I don't know that you don't have time. I need to know that you are underwater so that I know that I need to go hire another person. Yeah. So that I know that I need to go advocate for more resources so that I know that I need to go get a contractor in the short term so that you can actually have the time to go do the thing that we need to in order for us to grow. And when I explained it in that way, they're like, Oh, that makes absolute sense. You're not just trying to throw another thing on me. I need to tell you what's going on so that you have the tools that you need to be able to advocate for me so that everyone can actually move forward together. Yeah. Yeah, that's really powerful. Might work on some of that myself. Always room for improvement. So through Insight's Career Network, I want to talk a little bit about kind of of the industry at large and the people who are in it and kind of, you know, the way they're feeling right now. So you are seeing in your role, I'm assuming, how professionals are processing all of this change right now, the AI acceleration, the shrinking teams, the expanding expectations. What are you finding that researchers are most anxious about right now, and where do you think that anxiety is maybe well-founded versus where maybe it's misdirected or even just overblown? What I'm seeing is researchers aren't sure what skills they actually should be focusing on. They're not sure, should I focus on learning ChatGPT or Claude, or should I focus on learning specific tools that have AI already implemented in them? And if it's the latter, how am I supposed to get access to those tools? How do I go and learn those tools? They're not sure, should I go learn storytelling or should I go learn Excel? Should I go learn about business or should I go learn about marketing specifically? Like there's this disconnect, I think, that is happening between what they think they, what they're seeing in job descriptions and what hiring managers necessarily are actually looking for. And when they're going into interviews, they're hearing, they're hearing something different than what they saw on paper in the job description. Interesting. Interesting. And so. They're coming away confused. Like, what are you actually looking for from me? What are the skills that I actually need to develop? I was talking to someone from, who works in education and on the university side, and they were saying their board, which is made up of people in the industry, will tell them, stop focusing on Excel and PowerPoint. That is like out the door. But then the students that come back from entry-level roles that come back and, and report back, say, why didn't you focus on Excel and PowerPoint? That's all my day is. I need to know Excel and PowerPoint. And so it's this, again, it's this disconnect of what do you actually need to know, especially at entry-level, mid-level, so that you can actually succeed in those roles and what's being put on paper versus what is actually needed in the workplace. Totally. Well, Z, before we wrap up, I do, I wanna do a quick Current 101, and that is our recurring segment where we ask guests two related but opposing questions. So here are ours today. What is one assumption that researchers still hold about their role that you think is quietly or, or loudly becoming outdated? And then on the flip side, what is a capability or a skill or a trait that you think is going to matter more over the next few years than people realize right now? I think one particular skill that is quickly becoming outdated is honestly writing questions, the skill of writing questions. That's the thing that I think the large language models of today are doing honestly really well. They're good. Yeah. They're, they're drafting really great stuff, and it's kind of surprising what they do. And so if you see your job as a researcher as being an expert question writer, that's not the skill that you're going to need moving forward. That's not an insights professional anymore. Yeah. The skill that I think is increasingly necessary is understanding a business. At a basic level, understanding what makes businesses function. So, everything from the C-suite, when you look at those roles, I think that is the core of what an insights professional needs to know now. How does finance work? How does marketing work? How does operations work? And how do they work together to actually move a business forward? Because the insights that you now are creating, generating, they need to tie into those business outcomes more than ever. 100%. Yep. So, that's the skill that I think we're missing now because we've long had the skill of diving into the data and doing all the analysis, and the tools are making it so much easier to do that now, that now our job really is tying that back to the business outcome. That's the thing that AI still is not going to do. That's the thing that we can do because we can see the nuance, we can see the politics in the business, we can navigate through that, and we can figure out how those insights and how to communicate those insights to that business outcome. What is it that a company needs to do to actually act on the insight to make the business outcome happen? I love that. And You know, I find sometimes when I raise similar issues in coaching and things like that with more junior researchers, I would never say there's pushback, but there's a little bit of like, how am I supposed to develop that information? And I think part of it, you know, is like, well, that is a lot of what LLMs can help us do too. It's also talking to your customers. But one thing that I often say is, how much do you know about the business that you work in? Yep. Because this is a business too. We have a finance department. Yes. We have a product department, right? And the more you understand your business, just, it gives you the fluidity of understanding cross-functional work more generally and will make you a better partner to, to your customers. Yep. Yep. If you understand the business that you work in, you will understand business in general. Yes, exactly. Yeah, yeah, yeah. Yeah. Well, to close this out, I wanna come back to this question of of how tools are changing, not just how we work, but how we think about careers. Common theme in our conversation today. If someone came to you through the Insights Career Network and said, I want to build a career in research or insights that's going to matter in, in 10 years, what would you tell them to focus on? I would tell them to focus on business basics and actually understanding what an insight is versus what does the data say? Because there's a huge difference between being able to say, oh, the data say that, you know, 40% of people didn't like this. Tell me why that matters. That's the insight. The insight is why does that matter? Why does that matter to the business outcome? 40% of people didn't like it, which means that you're going to lose profit margin because they're not going to buy the product. That they didn't like, right? And that product that you want to put on the shelf is going to eat away at your profit margin. That's a very different story from 40% of people didn't like it. So if you can figure out business basics so that you know why that 40% didn't like it actually matters to the business, that is where your research career is going to matter. Love that. I mean, like, and like you said, those are, they're so highly interconnected, right? Without the business basics, you don't have a way to do that work. Yeah. Yep. Awesome. Well, Z, I think that, you know, what I will come back to from this conversation is just how much the role of research is changing and expanding. It's not disappearing. It's asking more of us. It's asking us to, to really be, you know, thoughtful participants in the business that we work in, but it's also opening a space simultaneously for us to have a lot more impact. And I feel like the thread that kind of ties it all together, at least for me, is this idea that agency and like willing to be flexible and, you know, honest and transparent and be a hand raiser, you know, and be honest about things like, I'm busy. It's not that I don't want to do this. Those are the things that become the foundation for, for all of this change work. The tools will change, the workflows will change, but the ability to step into, tend to ambiguity and, and ask better questions and build something that didn't exist before, or draw an insight that has a true impact. That does feel like the work. So thanks so much for sharing your experience and your honesty about what this moment in our industry looks like. And to everyone who's listening today, thanks for being part of The Curiosity Current. We will catch you next time. The Curiosity Current is brought to you by AYTM. To find out how AYTM helps brands connect with consumers rumors and bring insights to life, visit aytm.com. And to make sure you never miss an episode, subscribe to The Curiosity Current on Apple, Spotify, YouTube, or wherever you get your podcasts. Thanks for joining us, and we'll see you next time.