Rethinking My Research Ops Project Timelines
Rethinking My Research Ops Project Timelines
Before Today’s Post…
Exciting news! If you’re interested in Research Ops I’ve got a new resource for you.
I just launched Research at Scale, a new podcast all about how to effectively run ReOps. I speak to other people in the Research Ops field to learn how they’re successfully scaling research in their companies.
The first few episodes are up and available on all your favourite podcast platforms. Go have a listen! 🎧
Towards the end of each quarter, I spend time reflecting on the work I’ve accomplished and plan for the next cycle. This year, I’ve learned that I need to be more comfortable creating longer Research Ops work timelines.
Shaped by Feedback
In my previous role, I primarily ran UX research (UXR) projects. One of the more challenging parts of the job was being managed by someone who had little experience with the UX field.
My manager had good intentions, but most of my evaluation boiled down to a single question: “Could you work faster?”
Over time, that feedback — and my lack of pushback to my manager — nudged me towards setting unrealistic timelines for projects.
I observed this when I was interviewing for new roles around the time I joined Zapier. I sensed that some of my expected timelines for hypothetical projects shocked interviewers: I’d been shaped by feedback, hardwired to try to deliver work in less than 50% of a reasonable timeline.
Delivering Research vs Delivering Services
Drastically re-scoping my projects was unsustainable in my UXR position in the long-term, but the pain is more acute when I try to rush Research Ops projects.
With UXR, I could rely on slightly less data (e.g. fewer interviews) and still unearth helpful — though incomplete — insights.
With ReOps, cutting corners means deliverables are less valuable to researchers, so the effects of short timelines are more tangible.
Good Research Ops work requires internal research, creating prototypes, gathering feedback, and iterating. In between these big work blocks are the time-consuming, seemingly invisible tasks: gathering context about current demands on researchers, communicating with cross-functional teams, and more. I — and others — can see the results of reduced time in any of these areas.
One Major Initiative Per Quarter
My new rule for Research Ops work is simple: one major initiative per quarter.
With this approach, I can prioritize more thoughtfully and also give myself enough bandwidth to deal with any ops-related fires that I have to put out.
Over To You
How do you structure your work? If you work in a quarterly cycle, what do you keep in mind when planning your projects?
I’m all ears: please reply and share your successes and failures.
Sign up to receive future posts via email. 📬