What is a research framework and why do we need one?
Every quarter, here at Redgate, we present a summarised readout of our user research and associated insights to the wider company. This has become a regular forum for sharing what we are learning about our customers, their challenges, goals and needs across both teams and divisions.
As we continue to scale our research efforts and with that the appetite for great research, we’ve needed to provide some structure and governance around our research activities; to help with guiding conversations around how research happens and what approaches and methods to use when. To support this, during our last readout, we introduced the concept of a research framework.
What is a research framework?
A research framework provides an underlying structure or model to support our collective research efforts. Up until now, we’ve referenced, referred to and occasionally approached research as more of an amalgamated set of activities. But as we know, research comes in many different shapes and sizes, is variable in scope, and can be used to answer all manner of questions across all aspects of business, product and delivery.
From the broad fundamentals that have the potential to inform company strategy and shape portfolio decisions, through to the specific and narrow that guide our day-to-day development efforts. There is a flavour of research for every situation and a framework helps us recognise these different scenarios and tailor our approach and methods accordingly.
Why do organisations need one?
As above, a framework helps us to determine, based on what we’re trying to learn, the right approach and methods to apply in a given situation. It also helps to structure and plan our research activities, according to the breadth and scope of what we’re trying to learn. For example, we might reasonably anticipate more foundational (exploratory) learning playing out over a longer period; operating outside of the scope and internal boundaries of any one product team.
Having a framework also allows us to better prioritise our teams’ research efforts. Just like any other design and engineering activities research time comes at a cost, and although research is fundamental to helping us make evidence-based product decisions, we still have to prioritise how and where we spend that time. Do we need to allocate more effort now in identifying new opportunities or validating and testing ideas already in the pipeline?
The key here, and where the framework helps, is by allowing us to be more intentional about the different types of research we’re conducting and when. It provides a shared taxonomy, that describes the various modes/types of research, their purpose and when we should deploy these — based on a combination of where the product is in its life lifecycle, various strategic initiatives and delivery scenarios.
The Research Funnel
The framework we’ve adopted for this particular job is the Research Funnel, as credited to consultant and research leader Emma Boulton. We were lucky enough to work with Emma back in July, where she consulted with us to evaluate our then research maturity and help us think about (and take steps towards) introducing a practice around research operations.
One of Emma’s key recommendations was to adopt a framework to help govern, coordinate and communicate our research efforts. The Research Funnel nicely illustrates the idea of funnelling down from the very broad, more foundational aspects of Exploratory Research to the specific, narrow and optimisation-focused function of Operational Research.
Similar to my recent article on the Double Diamond as a framework, we’ve tried to incorporate and adapt (as necessary) Emma’s model to align with our own business, org structure and industry context. To briefly summarise, here’s a short description of each modes/types of research, their scope and intended purpose:
Exploratory Research
Organisations are likely to conduct Exploratory Research when exploring new markets and potential problem spaces that may yield significant longer-term revenues streams. This type of research is likely to happen less frequently, is broad in scope and completely product-agnostic.
Strategic Research
Teams are likely to conduct Strategic Research when seeking to discover new opportunities (new problems or unmet needs) to inform and influence future design and engineering effort. This type of research is likely to happen alongside teams’ current development efforts, within the context of an existing problem space.
Tactical Research
A team is likely to conduct Tactical Research when looking to explore and validate potential solutions to known, target problem. This type of research happens frequently, as part of teams’ current development efforts and within the context of the current opportunity.
Operational Research
A team is likely to conduct Operational Research when seeking to measure, iterate and optimise an existing, deployed solution/aspect of a solution. This type of research happens more frequently to monitor and improve upon recent development efforts, within the context of the current opportunity.
Applying the Funnel
With this framework in mind, we can start to see how different research activities taking place across the organisation might services various aspects of strategy and decision-making; from the broad and foundational to the narrow and specific.
Shaping strategies and portfolios
Research in this space is likely to help inform the bigger picture and direction of travel for the company as a whole; influencing associated marketing and sales strategies and shaping a portfolio of products and services.
Shaping product vision and roadmaps
Research in this space is likely to contribute to a vision and roadmap for a given product/group of products; focusing on surfacing new opportunities (new problems or unmet needs) and finding the intersect between these and desired business outcomes.
Shaping backlogs and backlog items
Research in this space is likely to determine and help prioritise a backlog of design and engineering effort required to ship experiments, evaluate impact (outcomes) and iterate towards an appropriate solution.
Traversing the Funnel
What I’ve illustrated so far provides a great through-line for agile organisations with a portfolio of products and services, where each team is focused either on a single product or aspect of a wider offering. Teams’ research efforts can cascade more linearly through the funnel; using research to address ambiguity, narrow the scope of decisions and help them determine what to explore and deliver next.
Yet a purely linear approach can perpetuate silos and risks organisations overlooking wider opportunities for insight and innovation.
The reality is that every product or service in the market operates within a wider context and as part of a broader experience. If you’re familiar with Jobs-to-be-Done (JTBD), you’ll be aware that the products and services we create often are a means to an end; ‘hired’ in moments of struggle to help individuals make progress with their goals. With a better understanding of customers and their jobs, we can start to redefine an offering, what functionality is in and out of scope and how they packaged and positioned.
As such, it’s important to understand this wider context, requiring our research efforts to operate across different customer segments and adjacent or related problem spaces. This sees exploratory efforts operating horizontally; looking at the bigger picture and abstracting away from individual products and services to understanding how individuals and professionals go about their lives, the challenges they face and the people and systems they interact along the way.
Similarly, if we think about how customers acquire, engage with and consume these products and services (having defined their shape and value) we see can see these as a series of touchpoints and interactions with your organisation, where the product or service itself is one piece of and even bigger puzzle. Research across the end-to-end (from enquiry and awareness to renewal and referral) helps organisations to understand, measure and innovate around the Customer Experience (CX).
Mapping the Funnel
Finally, to look at the funnel in the context of what for some companies might be a more complex and diverse mix of product and services, it’s useful to consider this model alongside the concept of managing and mapping the innovation portfolio (explore, exploit, sustain, retire), as introduced in the Lean Enterprise.
In Lean Enterprise, authors Jezz Humble, Joanne Molesky and Barry O'Reilly introduced us to the idea of mapping a portfolio of products against a maturity lifecycle. Early stage or greenfield projects sit over in the Explore phase, likely requiring a different set of skills and approaches to help establish early signals of product/market fit. Products in the Retire phase are generally considered end of life and will start to cost the business more to support and maintain than the revenue they generate.
So why is this relevant to research and how does this map to the funnels? At its simplest, different lifecycle stages will inevitably have different needs of research. Folks responsible for conducting or supporting the research needs of a portfolio company will likely find themselves vary the amount of time and effort they spend operating in or across what is likely to be multiple funnels; often running in parallel.
Those responsible for new product development are very likely to spend proportionally more of their time and effort conducting exploratory and strategic activities as they seek to identify a market, target customer and problem space worth pursuing. Is there an opportunity/problem valuable enough, that would resonate with a population of people and is within the scope of the company to tackle?
By contrast, those working on mature, established products are likely to spend proportionally more effort servicing more Tactical and Operational activities, as they seek to improve and optimise existing capabilities; increasing the number of people using and able to get value from that solution, whilst finding new ways to reduce operating costs (support and maintenance).
But of course, this mapping is also non-linear. Something in the sustain phase might be a candidate for innovation. Maybe we reimage that product in a way that is more fitting of new demand or maybe changes in technology allow us to reinvent a radically better solution to the same underlying problem. In such scenarios it might be plausible to revisit some of the fundamentals and explore new angles; shifting from a focus on Operational to Exploratory and Strategic.
This currently accounts for our attempt to map a research framework to the profile of our organisation. Organisations working with alternative setups in other industries will likely interpret and adapt this to fit their own circumstances. But, as a framework, it’s already providing us with a great foundation upon which to have healthier and more productive conservations about our collective research efforts.
