UX research as an internal platform: research ops, org design and outcomes

Henrik Mattsson · 00:09
Hi everyone, and welcome to the UX Research Rundown podcast. My name is Henrik Mattsson. I am the CEO of Lookback and your host for this show. And with me today, I have the one and only John Cutler, who, I’m a big fan. I’m sure a lot of people who are interested in building product and product management and all sorts of products and are on Twitter know about John, but we will get to know him even better. He’s actually a researcher from the beginning, so I don’t know how many people know that, but I think that’s pretty awesome and not very surprising.

And we’re going to talk about my favorite problem, which is how do we get people who are not researchers, or not people doing research, to engage with all the research that we’re doing, and build better products and experiences as a result of that. Because if we do a bunch of research and no one engages with it, then it’s very hard to change things. So thank you so much for being here, and welcome to the show.

John Cutler · 01:14
Thank you so much for having me.

Henrik Mattsson · 01:14
Awesome. So, as per ancient tradition, it’s been one season, we always start by asking our guests to give us a bit of their origin story. And I’m sure, especially the research part, and how you got into that and how you got out of that and all that stuff. If you could give us some background, please, that would be a great start.

From music and video games to UX research at AppFolio

John Cutler · 01:35
Sure. I dropped out of college and wanted to play music, and I had an idea for a video game, going chronologically now, but I think that was my first foray into product. I had this small company, and we made this game that was ultimately commercially a flop. So that’s kind of funny. But that kicked off a series of events. I was pretty lost in my 20s, but also doing fun things. I played with this band, and we toured around a lot. And I would do these various product-like roles and not product-like roles for a good decade.

So I got a late start in this, and then I started to settle into more legitimate product roles in things like ad tech and different media type things, different B2B things. And then, it’s been ten or more years, I moved here to Santa Barbara from New York City. And that was a big change. I was doing a little bit of consulting, I was looking for a job, and this started a series of working in B2B SaaS companies for the most part. And actually, that job was a UX researcher.

I remember at the time I went out to coffee with the head of design for this company, AppFolio, and she said, well, we’re looking for this researcher. Have you done that? And I was kind of like, no, I haven’t. And I started to do more stuff on it. And it’s really funny, I always talk to JJ about it, but I’m probably wired in many ways to be a researcher, but then I also have this product side. It was probably not the best role at the end of the day, because I probably should have been a product manager, but with this research bent.

But I loved it. I remember for the interview I prepared this heuristic review, and I was like, this is great. And I loved going through the stuff. But that was a good experience, because at that company, AppFolio, my role was primarily facilitatory. My role was to engage people with our customers. Obviously I did some nuts and bolts type work, doing moderated usability testing sessions and different research methods that I was learning and applying at the same time. But also I was the person facilitating kickoffs for things.

And JJ was very interested in doing design sprints, and we were trying new things. We read that Lean UX book, which is a really good book, by Jeff Gothelf and Josh Seiden. So it was cool being in a company that was trying new things at a time without a lot of baggage. It’s not like JJ was going in and saying, UXR must be run this way. It was a company with really strong product chops, and we were just trying different things. And it’s actually funny.

Fun fact: I was a Lookback customer at the time. A lot of the people were using a mobile web version of this product on site, doing maintenance repairs, and we knew nothing really about how they were interacting with the product. So I was very eager at that point to try to get the product set up, so we put a web wrapper around it and called it the app. And I think we were trying to integrate the SDK, and we were getting these calls going, and I have some amazing calls.

I was looking back at this, I have some presentations I gave at the time of people from the field talking about things, using Lookback. So yeah, early, early customer at that point. But ultimately I also had this product management thing. So I left there and I worked at Zendesk, and then this company called Pendo, which did analytics and onboarding things. And then my role recently, for four years, was at Amplitude, where I was working with a lot of our customers and future customers, helping them both with the product, but then also broader questions about how to, quote unquote, do product and use quantitative data in many cases.

But a lot of that also involved talking to teams about how they approached research, and other things. So it’s been quite a journey to get to this point. And then in four days I’m starting in a director role at a company called Toast, where I’m going to be working in what they call product enablement. And what I love about that is my peers: there’s peers in research operations and peers in design ops and peers in, roughly, product ops and all these different things. So we have this nice team of people doing this stuff.

