Take a look at the diagram below. It walks through the two primary sources of question creation: from your stakeholders and out of your research activities. If you're in a centralized model, then column A is where you'd optimize your efforts, while in an embedded model, you can use both columns A and B (read more about embedded and centralized research organizations in Collection 1, Handbook 1, Topic 4).

Let's break down each part of the diagram so you can feel more confident when finding fruitful questions to study.

‍

Senior Leadership Needs Help

The first group of people to understand are your senior leaders. These folks might be the ones paying for the research, but they're certainly the ones who set the long-term strategies and vision for the product or your immediate stakeholders.

More often than not, if a senior leader asks you for help, you should jumpstart research right away. You still shouldn't be studying fruitless questions, so make sure you take the time to educate and refine any fruitless questions they have. Use these moments to build your relationship, making it easier to run fruitful research in the future.

‍

Stakeholders ask Questions

Next, understand and talk with your core or immediate stakeholders. You don't have a regular or consistent set of stakeholders if you work in a centralized research model. But in an embedded or product model, your core stakeholders could include a product owner, UX designer, engineering manager, or any other non-researcher that's invested in building a better experience.

When working with your stakeholders, you want first to make sure you're noticing their problems and predictions They're all trying to make sense of the current product and the person or segment who's using it. Note down their assumptions, questions, and more.

You're also looking to understand their domains. Each of your core stakeholders has unique skills, perspectives, and goals. Sadly, the goals of each stakeholder might overlap and contradict each other. The design stakeholder wants to build a great experience. However, their focus on improving the system's design might contradict or slow how engineering stakeholders develop and maintain that system.

Everyone cares about the user, just from a different perspective. As a researcher, you can bring clarity by learning from your core stakeholders and seeing where their goals and issues overlap. That overlap can be one great source for finding fruitful research questions.

There's a guide that'll help you make the most of these interactions, alongside some general and specific questions you can ask individual stakeholders (namely product owners, UX designers, and software engineers).

Guide 04: Conducting Stakeholder Interviews

One final note on stakeholders: it's not their job to develop fruitful research questions. They have other priorities, so it's up to you to regularly interact with your stakeholders and understand their needs.

‍

People-facing Departments

The last set of people to understand are colleagues or peers that directly interact with users. Functions like customer service, sales, and IT support have regular interactions that expose them to real issues and needs in the current experience.

Maybe a salesperson keeps hearing customers wanting X feature or that customer service reps spend a lot of time helping new customers set up their accounts. Build relationships with these departments so you can identify questions to study.

‍

Conducting Desk Research (Product Analytics, Releases, & Reports)

Column B of the diagram (above) represents research activities. A research activity are the things that you do to help build better products. One beneficial activity is conducting desk research. It can take a lot of resources to run an entire study. However, sitting at your desk and reviewing log data or product analytics and reports can be less resource-intensive and still help you find fruitful questions to study.

Log data represents the regular measurements or metrics that are recorded when people interact with the company or the product. Based on your industry or domain, you might see metrics recorded things like browsing behavior, sales per year, the changing number of active subscribers in a segment, and more.

Some of the things you could look for are listed below but make sure to ask your stakeholders about additional or important materials to digest regularly. And if you're interested in better understanding product analytics and metrics, check out this resource for more help.

Guide 05: Conducting Desk Research

Things to Look for When Conducting Desk Research

• Formal and informal language (such as acronyms, terms, definitions, or how stakeholders or users speak about a product)
• Ideas or concepts relevant to your industry
• Approaches or past study designs you can emulate or copy
• Results, findings, insights, and recommendations
• Discrepancies, gaps, or contradictions across sources or reports
• Colleagues, teams, departments, or researchers you can get advice or help from

‍

Reviewing the Roadmap & Backlog

Other helpful sources of fruitful questions are the roadmap and backlog. Roadmaps can come in many forms (e.g., feature, release, content, marketing, or product roadmaps). Your focus will likely be on the product roadmap, an evolving, collaborative document that outlines the direction, requirements, and goals for a particular product or set of products. The work that isn't urgent or high-priority gets dumped on the product backlog.

When you're talking with your stakeholders, make sure to ask about their product roadmaps. Most product roadmaps have set goals and specifications for what a product or service needs to do or achieve. Commonly, they are known as product requirements.

