Strategic research: research that shapes the roadmap
Strategic research decides which problems are worth solving; tactical research checks whether what we build works. How to balance them and feed the roadmap.
What is the difference between strategic and tactical?
The difference lies in the question. Jared Spool, as quoted in a Looppanel article, puts it this way: tactical research asks whether we are building the product right for our users; strategic research asks whether we are solving the right problems.
That changes the scope. Tactical work moves inside a product and a bounded goal: a usability test of a sign-up flow, a navigation test before a launch. Strategic work, according to Spool, is different because it is not focused on products. It moves outside the product: what someone who does not use our service today needs, what people do when they are not in our app, which problem is worth solving next year.
A simple rule to classify: if the result could change the direction of the product, it is strategic. If it only changes how something that already exists looks or works, it is tactical.
This is not the same as generative versus evaluative research. That distinction is about method and timing: discovering needs or testing a solution. Strategic versus tactical is about the scope of the decision the research informs. A usability test is evaluative and almost always tactical, but an evaluative study of a new concept can be strategic if it decides whether a product line moves forward.
Why does it matter to a designer?
Because roadmap decisions are made before design arrives. A team that does only tactical research always arrives late: it validates screens that someone has already decided to build. Strategic research is how you arrive early, while there are still options.
It also keeps design from becoming a review service. If every request is “does this button work?”, design work shrinks to polishing. Strategic research gives the team a voice in what gets built, not only in how.
A strategic finding only matters if it changes something concrete. Before you present it, write down which decision it would change and what would happen if the finding turned out to be false. If the answer is that nothing would change, the finding is interesting but not strategic. And if the decision was already made when the research arrived, the research came too late: that is a signal to review how your organization plans, not only how it investigates.
How do you balance them?
According to the same Looppanel article, Jared Spool recommends that 85% of research be strategic and 15% tactical. Treat that as a practitioner’s recommendation, not as a measured industry figure. What is useful is the principle: check how much of your research looks forward and how much looks back.
A practical method to start:
- List the decisions for the next two quarters. What will be built, and what will be left out.
- For each decision, write the research question. If you do not know what to ask, the decision is still premature.
- Classify each question as strategic or tactical.
- Assign a method to each question. Interviews, a diary study or a competitive analysis for strategic questions; a usability test for tactical ones.
- Review the result with the product team before the roadmap is locked.
How does it relate to the roadmap?
ProductPlan argues that the design role is both tactical and strategic, and that having a separate UX roadmap and product roadmap does not make much sense. It recommends showing tactical work, such as design sprints, prototyping and usability testing, on short-term roadmap views, and strategic work, such as strategic user research or design audits, on views spanning months or quarters.
A research roadmap also makes sense on its own. NN/g describes it as a living artifact that prioritizes future research efforts, from early discovery initiatives to later usability testing (video by Sarah Gibbons, 2023). If your organization has a design roadmap, research should appear there as planned work.
Example
Illustrative example: a parcel delivery company plans a redesign of package tracking for the next six months. The design team proposes two research lines. The first is strategic: interviews with people who send parcels occasionally, to understand what they expect to know while a parcel is in transit and why they abandon the app. The second is tactical: a usability test of the current tracking screen, to fix problems they already know about. The interviews change the roadmap decision: the team finds that people want proactive alerts, not a fuller screen. The roadmap is adjusted before anything is designed.
For your next planning cycle: write the three product decisions for this quarter and, for each one, the research question that would answer it. If a question sounds like “does it work?”, it is probably tactical and should not decide the direction.
Common mistakes
- Doing only tactical research and arriving late to decisions.
- Doing only strategic research without validating anything that reaches production.
- Treating the research roadmap as an appendix instead of part of the product roadmap.
- Using the 85/15 split as a fixed rule without looking at your team’s context.
- Presenting strategic findings without concrete decisions that connect them to the roadmap.
- Doing research without questions. Without a decision to inform, any study is exploration with no destination.