So I’m sure I’ll be back in the game now. So yeah, that’s the long story, not so short.

Research as an internal platform: product enablement at Toast

Henrik Mattsson · 06:32
Oh, love it, love it. Awesome. I get so nostalgic when I hear these stories of early Lookback customers that worked with the product, when it was cool to just, oh, you can record a mobile device, this is awesome. A lot of things have happened, and that’s super cool. So do you think that your… Oh, I have so many questions. I think you have very relevant experience for what I’m interested in talking about here, but I’ll start with this. So in your new role now, and perhaps even in the role you’re just leaving, do you still think that you have mostly that facilitator role, or how has that evolved over time?

John Cutler · 07:14
Yeah, so I had a question with this career shift recently. I knew I wanted to be focusing internally. Do I want to get back in the thick of it, of product management, being a product manager on a team? Or ultimately, do I care a lot about the health of the overall environment, and thinking of what I do almost like a platform, facilitating and supporting people, enabling people within the company? And that was a hard question I’d ask myself, because being a product manager is really fun.

It reminds me of music a lot. It reminds me of being in a band with a group of people. There’s that sensation when you’re a product manager and you’re on a team. But then it’s one team. What would it be like to do things that supported everyone? And so I ultimately picked the latter approach this time around, and it probably will be more facilitation oriented. But I wanted to underscore that concept: in product management, there’s this idea of being a platform product manager. And I think platform is an incredibly good analogy here.

It’s an overused term. People say, we’ve got a platform. You don’t have a platform. But what I like about the word platform is the dynamics of what it means. When there’s a platform, you have many people who have different applications that they want to run, and you probably have to collect a lot of data for them, and then you need to synthesize that in some ways. So the analogy actually works: you have to collect this data, and you have a common source of stuff, and then you have to synthesize it for different applications.

When you think about product enablement or even research operations, you’re in the business of being a force multiplier for the organization, but you can’t treat everyone the same way. You can’t say, just do it this way, it’s the only way to do it. You have to be thoughtful about what people are trying to get out of it. So when you ask if it’s a facilitation thing, it is. And it’s also that idea of creating platforms within a company that help people do their jobs more effectively.

And not to jump ahead too much, but I think that a lot of researchers are struggling so hard to even get anyone to pay attention to their research that they don’t take a step back and think, okay, ultimately, the goal here is to help decision making in this company. And my goal is to think about how to creatively scale expertise and scale the information we have to everyone. I understand the instinct to protect the research craft, and I think it’s very important. But take a step back and think: I work in a company with 500 people, and what if I could uplevel everyone in terms of the decisions that they’re making?

It’s a balance that everyone faces, I’m sure. But these are some of the things on my mind, even in this new role.

Carving out space for research: three organizational tensions

Henrik Mattsson · 10:22
Yes, super interesting and spot on. It’s funny, I always tell my guests, we only have one podcast episode, we’re not going to be able to write the book on this, so don’t worry about covering everything. But seeing your Twitter production and your productivity, we could write the book on there. So if you would like to map out all of the challenges involved, organizationally and culturally, with these facilitation roles, in terms of carving out the place for research. Because this is a process that has changed a lot over time.

Just in the seven years that we’re talking about now, since you were a researcher, research is more part of the organization than it used to be. So people are arriving in this space. The engineers were there first, if we simplify, and then came the designers perhaps. So how do you carve out that space in a collaborative way? Because it’s not about claiming territory, although sometimes the rhetoric is a little bit like that. So how do you make that happen in that kind of magic way?

John Cutler · 11:34
The analogy that I give: even at Amplitude, I got briefly involved in education, and recently I was helping the team that was going to be responsible for community. And even go back to when I was at Zendesk, I was the PM of search. And search, it’s just like Google, right? It’s easy. So one way to think of this: community is a great example. You go into a company and say you want to do community. They say, oh, you mean user groups? I’m like, no, there’s much more to community.

