Identifying your research problem before you actually do the research

Things that shouldn't have to be said, that we increasingly find ourselves talking about

Card-sorts, digital ethnography, shop-alongs, metaverse immersives, live experiments, A/B tests… the list of research methods and platforms available to us today are endless. This comes with the natural peril of choice overload leading to us making choices without a logical criteria behind them.

I often find myself in conversations where we jump into approach-and-methodology-building, sometimes solutioning too, without putting the necessary time and effort into problem identification, discovery and framing.

(It should be) needless to say, the approach, methodology and eventually the solution should be problem-driven, not the other way around. Caveat: The client/project sponsor’s appetite for exploration vs definition as well the business context are key considerations and hence a necessary voice in this conversation.

Here’s a simple matrix to provide you with a start point when you are developing proposal, kicking off a project or even starting a new phase of one. Mapping your problem statement onto this framework and aligning that understanding within the team + with the client/sponsor will help proactively address a lot of pain along the process that emerges when expectation setting isn’t done upfront.

Unstructured Problem, Undefined Outcome = Open Exploration: This is an opportunity for open exploration, the chances of this being a layered problem with multiple stakeholders, interactions, context factors and touchpoint is high. The goal of research would primarily be to identify the problem 1) worth solving 2) realistically solvable within the constraints of your project. Developing a problem inventory and identifying the level you want to solve at is key here, to avoid solutions that are too intangible or unfeasible. Ex. You are tasked with understanding emerging needs and potential interventions for a disease growing in incidence, in populations that may have existing infrastructural challenges (think: covid management strategy in non urban areas, globally.)

Semi-Structued Problem, Semi-Defined Outcome = Opportunity for Testing: A strategy is defined but the actual interventions are not. Your research approach here would strongly leverage past work done and bring granularity, clarity and definition to the outcome defined thus far. Ex. A product/solution is being developed and you need to conceptualize and/or test what features/positioning/communication/interventions might work for different audiences.

Structured Problem, Defined Outcome = Roadmap: In this case, while the final solution set may not be known, the desired outcome is clear. You know what your outputs are going to be, and your research approach is about identifying the steps to get there. Ex. You are working with a functional team/product team in an organization to define their 5 year roadmap.

Semi-Structured Problems, Undefined Outcome = Opportunity for Innovation: In this case, there may have a broad area of interest identified upfront but with immersion and discovery, you will frame the problem, and further identify and prioritize opportunity areas. Ex. You have been asked to study what might be opportunity areas for an emerging user or product segment (think: within snacking as an area, you explore plant-based snacking, snacking moments in the new WFH/hybrid workday, where people look for snacks, what they study on labels, segments of snackers, etc).

Structured Problems, Undefined Outcome = Opportunity for Contained Exploration: A fun oxymoron, but also a reality in several projects you may undertake wherein you are provided an opportunity area upfront, and you need to identify how to make it work - what channels, what moments, which segments, which levers. Ex. You have been asked to study how a product might scale to a new geography/user segment.

Highly Defined Outcome, Unknown Problem = !Caution, this is a Pitfall! = If the solution or outcome is pre-determined and highly defined without a problem frame, chances are the research here will be superficial, confirmatory and likely to being done to tick a box (so don’t do it).

Note: This framework is not meant to be a hard-and-fast rule based categorization, but simply a heuristic to help you kick start projects with a shared understanding and an anchor to go back to.

In conclusion, 1 hour spent discussing this together could save countless resources on potentially irrelevant research, stakeholder tension and unusable outputs.