Posted by Ray Poynter, 22 November 2020
There are two key requirements for most research today – faster and easier. There are other useful things too, such as better and cheaper, but the two key requirements are faster and easier.
Why Faster – what are we racing against?
If we look at research from ESOMAR, NewMR, GreenBook etc we see that most research is tactical, it is part of the management of businesses and projects. This means that research needs to operate at the speed of business. If evidence-based decision making is going to grow, the evidence has to be available in time to help with the decision. What is research racing against? It is racing against the point where the business needs to make a decision. The more research is used to help make decisions; the faster research will need to operate.
Why Easier – easier for whom?
It needs to be easier to produce and easier to use – but for different reasons. The research needs to be easier to produce because it needs to be faster and, in most cases, it can’t become more expensive in order to be faster. This means producing the research with fewer people working fewer hours per project – which means easier. The research also needs to be easier for the users because the trend, as shown by the research mentioned above, is for the democratisation of the research process, i.e. the users of the research are increasingly unlikely to be familiar with research, with research methods, and research terms. The outputs need to be in forms that are useful to the people who are going to receive them and apply them.
How do we make research faster?
This will vary by company and by type of research project, but the process of finding out how to make it easier and faster is the same – and has been established since the days of Adam Smith in the 18th Century (see The Wealth of Nations, 1776). The first step is look at the process and identify where the problems are. For example, where are we dependent on a small team? Where are the holdups? Where are we using skilled people to do clerical, cut and paste type jobs.
A typical set of processes would include:
- Better statement of the initial problem, knowing what is supposed to be produced and what success will look like.
- Using standardised components to be able to build solutions from tested processes (think Lego, you build a wide variety of things, from standardised bricks).
- Fix problems at source, not later. For example, can you improve the quality of the data you receive, rather than having to clean it later.
- Automate the processes that are slow, error prone, and tedious – for example reduce cutting and pasting data from one place to another.
- Design the outputs at the start of the project, ideally using standard templates (again think Lego).
How do we make the research easier?
In terms of producing the research, the steps that will make it faster (see above) are the ones that will make it easier. In terms of making the research easier to use, conduct user research with the people who actually use your results. What do they need, what do they currently call things, and what do they understand? Using this knowledge, design outputs that give them what they need, in their language, with guardrails. (Side note, researchers conduct too little research with the people who use the research – just like the cobbler’s children who had no shoes.)
Does that mean the research has to be less good?
This is a risk, but forewarned is forearmed. A lot of the research I see at the moment is not great. The surveys and discussion guides are often written from scratch, by relatively junior people, without reference to best practices. By shifting ensuring that 90% of projects use methods that have been validated and documented the faster, easier research will actually be better designed. Perhaps the single biggest complaint about research from clients is that the results are not insightful and do not provide actionable advice. When teams use systems to process the data, use automation for the heavy lifting, and follow story-finding principles they are more likely to produce quality outputs, and they will be faster, and it will be an easier process.
Faster, easier research does not need to be less good. Put in place a better problem definition, use validated methods, receive better data, apply story-finding processes (utilising automation for the things that can be automated), and create outputs that match what clients need and you will have faster and easier research that is also better.
Is there a role for Slow Research?
The slow movement started with Slow Food and was popularised by Carl Honore in his book In Praise of Slow in 2005. There is a need for slow research and here are just a few of the cases:
- Major strategic projects should be slow enough to allow the thinking to develop. In fast research the answer is usually known in advance, it just needs quantifying. But when we are considering new ideas, paradigms, and alternatives we need time for our thinking to accommodate new connections and consider new consequences.
- To separate short-term effects from long-term effects. There is a strong argument that brands, marketers, and researchers have become too fixated on short-term effects (e.g. clicks and downloads) and insufficiently focused on long-term effects, such as the connection between brand values and price-elasticity. This point is well illustrated by Les Binet and Peter Field in the The Long and the Short of It.
- Where longitudinal research is required. To understand issues like brand loyalty, churn, paths to purchase etc you need to research over time. What is more, that research often needs to be longitudinal (i.e. following the same people) instead of cross-sectional (using new people with each wave). Clearly, if you want to follow the same people for several months or years, it will take time. Here is a blog I wrote on the need for longitudinal research.
Hat Tip and Thanks
My thinking on this topic has been greatly aided by a conversation in LinkedIn, you can see the LinkedIn conversation with 20 or more comments by clicking here.