Or you go in and you say that you want to do content, or you want to do evangelism, or you want to do education. Oh, education, it’s just like Salesforce Trailhead, right? Let’s just do it this kind of way. One thing to just bring out into the open is that in any specialized domain, there’s always going to be this balance of having to advocate internally about what’s possible in that particular discipline, how it can help people, what good looks like, why it’s important. There’s going to be questions about when to protect the level of the craft, versus maybe have a little less craft but spread it more broadly in the organization.

And everyone has that. And I think that’s the first thing to accept. People who run education teams have the exact same discussion. They go in and they say, well, education is this whole art and this theory. And guess what? It’s not just about courses. You have to create cohorts and community. So a deep education thinker has this whole laundry list of techniques, and then has to meet with the executive who says, it’s like Trailhead, right? And I think my experience with talking to a lot of researchers mimics that.

There’s those natural tensions. So that’s the first thing that comes to mind. There’s just a certain physics anytime you have an emergent area of specialization that not so many people know about. It starts with generalists, and then there’s a debate about specialization. The second thing that comes to mind is one pattern that I see in a lot of organizations: they’re still just coming around to the idea that there’s not just one motion and one way to run every single thing they do. And so this is not just about specialization, it’s about standardization and consistency versus flexibility.

So the first one is about the normal trouble that specialists have all the time. The second one is about the normal questions of centralization and standardization versus flexibility. So what you see with a lot of researchers that I meet is that there’s this battle where we want to try to be involved, yet not all efforts are created equally. Not all initiatives are created the same way. Sometimes it really is good to tell a researcher to go off for four months and do something. Many times it’s not.

Yet the company goes in and says, we must run just one way of doing all things. And I think for a lot of people I meet in the research ops space, this is their dilemma: they instinctively understand that there’s many different motions that they need to support, but they’re struggling to even get one way to work. So it’s like, do I standardize, and make it easier for the organization to understand what we’re proposing? Or do I decentralize what we’re doing and be more flexible, which might be more effective on the ground, but maybe not more effective at explaining it?

That’s the second one: standardization versus decentralization, building on the specialization thing. And then the final pattern that I’m seeing out there, when I’m chatting with people, is resolving the vast overlaps that exist now, where you have a research operations team and then a design operations team and then a voice of customer team. What the hell are they doing? Why do they insist on owning this stream of information? My friend Michael is at Figma, and he’s having to battle these things he’s doing in research and voice of customer.

But I think he’s coming to the realization, too. He’s like, ultimately, we need to start thinking about the analytics side of it. We need to be thinking about community. He joked that you’ll notice that some product leaders at Figma go on Twitter and say, what should we build next? And you could imagine you’re sitting there in either the research ops team or the voice of customer team or the other team at Figma, and you’re like, what are you doing? We’ve got this dialed in. So the final thing, which is the outgrowth of the first two, is that what you tend to see in organizations is that these highly overlapping things reach almost an inflection point, where suddenly people start asking, should they just be in one cohesive group that thinks about these types of things?

So I don’t know if that helps, but those are the three patterns that I’m noticing. They’re probably not new to anyone listening to this. If anything, I’m just reiterating the tensions that you’re seeing: the specialization stuff, the standardization stuff, and then the overlapping of emerging roles that causes both friction and advantages. Those are like the physics of this problem. And so I think it’s very interesting.

The integrator burden: who carries the glue work

Henrik Mattsson · 16:58
Yeah. No, I think a lot of people would recognize themselves in that landscape. That’s the world people are navigating. And it can vary from big companies to smaller companies to new companies, it depends a little bit, but it’s definitely something like that. And you can add other trade-offs to it too. A lot of research leaders I’ve talked to say that a lot of their work is about bridging: navigating this landscape, helping their team navigate this landscape, building relationships across this landscape, building alliances across this landscape.

But that’s not in their job description.

John Cutler · 17:40
How do you get any work done if you’re doing that? It’s funny, because I wrote this blog post called the Integrator Burden. And in that particular blog post I dig into this challenge, and it’s very interesting hearing different people. Some people said, this resonates so much, but I don’t want to be the glue person anymore. I’m too burnt out. I can’t be the glue person during the pandemic anymore. My natural instincts as a researcher were empathy and glue and shared understanding, and in fact, I’m maxed out.

