Finding the balance: How we prioritise research at Deliveroo
The Research team at Deliveroo is pretty new, and very small. We began when I joined, in January this year, and currently there are 2 of us (soon to be 3!). There are 8 product teams, so we’re pretty busy!
Managing priorities
Before Deliveroo, I was used to carrying out research as part of a single product team. I was aligned with one roadmap, worked almost 1:1 with a Designer and Product Manager, and was constantly up to speed with what was being built and iterated upon.
One day, we hope to have a similar set up at Deliveroo. But in the meantime, I’ve been faced with a brand new challenge — how do you co-ordinate research across all these teams if you can’t be in stand ups with them, sit with them, or work together sprint by sprint to iterate towards a design?
At first, our biggest priority was to give each team something to help them understand their users. Since there wasn’t a dedicated researcher before I joined, the teams had really big contextual questions that they desperately wanted answers on: What is it like being a restaurant using Deliveroo? What is the worst thing to go wrong with your order as a customer? When and why do people choose to order from Deliveroo?
So we started a research Trello board, with two columns — one for huge, contextual projects, that would give us heaps of insight at a high level (projects involving field visits, journey mapping, diary studies); and one for smaller, focused projects, that would help with the direction of the product or the design of a flow that the team were working on there and then (e.g. usability testing, remote research, phone interviews). We set up a monthly meeting at which Product Managers and Designers would ‘pitch’ for research resource for that month based on what was coming up in their roadmaps.
For a while, this seemed to be working pretty well — all the teams were really involved in the research we were doing, and super keen to use the findings in determining changes to make in the product. We were managing to get pretty good coverage across all of the product teams by sticking to priorities defined in the meeting. It was also great to be able to build up understanding that spans across all our users. If we see a problem in a restaurant for example, we’re able to relate that to our knowledge of how it’s likely to affect customers, drivers, and internal operations.
“The researchers have so much to do, don’t bother them!”
But then, we started to see that working in this way was causing some problems. We were enabling a team to see more than they’d previously been able to about how they could improve so many areas of the product. We were giving them new ideas to explore, and insight into the current mental models and needs of their users.
And then, we were walking away. We were switching to our next priority — a different context, a different set of users, another product team. We weren’t able to help them refine the ideas that they had, or test whether a design solved a problem we’d uncovered. We weren’t around for those quick questions about something we’d touched on in our findings but that needed more context.
We also started to realise that people felt it wasn’t possible to approach us outside of our meeting. The Trello board has such an incredibly long list that rather than giving the flexibility we’d hoped, it was making us look totally overloaded. It felt like we were unable to take on last minute research outside of the prioritisation meeting.
We needed to work out how to support teams in a way that comes naturally when you have a Researcher embedded in each team.
Finding a balance
So now, we’re trying something new. As well as prioritising large projects on our board each month, we’ve left ourselves some space for more spontaneous research. At first, we’re trying out working closely with the restaurant team, spending an afternoon every week with them taking their ideas out for quick testing, or visiting restaurants to get some questions answered that will feed immediately into product changes.
Earmarking a specific afternoon a week for a team has been working really well. They know that this time is dedicated to their work, which has meant they feel comfortable approaching us with research questions that would otherwise have slipped by.
We’re going to try doing this with all the teams. Once a week won’t be the right frequency for every project, but we’re going to try new ways of showing that we’re reserving some time each week for research that needs to happen on a day to day level, and doesn’t feel right being raised in a big monthly meeting.
Of course, this is a short term solution. We’re also moving more and more towards a loosely embedded structure — a researcher for each product area, who is able to attend all team meetings and work closely with the team on carrying out research throughout product development.
We’re looking for more people to join our team so that we can start moving in that direction! If you’re interested to find out more about how we work, please get in touch with me. You can also apply to join our growing team here.
