This is the third (and final) part of my MRMW EU 2019 summary series. You can read my Day 1 summary here, and my overview of the second day here.
In a 20 minute, interactive session on the second day of MRMW EU 2019, FlexMR CEO Paul Hudson took the stage to challenge the audience with a series of tough – but often overlooked – questions about who really shapes modern research experiences. The presentation was split into two halves.
In the first, he explored the role of software developers in the research industry, and evaluated whether it is fair to say there is a dependence on the group. And in the second, the audience worked together in order to start a conversation around how both researchers and software developers can better collaborate and build better research experiences.
Influence and Reach
The ideal starting point for this presentation was a deep dive into data from the Q3/Q4 2018 GRIT report. This showed, clearly, that out of the top 12 emerging research methods – only two do not require input from software development to implement. Similarly, the same report highlights that researchers are 2.3x more likely to use online surveys than offline alternatives and while in-person focus groups remain the most popular qualitative method, online communities are quickly gathering steam; in use by 25% of all respondents.
One particularly interesting graph showed that while there is already a reliance on the hard skills of developers, this is only set to increase further as big data, visualisation, AI and automation technologies are taken more seriously by the insight community.
In fact, when broken down, Paul showed that development teams have input into the categories of software used by researchers, individual elements of such software (UI, features, architecture etc.) and the channels they are delivered over (such as online interfaces, voice skills and mobile devices).
A View from the Other Side
After establishing the scope of software developer input into modern research experiences, Paul introduced quotes from members of our team that provide a fascinating look at how the ‘other side’ view their role.
Dave Russell, a senior developer in the research industry, said; “Software development in market research is ultimately about providing people with a voice. We harness technology to create engaging digital spaces that empowers researchers and encourages people to share their thoughts.”
Meanwhile, Alex Leaver explained; “It shouldn't surprise anyone that the software development landscape evolves at a rapid pace. From the cloud to big data to machine learning; as a developer, it is my job to understand these technologies and identify how they can complement new and existing market research tools.”
From these statements, two themes emerged. First, developers view their role within the research industry as one which builds the foundations for researchers and participants to build on. And secondly, a developer looks to new technologies and innovations to understand how it can fit into and improve existing processes. This begs the question; is the insights industry really as in control of its own future as we like to believe?
Well, sort of. What this results in is a cyclical process. Research methodologies, projects and reports are designed by researchers – who are restricted by the technology and software we use. Developers build the tools and software we use but are restricted by our expectations, needs and previous ways of working. And, ultimately, these two groups and the restrictions they place on each other can, without intervention, lead to stagnation (or, the wrong innovations).
The Skills Pyramid vs the Skills Continuum
What Paul did next was to stack all the skills required to build research technologies, make efficient use of them and drive informed decisions. What became quickly clear is that these skills sit in a pyramid structure – built on foundations of specialist, niche and backend programmers, slowly moving towards C-Suite executives and key decision makers who share no overlap in skillset with those at the base of the structure.
Another way to visualise this pyramid is on a continuum that plots skills between hardware/ software development at one end, and insight generation or activation at the other. A current view of the industry would suggest there is little overlap in the centre. Programming, QA, UI & UX design of research systems are viewed as the responsibility of development departments. Meanwhile, everything from data collection to research management and decision making is the role of the researcher.
Paul made the case that to drive real, useful and practical innovation – we need to start eroding that hard border and stretch both the input of researchers into development responsibilities and vice versa. However, that is much easier said than done.
Challenging Researchers and Developers Alike
Using the research continuum as a starting point, the second half of the presentation asked attendees to work together in tables to answer the following questions:
- What makes a good experience for participants and project for stakeholders?
- What should we be teaching developers working in the research industry?
- How can we improve communication between researchers and developers?
- How can developers & researchers work together to find the best outcomes?
The resulting debate was lively, stimulating and started the room thinking about what both we should be doing to engage more with the development community, who should lead and how best to collaborate with others. After 10 minutes of discussion, Paul brought the room back together to talk through some of the thoughts that the groups wished to share.
While I don’t want to share exactly what was discussed (though feel free to get in touch with myself or Paul for more info) some common themes that emerged were: education is better than leadership, engagement and working towards a shared vision are vital, and innovation cannot just come from one side alone.
I think the audience discussion is best summed up in the words of FlexMR CTO Neil Bartley: “As developers working in the research space, we have the same vision and responsibilities as insights professionals, we just use a different set of skills to achieve that goal.”