I can’t do it anymore and do my day job of doing this stuff. So that resonates a lot. And I think this is what I’ve noticed about a lot of folks in research, and a lot of just more thoughtful… thoughtful is a judgment-based word, but they might just be more systems thinking types or whatever. There’s just a lot of burden that goes along with that particular work that can be difficult. I even remember at AppFolio, just being in the thick of things, sometimes you just see more of the organization than you might expect in those roles, which is pretty heavy.

Henrik Mattsson · 18:59
So I haven’t gotten a research leader to admit it. But sometimes they ask about who should carry that burden, and isn’t it a bit unfair that it falls on, let’s say, the research leadership? Because ultimately, and this is just the theory I have, I think that we’re moving into times when this idea that you can compete and build great products without having a sophisticated research practice and understanding, looking at all of this data, qualitative and quantitative, is an obsolete idea. Those days are over, and we need to do this.

So it’s in the company’s interest to make this happen. But the burden often falls on the research leadership, for example. It could be other functions too. Do you agree with that? And how do you think that different people in an organization should relate to that? And whose responsibility is it, so to speak?

John Cutler · 20:04
Well, I think part of it is just due to sheer exposure. I don’t think it’s malintent of the organization. And then I think another part of it is that most parts of most organizations do not slice across the org. So you’ll notice that people in human resources or people teams often feel that burden, obviously, or anyone who has insights and bridges across those things. So I think part of it is just a byproduct of that type of role. But I agree with you that ultimately it falls on the CEO, I guess, and other product leaders to admit that this is a part of their tool chest.

What I’m noticing out there is that with a lot of companies, there’s still this: I’m a product leader, I’m a CPO, so therefore I need a counterpart. I need a CTO. Okay, that’s great. And we’re going to create this triad, this trio, and it’s going to be great. I think people still just lump a lot of these other leaders underneath those other leaders. Yeah, well, we had the research thing. I think what we probably will get to, not in the next year or two, is a place where we won’t talk about trios as much as we’ll talk about the four or five heads.

And there’ll be someone who sits alongside those folks, who obviously partners a lot with design, but is thinking really holistically about insights, and has a very broad remit around qualitative and quantitative stuff. And I guess then the question is, how will design interact with that? Or will design try to hold back the design aspect of that versus the quant stuff or other things? I think that’s TBD. I think that’s the tension that you’re seeing in a lot of companies at the moment.

Collaboration, cognitive limits and Team Topologies

Henrik Mattsson · 22:12
Yeah. So, a quick follow-up on that. I have another theory. This is not me coming up with this stuff, I’m just observing some things. But I see, across pretty much every tool space, we’re moving towards more and more collaboration. If we take developers, GitHub and stuff like that, it started pretty early, for obvious reasons. And then designers were working in isolation for a long time. Then they got Figma and tools like that, where it’s very much about real-time collaboration. And that’s what we’re seeing also when we do research with Lookback, and we realize, hey, it used to be about recording sessions.

That’s not what it’s about anymore. There are some table stakes. You need to be able to record sessions. You need to be able to run the analysis software, etc. But it’s really about the live, cross-team collaboration. It sounds like a fancy speech or something, but it’s really coming into fruition with the help of technology, but also with the help of maturity in different companies. And I wonder if that’s something you also see. And what does that mean to our industry and the way that it’s organized across different companies?

Will we have a breakup of all of these silos, or will there be a counter movement, or what do you think?

In Lookback Teammates and stakeholders reply to timestamped notes in threads, so the discussion stays on the moment in the session. Learn more

John Cutler · 23:42
Well, I think of the work of someone like Matt Skelton, who wrote this book, Team Topologies. He’s very focused in that book on describing different teams. But he hits on the point that there is a limit. There is a cognitive limit, above which you hit points of cognitive overload and cognitive drain of the teams. And the interesting part of that book is, we talk about silos, and after reading that book, one says, well, a naturally occurring wall might be a benefit. Can you peek your head through it?

And so I think that what we’re going to see is much more thoughtful organizational design. What I mean by that is that at the moment, what you see is these very brute force matrixing efforts, or one dominant way that everyone is supposed to work. And when you think about Matt’s book, and if you want to research it, it’s actually a great book and I recommend it, he talks about enabling teams, and there’s value stream oriented teams, and there’s specialized subsystem teams. I love the words that he uses, because it gets you thinking: no, there’s not just one way to run this.

