How not to do “theoretical” research

Make your research more impactful

Nov 19

Let’s clarify one thing - theoretical research is not always a bad thing. Sometimes the timing is off, or a team may not be ready to implement things found from research. In this article, I’m going to talk about how I avoid research insights being shelved or having limited impact.

Photo by Nadir sYzYgY on Unsplash

1. Go for the long term instead of short term (or a combination of both) - this ensures that it’s evergreen

When something is evergreen, it has multiple applications. It can be used by many teams or different teams. The effort to return ratio is higher. That’s not to say make everything big and broad for the sake of doing so. Figure out other use-cases for the data you are collecting.

For example, at Zendesk, I needed to help a team figure out appropriate terminology and labelling. Due to the visibility of the project and the research method used, it was important to have a large sample of responses. This was done via a survey emailed to many customers. At Zendesk, we want to ensure a good experience and not bother customers unnecessarily. Since we were already sending out a survey, we included some additional questions. The responses would help us inform other broader initiatives and the product roadmap. It was piggybacking on something short term, while also servicing our longer-term needs. This bonus research can be used when teams are kicking off projects and need a general sense of our users.

2. Have a hypothesis to give direction to the project

Avoid doing endless research with no goal in mind. Ultimately your research should help to answer a short term or long term business question. It begins with turning it into a hypothesis. An example of a hypothesis might be "what needs do agents have when they are handling multiple types of customer support channels at once". It is slightly scientific in nature, but you'll notice it's not a thesis hypothesis.We used this hypothesis to design early versions of the agent experience. It helps to guide the research along. Ultimately it doesn’t always have to be a positive outcome. If research helps to determine that something is not actually a problem, it is valuable as long as it is early enough.

3. Timing is key

Ideally, you want your research to be timely so it’s not delivered too late for decisions or course corrections to be made. Sit in on planning meetings, get a good sense of long-range planning, look at trends and other sources of data (link article) so you have an idea of what direction the industry is heading. It helps teams avoid doing validation during discovery and discovery during validation. There’s a 9 month planning period that happens at Zendesk, I make sure that teams know there are researchers at hand to help them with their area and researchers get a sense of assumptions made to push that planning ahead.

4. Getting stakeholders involved early and figuring out “what keeps them up at night”

Half a researcher's job is to help with the interpretation of what questions a team might need. There’s what people ask, and then the surrounding areas of that topic. A good researcher doesn’t only think about execution but also about providing value. It’s a bit meta but it’s not solely external user needs you need to discover but internal ones too. We use a planning document to outline project goals. We also conduct stakeholder interviews to find out all the context and concerns. For the research that we did to inform designing the agent experience, a lot of time was spent on speaking to multiple stakeholders and identifying them. Here are some example questions we would ask:

What worries you about the project? (Ie the “what keeps you up at night question?”
Who else should we be talking to about this project? (Helping to discover stakeholders to avoid mid-project changes)

Also critical is using these interviews to identify an early advocate for the project and work with them closely. They should be someone who is keen on research and is more likely to put in place the findings.

5. Writing it with your audience in mind

Firstly start with an executive summary. You want to summarise the essence of the project for those who are time-poor and then the details for those who want to dig in. From your stakeholder interviews, you can understand the business context also. Use the same terminology as your stakeholders. Align your findings to what they measure e.g. new users, user engagement, reduction in churn, increase in spending. One mistake I’ve learned is careful labelling your report by the temporary internal project name. It makes it harder to find later, and less likely to be referred to again by other teams. It dates the work much faster. You might want to include the feature or something more evergreen in the title itself.

6. Make sure that research is everywhere

If a tree falls and no one is around to hear it, has it fallen? By having research everywhere and it’s easy for teams to share ensures that it’s circulated widely. The more often and wide your work is circulated it’s easier to refer to and use. Consider different formats depending on how information is consumed. Present the work, record the presentation. Bring up your team members work if relevant in those early context meetings. Have those stakeholders interviewed earlier on to advocate that work. Later on, look at tying the research work to something that was released or improved.

7. Treat research as something to be continuously iterated upon

Follow up with them on how they used the research, what was useful, what missed the mark. This could be done as a feedback form sent to those who got sent the research outcomes. If asking for feedback, be prepared to take it on board or experiment. Update those stakeholders on what was implemented or changed so people can believe in the process.