Correctly applied, agile research is a crucial tool in the corporate researcher’s toolkit. But what makes agile research, well, agile? When is agile research appropriate and when should it not be used in lieu of other research approaches? In this article we’ll answer these and other key questions to help you understand how you can apply agile research to drive faster, smarter innovation.
To understand how critical change through time is to the value of agile research, try the following thought experiment.
Imagine that you are driving somewhere you’ve never been before. Your phone is dead, but a friend in another car knows the way and can lead you. Would you prefer to pore over a detailed map, write down the exact timing of every turn, and then paint your windshield black? Or would you be better off starting with a general route and then adjusting to keep your friend’s car in sight?
Agile research is, unsurprisingly, an approach to research that draws inspiration from agile software development. Agile research eliminates dependencies and friction that can slow down traditional research studies, trading off precision for directionally useful feedback that enables rapid learning and iterative improvement. At its core, agile research provides directional guidance early and often to guide decisions that might otherwise be driven by opinion rather than data.
This quick and iterative approach to conducting research is naturally better suited to supporting some types of decisions than others. Agile research works well in situations that have one or both of the following traits:
For example, suppose that rigorous market research has determined that an opportunity exists to solve an emergent customer problem. With that opportunity defined, the downstream research that supports feature development meets both of the criteria for an agile research approach. Product teams want to know if a proposed feature affects consumers’ likelihood to buy. In such cases, missing out an opportunity due to a false negative is financially worse than erroneously detecting an effect that is actually due to chance and building a superfluous feature.
In addition, the team developing the product is likely to iteratively make changes based on continuous consumer feedback. The next round of feedback needs to measure response to these changes. This means that data needs to be gathered not just quickly but repeatedly.
It’s less important that each data point be perfect than that data points come in frequently enough to allow you to learn and adjust. One perfect swipe of the wipers every five minutes would be a recipe for a car crash, while even the smeariest swipe every few seconds helps ensure safety.