It’s not just either the matrix or functional groups. There’s ways to be extremely thoughtful about this. And that to me is the future of this, where the future will not be infinitely collaborative: cognitive overhead, interruptions every single moment, infinitely real time or anything like that. Because we just have natural limits. You cannot expose a group of six, seven, eight people to so much information, and the technology is just accelerating the rate at which we can either access the information or derive insights from the information.

But there’s a limit, clearly. And it used to be the limit was just the effort required to get the information. But now, with tools like Lookback and other things, the collecting of the data, and even synthesizing it to a point, is taking a little less cognitive overload. But you still have to process it and turn it into action. So I think what’s going to happen is we’re going to reach a point where the primary limiter is the ability to synthesize and utilize the information, meaning turn it into decisions and turn it into action.

And there’s going to be a trend of thoughtful org design where people respect that. There can’t just be one function or matrix model. So what would that look like in practice? It would look like you would have a research team that would divide itself into more platform-like, centralized, what we might call town planners. They’re the ones who can raise all the ships and get things to work across the whole company. And then you’ll have aspects of the research team that can almost parachute in, so to say, when there’s a specialized problem that needs to be solved.

And then you might have people, you see this evolution in marketing and marketing operations, that are just working all day on systems and making sure that the plumbing is working. Simon Wardley has this idea of pioneers, settlers and town planners. The words can be a little iffy, it sounds very crusading or whatever. But the interesting part about that is that the work of the pioneers is made possible by the work of the town planners. So you can imagine that in the United States, when they were going across the West in the westward expansion, Chicago was a hub, and it was run by town planners, and they made sure you could get the supplies you needed to go off and find California, or find gold, or do whatever you were doing.

Certainly there were people in California before. But you get the idea. What I’m trying to present here is that in practice, you’ll see much more nuance in the org design. And then I think there’s a physics to the problem, where you’ll still need to define relationships between groups and be more fluid, but there’ll just be more thoughtful processing. I don’t know if that answered your question or if I took it to a different place, but I think that’s the future. And I don’t think endless collaboration or endless real time is even possible, nor desirable, in many ways.

What will change how companies organize research

Henrik Mattsson · 28:12
Well, while you were saying this, I thought back to my PhD days. I did a PhD in economics, and there’s this German economist, Lösch, who said something like this. He said the only reason we can endure at all is because not everything rushes in, not everything happens to you all the time. And there’s definitely that cognitive limit. But this is super interesting. As a tool person, when I started thinking about these things, I was like, we’re going to fix this with the tool. The tool is going to fix it.

But then as I’ve matured, I’ve realized that this has a lot of aspects. It has these organizational aspects, it has these leadership aspects, it has these builders’ aspects, and it has a tool aspect. And what do you think are going to be the leaders of this? Is it going to be technology, product, organizational theory? What’s going to bring about this new order?

John Cutler · 29:14
Well, I think that it’s already happening, and it’s happening in organizations that have a mix of systems thinking and operational… we would call it an operations 3.0 approach, where they’re thinking more that standardization is not the be-all and end-all. And then I think it’s going to be about deep, passionate people coming from many different perspectives. It’s funny, because even within product, there’s the product design perspective, and then the design perspective, and there’s this overlapping camp of the UX perspective. Then there’s the research community, and then that overlaps with product in the discovery community, and on and on and on.

So I think that it’s going to be a combination of those traits: passion for the craft, passion for thoughtful approaches to operations, and then also just the sheer element of competition, when companies are getting soundly beaten by companies that have figured out some of these elements. When I talked to Michael at Figma, just the level that they’re even thinking about this stuff, and the thoughtfulness they’re putting towards some of these ops… And it’s funny, I’ve had conversations with product ops folks and then research ops and VOC people at the same time.

And is anything perfect? No. But that they’re having people going to work thinking about this is important.

Customer access, representative samples and research rigor

Henrik Mattsson · 30:46
Yeah, absolutely. Well, what role do you think that research is going to have in it? And when I say research, you can answer this as you will, either research the function or… What I see in our research on how companies research is that the act of engaging with user research, perhaps live observing something, watching a user struggle, becomes a uniting, a focusing force. Because that’s really what it’s about, right? You see the experience you’re building, and you’re in there, and you’re seeing it in action.

