The Evolution of Research Operations at Spotify
Enjoy our companion playlist for this article:
From Participant Recruiter to Research Ops: The Evolution of Research Operations at Spotify
Nine months ago, a posting on our internal job board caught my eye: “Research Participant Recruiter.” At the time, I had been at Spotify for a year and a half managing the sales support team and operationalizing workflows, but was hungry for a new challenge. This Participant Recruiter role was meant to provide logistical support to Spotify’s User Researchers in setting up research sessions. Historically, the Senior User Researchers and managers at Spotify developed processes to manage research setup while simultaneously designing and running research sessions. However, as the team grew, it became challenging to upkeep these processes on a global scale. The idea behind this position was therefore to have a dedicated resource to develop and execute research setup processes, ultimately allowing the User Researchers more time to focus on their craft. Having worked as a Research Assistant in the Schacter Memory Lab at Harvard and pursued undergraduate degrees in Psychology and Music, this role looked to be the ideal marriage of my educational and work experience. I was intrigued by the notion of blending my passion for research, process, and connecting with people, and decided to pursue the opportunity further.
Little did I know when joining the team in late January, this Participant Recruiter position would evolve into what we now know as Research Operations. My job over the next six months would therefore require defining the what that meant for Spotify and then beginning to execute on that vision. It was through this exercise I’ve come to understand that the potential scope of Research Ops is vast, and therefore requires working closely with the team to understand their needs, and to develop and communicate a plan of attack that is both realistic to existing ops bandwidth, and flexible enough to evolve with the needs of an organization.
As with any new job, I spent the first few weeks engaged in discovery conversations with the team I’d be supporting. In the spirit of research, and in hopes of uncovering the existing landscape and processes that needed to be developed, I approached my initial conversations as in-depth interviews, or meta user research sessions, with the Researchers and their managers. I compiled notes after each session, identifying common points across the team. My initial conversations revealed a vast array of additional challenges for the team that extended beyond research setup, ranging from vendor onboarding, to a lack of documentation and resources, even to a need for community and knowledge sharing. In other words, asking the simple question - how can I best help? - revealed that the scope of the ops role I was hired for only addressed a subset of the team’s needs.
As Kate Towsey mentioned to me in a recent conversation, any single focus area of Research Ops can only be thought of as a piece of a larger pie, in that discussing one piece inherently implicates one or several others. For instance, even the most seemingly simple topic, such as recording a usability session, opens a floodgate of operational questions that span the entirety of the research lifecycle. For instance, once the participants are recorded, their PII is retained, which therefore requires working with legal to develop a consent form for participants to sign, and even determining and documenting a digitized process for consent form signatures. Then, once recordings exist, you’ll need a strategy for video storage and retention, and even a set of tools to analyze videos and share the insights generated. And, on the most basic level, you’ll need to find those participants through recruiting. This exercise demonstrates that each operational element of the research process is interconnected and therefore cannot be thought of in isolation.
My analysis and discovery period with the User Researchers quickly made it clear that in order to appropriately support the team - or in order to address the whole pie - I needed to broaden the scope and function of my role - from Participant Recruiter to Research Ops.
This realization meant defining how to approach a seemingly endless set of operational questions. With the help of our Design and Product Insights Ops Lead, I was able to design and outline a phased approach in a Trello board. In the first phase, we identified the low-hanging fruits I could tackle in a 3–6 month timeframe, removing some of the time-consuming operational tasks for Researchers, such purchasing participant compensation, or obtaining physical consent form signatures. To remove these time-consuming elements, I implemented digital signatures for consent forms and a Trello board for research setup assistance. But there were also questions that needed more in-depth answers. To address these, I therefore planned two additional phases of work to refine my initial processes, and then to test and implement sophisticated solutions such as a strategy for video storage and retention. This phased approach was valuable in helping me to make a quick and tangible impact on the day to day needs of the Research team, while still leaving room for iteration and improvement.
Although helpful, this approach helped me realize that even with this structure one person alone could not address every piece of the Research Ops pie. Ideally, ops could tackle the higher-level theoretical questions, while simultaneously managing research setup for our 25+ User Researchers. Because there is only one me, I realized that as important as it was to establish where my work started, it was also critical to have clear guardrails of where it stopped. To accomplish this, in rolling myself out as a recruiting resource, I worked to define what types of studies I supported, the markets where I supported them, and how I would divide and conquer each of the tasks. By starting with a tightly defined scope, I was able to simultaneously execute work setting up research sessions while also iterating on process improvements such as digitizing our consent form signature flow. But this was not to say that the scope of my role wouldn’t evolve over time. Rather, I emphasized that although there were opportunity areas for expansion of ops support, this starting point was manageable with our existing resources.
Of course, no level of planning can prepare a person for the ever-changing tech and research landscape. While I’d planned to address the higher-level questions such as privacy and lab builds later in the year, updated European privacy standards and two new Spotify offices opening in London and New York meant being flexible and building strategies earlier than expected. This helped me to understand that while having a plan of attack is helpful, it’s critical to iterate on the plan based upon the reality of the team and the company’s broader needs. This realization has reinforced the fact that priorities may shift over time based upon the needs of the organization as a whole.
These past past six months have therefore been as much about defining and communicating the scope of Research Ops at Spotify as they have been about executing on team needs. And as much progress as I’ve made in defining my role, my understanding of Research Ops is ever-evolving.
In early March, I had the pleasure of being introduced to the industry Research Ops Community on Slack. As the sole proprietor of Research Ops at Spotify, it’s been wildly helpful to socialize challenges and ideas with people who face similar questions. But, perhaps most importantly, these conversations have shown me that while my initial approach was designed around the needs of the research team, it was also entirely specific to the structure and function of our research organization at Spotify. In other words, in engaging with members of the community, I’ve learned that though there are common areas we all work on, the needs of research teams we support may vary depending on the larger organization. For instance, due to the work of the Researchers and leads team before I joined, research is seen as invaluable to our product lifecycle at Spotify. The operational needs I face are therefore different from those of an ops person at a startup, whose main focus may be selling in the importance of embedding research in product development. It is only in coming together, then, that we’re able to get closer to a holistic picture of the role ops can and should play in various contexts. I look forward to continuing to partner with the community to share our experiences, and to further refine our definition of #ResearchOps both within organizations like Spotify and beyond.