Should Research Ops Report to UXR or an Ops Function?
On the Scaling Research podcast this week, I chatted with Kate Towsey about how to grow and mature a Research Ops practice. Have a listen below. 🎧
One of the numerous benefits of hosting the Scaling Research podcast is the divergent thoughts that trigger from my conversations with guests. My subconscious is constantly processing and connecting ideas from these chats.
An area that I’m looking to explore in the near future is ReOps reporting models. Should ReOps sit within UX research (UXR)? Or perhaps a wider Ops function within the Design/Product org makes more sense? When does one approach fit better than another?
As I consider Research Ops at Zapier, much of my work affects product managers (PMs) and designers. Does it make sense to have a separate, disconnected person with a similar role for Product and Design?
Part of me says Ops work should be connected:
Whoever handles UXR tooling could (surely) help with Design tooling
The person in charge of the UXR budget planning and tracking could easily add Product or Design budget to the mix
Then, another side of me whispers:
UXR is vastly different from Design and Product
Does a central Ops service scale as UXR, Design, and Product mature?
What Do You Think?
I’m nowhere near an answer here, but I’d like to hear your opinion.
How have you set up Research Ops? What are the benefits of your reporting model? Please get in touch and let me know. 🙏🏾
Sign up to receive future posts via email. 📬
Photo by Javier Allegue Barros on Unsplash