Sometimes product building can be a very theoretical exercise. You’re sitting with your team and you’re reviewing each other’s stuff, you’re reviewing each other’s code. But when you’re in front of the user who’s struggling with the real thing, it becomes this common force. Do you think that’s right? And what kind of role would that play in this?

John Cutler · 31:46
Well, one thing that stands out, maybe I’m just repeating what you’re saying in a way, is going back to my days doing research at this company called AppFolio. Certainly there was a larger team, but my goodness, the power of having a well-curated research panel of a thousand-odd people that were willing to fill out screeners, to be co-participants in the design of new features, and respond to different types of studies. Having that access and eliminating the friction. At the same time, this is actually a great example.

Many people are like, just contact any customer you want, all the time. We should be able to talk to any customer at any time. Great. Some companies haven’t even gotten to that point. That’s actually extremely difficult. The next level is to think, well, we know from a research perspective that just asking everyone any question all the time is not going to help us out. You want a representative sample. You want to engage the people in a participatory process. So that’s a next level thing. Great, we’ve gotten over the burden of, can people even get in touch with customers?

Now, can they get in touch with the right customers? And then it seems like there’s a next level above that. Okay, they’re in touch with the customers, but are we using the right representative sample of customers? Are we using the appropriate techniques relevant to the product challenge at hand? We’ve gotten the contact, we’ve made sure that it’s representative. Now, are we applying the correct techniques? And you can see how technology probably enables all these particular things. Many companies are just struggling with the dumbest problem: there’s some customer success manager who feels they need to sign off on someone calling the customer, and there’s no way to automate that.

Just mind-numbing problems. But once you’re through those things, and you get through the basics, and then you start thinking about representative samples, and then you start thinking about the right techniques, I think that the next level after that is the refinement of technique: knowing when to go really super deep in terms of the discipline and rigor of what you’re doing. There are plenty of organizations that seem to have a research team, and they’re always advocating, and product seems to enjoy what they’re doing. Product is grateful, they love their researchers for doing it.

But there’s still not a perception of when and how to apply high rigor to the problems that they’re doing. So we could go on and on across this progression. I don’t know if it answers the question specifically, but I feel that those are the steps that are necessary. But one thing to keep in mind is that it’s a progression for every company, and you reach a plateau, and then you’ve got to think about the next level of it. So the companies that have incredibly easy access to customers, at a certain point, if you sit on your laurels and you say, well, we’ve done it, we figured that out, we don’t need to improve what we’re doing anymore, that seems to be where the trouble happens.

But going back to what you said, how many teams don’t experience that magic? That’s what I loved about Lookback at that time. Oh my God, how amazing was that? How amazing was it to get insights into someone interacting with the surface area of the product in a more natural way? But this is my point about the rigor thing. If you go to someone who does deep ethnographic research and understands all the literature behind it, it’s funny, they’ll look at that and they’ll be like, oh, where is your ethnographic study plan?

What are you doing? And you’re saying to them, hey, I understand all that exists, but this is magic. I’m talking to you as a product manager, and this is magic. No, it’s not magic. Back at the university when we did this, I will cite study X, Y, Z, published in 1994, that this is not a good ethnographic study. But back to the point: just speaking as a product manager, I think that sometimes researchers underestimate the very basic connections that can be created. And they’re right to be suspect of it, because it could go in the wrong direction.

But I don’t know, it’s just magic. Putting my PM hat on, it’s just magic.

Advice for research leaders: think in outcomes

Henrik Mattsson · 36:26
Yeah, yeah. No, totally. And it’s very unexpected too. It’s hard to plan for. Sometimes it just happens, and you need to take care of it. Cool. I would love to just keep talking forever and ever, but I’m going to try to reach some sort of conclusion here. So if we take the perspective of a listener now, who is in this field, an up-and-coming research leader, and thinks, well, this is an exciting future, there’s plenty of work left to be done here. Do you have any advice on how to navigate this, if you want to be at the forefront of this development that you’re talking about?

Who do you ally with in organizations? What do you read? What do you do to bring yourself closer to that?

