How to find opportunities to incorporate research into existing business processes
Researchers & Designers bemoaning that we don’t have the proverbial seat at the table. We aren’t seen as equal partners to functions such as Engineering, Product, or Marketing, so it’s hard to have the level of influence we want. We’re viewed as a support role and as a service provider, not as a strategic resource. There are debates about where UX should sit in the org and who we should report into to have the most impact. We’re getting pigeonholed into either very early stage projects (think Market Research) or very late stage projects (think Usability Testing), and some argue it’s because we’ve been doing the wrong research.
Most stakeholders have a fundamental misunderstanding of the value Research can provide.
It’s a tale as old as time (or, at least, as old as 2012). But why is it happening? Where’s the root of this misery? I think it’s indicative of a fundamental misunderstanding of the value research can provide. Companies build Research functions with a preconceived notion of what Research is and does, and most Researchers let others dictate how they work. The question shouldn't be “when should we do research during our development process?” It should be “how.”
The way to answer the “how” question is to show how we can provide value at each step along the way. We need to learn to speak their language and see the challenges they face in order to be good partners and tell them how we can help. We need to understand the business processes we interface with and clearly communicate how we can support those processes.
Depending on who you’re most commonly working with, the stakeholders and processes you need to align with will vary. Two of the most common teams Researchers work with are Product Delivery (which includes Engineering, Product Management, Design, etc.) and Marketing, though of course you might be more closely aligned with Sales or Customer Success. In each of these cases, there are established patterns and processes that dictate how work gets done:
Hopefully, you already have some idea of how this works at your company based on the interactions you’ve had and the projects you’ve completed, but if not, start by digesting all of the existing documentation on this. Having a basic understanding of both the high-level concept of a lifecycle as well as how it works at your particular company will make subsequent conversations go much smoother. Make a copy of their diagram/flow (or, if they don’t have one, make one for them 👩🎨) for you to take notes on as you dig deeper: this is the foundation of our integration plan.
Once you have an understanding of the process, the next step is to talk to people. Talk to leadership for a high-level understanding of why the process is the way it is and to the individuals who execute the cycle to get into specifics. And when I say specifics, I mean nitty gritty details.
Oftentimes, leadership doesn’t have a clear picture of the reality of how their teams execute, so having this bottom-up knowledge is just as important as top-down.
You can approach this like any other Research project. Start by identifying the context, objectives, and outcomes:
Talking to teams should be the first thing you do, but it’s often just as valuable to observe the cycle a few times.
As we all know: what people say and what they do can sometimes be very different, plus it’s rare for any particular team/project to perfectly follow the documented process.
Understanding how it manifests for different sizes and scopes of work will help you craft a realistic proposal later. If you have multiple distinct teams, you also need to understand the differences in how they operate so you aren’t proposing something that’s completely untenable for anyone.
All of those insights you gathered about the reality of how your partners work is invaluable for two key reasons:
What you might experience is, upon sharing your insights with leadership, they’ll want to make changes. That’s great! While the original purpose of the research was for you to learn how to integrate with the process, there’s no reason why it can’t provide additional value. Make sure your proposal adapts to any changes in the process: there’s no point in proposing something that’s out of sync.
When it comes to crafting that proposal (something I’ll talk about in-depth in a later post), there are a few key things to keep in mind that can help steer you toward success.
One of the most important things to consider here is flexibility. Your goal isn’t necessarily to have the perfect solution or to give complete confidence in every decision moving forward. If your proposal is too pedantic, people will ignore it. If engaging with you slows them down too much and causes deadlines to slip, people are either going to find shortcuts to work around you, or fudge the data to get the response they want.
When I was integrating Research into Auth0’s PDLC, we went through a few iterations to find the right balance. We kept running into situations where a set of methods didn’t quite work for a given project, so it felt dumb to make teams go through the motions (which, ultimately, devalues Research).
Instead, what we ultimately settled on was to come up with a list of questions for each step of the PDLC, and we left the “how to answer” part to be determined for each project. After all, when it comes to research, “it depends” is one of our favorite responses. 🙃
This might take a bit of a stretch for you, but you’ll need to think about creative ways to apply the methodologies you know and love to different audiences and different research questions.
There’s no reason why we can’t provide insights about what makes a good qualified lead the same way we can answer questions about end-user personae.
Research is subject agnostic, and while you might need to learn a bit more about the objectives you’re trying to drive (e.g. prioritizing ad spend is very different than prioritizing a backlog), the core practice is the same.
This is also an excellent opportunity for co-creation. Work with senior stakeholders to come up with a good set of options and requirements for each phase. Bringing others into the process not only helps educate them about what Research can do, but their domain expertise also supplements your expertise of the craft of Research.
Doing the work isn't enough; you also have to get people to listen and actually do what we’re asking them to do. Without going too far into change management and building influence, you need to show impact over time. Do good research and show the value you can provide in areas you’re already working. Develop research champions, and then work with those champions to pilot research in a different phase of the lifecycle you aren’t currently working in. If you’re already fully integrated with, say, the PDLC, use that as a launchpad to start conversations with Marketing about how you can work together. Tackle this piecemeal, using each success as a case study for future integration opportunities. Don’t try to boil the ocean.
Building flexibility into your proposal is a sign of being a good partner and will help you gain some credibility.
Pair that with a few high-impact research projects and soon you’ll have enough leverage to create concrete checkpoints or requirements to involve Research. At Auth0, concrete data was required to move any project through the PDLC. The scope of the data needed would scale with the size of the project: smaller projects generally used existing data, whereas major initiatives would often require multiple new research studies.
The added benefit here is that, by integrating with existing processes, it becomes much easier for you to forecast your workload and build your Research roadmap. Win-win.
The original outline for this post has an entire page of questions you could/should be asking for each phase of the PDLC. The goal is, on top of giving you the theory, to provide practical examples of how to apply the framework to different lifecycles. That's exactly what I cover in Part II.
Check out Part II and swipe some free Notion templates to help you get started.
Brad (they/them) is a UX Leader, User Researcher, Coach, and Dancer who's been helping companies from early-stage startup to Fortune 500 develop engaging, fulfilling experiences and build top-tier Research & Design practices since 2009. They have helped launch dozens of products, touched hundreds of millions of users, managed budgets ranging from $0 to $10M+, and coached hundreds of Researchers. Born in Buffalo and currently based in Brooklyn, NY, Brad dances with the Sokolow Theatre Dance Ensemble and Kanopy Dance Company, co-organizes the NYC User Research meetup, and served on the Board of ResearchOps from 2018-2021.