Product requirements are the essential functionalities a product must have to fulfill a need for any given people segment. A smart speaker needs a way to give feedback when any vocal command is received because it doesn’t have a screen.

These requirements can be functional or nonfunctional. Functional requirements are related directly to what people want or expect when using something (such as with the smart speaker example). Nonfunctional requirements are related to how the product fulfills those needs.

For example, there have to be strong security requirements for a service that stores your passwords in the cloud. People might never interact or even see these requirements, but they’re essential to a positive user experience.

Other non-functional requirements include things like ensuring product reliability, developing documentation or help guides, or meeting any relevant legal constraints. All product requirements — functional or not — need to be identified and planned. Typically, requirements get placed on a product roadmap.

If you’re able to find and review a product roadmap, one helpful activity is to categorize the requirements. First, group them into functional and non-functional requirements. Then, group them further using the common buckets below.

Categorizing Requirements on A Product Roadmap

• Regular maintenance (work that keeps the technical side of the product working smoothly)
• Fixing issues and feedback (dealing with reviews, bug fixes, and other unexpected issues)
• Iterations and feature releases (making improvements to the current experience)
• Product strategy and planning (ideation, discovery, and collaboration to plan the future)

You should be able to see where limited resources and energy is being spent and on what pieces of work. If you see a lot of future-facing requirements, it’s a good signal to conduct strategic research now. If you don’t see any requirements to improve the product, engage in conversation about how a few usability tests can lead to immediate and meaningful changes.

But remember earlier when you read any prediction can be wrong? A roadmap is essentially a lot of people making predictions and putting them into a document. Every roadmap will be wrong, either in a little or a big way. You shouldn’t view any roadmap as "truth,” but use it to understand how work is progressing and where you can add value with your research.

Beyond just inaccurate predictions, many other things can stop how effectively stakeholders or the business completes items on their roadmap. Some all-too-common examples are listed below:

How Product Roadmaps Can Be Inaccurate

• Updates/changes on one roadmap/backlog might affect another team, but that team might not be notified until too late
• Pieces of backlog work are more complex than originally thought or can’t be built at all
• Stakeholder or business priorities shift as time, resources, and energy gets depleted
• Different teams might use different language/terms/mental models for the same thing, leading to communication barriers & assumptions
• Timelines are typically too short, and stakeholders overestimate how productive they can be within those timelines
• Feedback, usage data, and comments from the target user challenge the plan forward

The last way is the most counterintuitive: people dislike the work the business has released, shipped, or implemented. In these scenarios, instead of moving onto the next project, your team has to scramble to make changes, solve bugs, train support teams, or consider rolling back what was released. Timelines get pushed back, fingers get pointed, and tensions rise.

If your research challenges a defined product roadmap, get ready for stakeholder frustration.

The solution? Research early enough so that the product roadmap is easier to stay on track. However, the sad reality is that UX practitioners rarely get invited to plan roadmaps or prioritize backlogs. Some businesses dislike research because it can identify alarming issues that entirely derail the "perfect" roadmap. Others don't know that researchers (and their design counterparts) are valuable people to have in the room when making roadmap changes.

Over time, as you conduct fruitful research, you increase the probability of attending road mapping sessions and influencing the product before anyone creates a single design or button.

‍

Attending Meetings

Your regular meetings with your core stakeholders are possibly the most consistent place to find fruitful questions to study. Your stakeholders are making assumptions and predictions about what people want or need. Mark all of these down in one centralized note taking document.

Adopt two behaviors right away: first, take bulleted notes during all of your important meetings, and second, review your notes weekly (such as setting a weekly, recurring, Friday afternoon event on your calendar to check the past week's notes quickly). The behaviors increase the chance you recognize fruitful questions. If you recognize the chance to do some impactful research, you can propose questions to study to your stakeholders.

‍

Conducting Primary Research

The last place you can look for fruitful questions is during other studies you've started. Known as primary research, you're going out to collect new knowledge. Desk research, mentioned earlier, is secondary research as its data that's been collected for another study or purpose.

However, because questions lead other questions, you'll most likely notice other important things to study. You can propose them back to your team in your reporting deliverable as recommendations (see this topic for more).

It can be overwhelming knowing what to study. Similar to categorizing requirements in a product roadmap, you - and should - categorize the possible or requested research questions, hypotheses, and topics to be studied. From there, you can more readily separate fruitless questions from the fruitful ones.