John Cutler · 37:16
Well, to follow on the theme of what we’ve been talking about, I think you pointed it out: we were talking about commanding a certain high ground or space in the company, and how there are advantages to that. But that’s ultimately not the final goal. And I think that’s what I’m noticing. I speak to some design leaders, and they’re like, okay, it’s taken six years, we finally got the kind of respect we need. And they’ll even talk sometimes about installing processes that they realized were not really optimal, but they had to do it to just get people going through the motions.

And I think what this brings us to is, and not to try to interject with another model where maybe the researchers are like, why are you telling us about that model, but to me it’s thinking of these as internal products. There is that element of: are we truly succeeding? That’s what outcome-driven thinking is. And I think it’s so easy, if you’re doing research, to be like, we did what we could, we delivered the study the way we said we would, or we got Lookback and so on.

Or, we did the best we could to tell product what they should get up to, and they ultimately didn’t take our advice. It probably sounds cliche for me to say it, but I think it’s preparing yourself for a career situation where you’re essentially owning a platform. You’re owning an internal product that’s meant to uplevel the whole organization, and asking: are we doing the job? Are we succeeding from an outcome-driven standpoint? I think that’s very uncomfortable, but I think that’s the step that a lot of leaders need to think about.

It’s almost like once you’re at the seat at the table, then the real work starts, which is the most depressing thing to say. You’ve been working for ten years to get the seat at the table.

Henrik Mattsson · 39:29
Yeah, it’s almost like a generational thing there. I think about the generations, my grandmother and my father, who put me in a position to do something meaningful through all their hard work, but they wouldn’t get any credit for it. So there’s going to be some generations that build it up.

Who gets credit for UX research’s foundations

John Cutler · 39:47
I was thinking, to just add one thing related to that. I said all that, but I wanted to caveat it by saying there’s a huge problem right now with the product world: the product world takes credit for the hard work that’s been put in place by a lot of design folks or other folks, where they say, we’ve just reinvented this new thing, and it’s great, we’re going to reinvent UX research. I wanted to be really clear: when I’m talking about adopting an outcome-focused mindset, I’m not asking people to succumb to the buzzwords of product or whatever.

We can remove the word product and just think about outcomes. I’m seeing that that’s the next progression. But a lot of these advancements in UX research were on the shoulders of people who are not really getting any credit for it. And meanwhile, orgs are reinventing UX research from the ground up. That bothers me a lot.

Henrik Mattsson · 40:52
Yeah, totally. But I do think, on the positive side of that, you can call it product or whatever, but I’ve talked to other research leaders who’ve said the same thing: researchers actually have all of the tools it takes to understand how a product is actually performing, and what to do about it. That’s the job, right? And it’s just applying those skills to the product that is research within the company.

John Cutler · 41:25
That’s a great way to put it, and that’s what the best folks are doing too. I talked with a research leader recently, and they’re like, we’ve done a research study on research at the company. I love that you bring that up, because all the tools are in place: the systems thinking, the outcome centricity, connecting with people, being thoughtful about it. I would say that some of the additional tools, like this operations 3.0 or the Team Topologies stuff, thinking about org design, might not be in the wheelhouse of a lot of research folks, and certainly not in the wheelhouse of a lot of product folks either.

So that’s no judgment. It’s just that, if the goal is to apply that level of thinking to what you’re doing, beyond saying, our analysis of the situation is this, and here’s the opportunity areas, which would be the common thing, the next thing in the product thing is: and we are going to try this for this outcome, and then we’re going to reflect on the outcomes. It’s tacking on that little part at the end. That’s important.

In Lookback Link each finding to the research goals it answers, so the team can see which questions research has settled. Learn more

Henrik Mattsson · 42:23
Yeah. Awesome. Wise words. I’m going to stop us there, John. I could talk forever, but thank you so much for coming on the podcast. It’s been a pleasure.

John Cutler · 42:33
Yeah, this is great.

Henrik Mattsson · 42:35
Awesome. An honor to have you. And we’re going to see each other on the Twitters. And also follow this podcast season. This is season number two, and there’s been a lot of great leaders on season number one, too. So have fun with it. Happy researching. Be kind, and take it one day at a time. Take care.

John Cutler · 43:00
Awesome. Thanks for having me.