Moving beyond “Let’s just talk to people”?—?A Guide to Level Up Your Product Research

Every product team has questions: What do users need most? What obstacles are they facing? How can we improve their experience? Research provides the answers.

While “let’s just talk to people” is a good start, far too many teams stop there. If that sounds like your team, this article will help you refine your research strategy with a simple process:

1. Define Research Questions
2. Match Questions to Methods
3. Develop Guide(s)
4. Conduct Research
5. Analyze Results
6. Share Insights
7. Iterate!

As you gain experience, continue to iterate and adapt this process to meet your organization’s needs.

1. Define Research Questions

Every step of your research process should come back to the questions you are trying to answer. Simply put, research questions are what your team wants to know. These questions are not the same as interview questions. Here are examples:

• Who are our users? What motivates them?
• How do our users feel about [specific feature]?
• Could we improve our onboarding process? How?

Make a list of your questions. Encourage everyone on your team to contribute. This not only ensures a breadth of ideas, but it’s an easy way to encourage team-wide investment in the results you gather later.

If the “research question” label is stifling, simply ask your team what they are curious about. Look for statements like the following:

• “I wonder if….”
• “Do you think…”
• “What if we…”

You can also discover research questions by examining the assumptions behind statements, such as:

• “It would be better if…”
• “We should try…”
• “[This idea] would improve results…”

Reword these statements as questions and add them to your list.?

Categorize and Prioritize

Group together any questions with a similar theme or category, then prioritize the list by placing the most important research questions/categories at the top. Number the list.?

How you prioritize depends entirely on your product’s context. Here are some of the factors you might consider:

• Company vision
• Market potential
• Existing product strategy
• Target outcomes
• Analytics
• Customer feedback
• Etc.

2. Match Questions to?Methods

With research questions ready, the next step is mapping each question to the best method(s) to answer them. While interviews are often the default, they’re just one tool among many. As your skills grow, aim to diversify the methods in your toolkit. Here are some I'll be writing follow-up articles on:

• Interview?—?One-on-one conversations to gather insights into users’ needs, motivations, and behaviors.
• Analytics—?Tracking and analyzing user data (e.g., page views, click-through rates, session durations) to identify patterns, trends, and areas for improvement in product usage.
• Concept Testing?—?Presenting new ideas or concepts to users to gauge their reactions and validate the potential of specific features.
• Card Sorting?—?A method to understand users’ mental models by asking them to organize information into categories.
• Focus Group?—?Group discussions with multiple participants to explore attitudes, ideas, and preferences collaboratively.
• Contextual Inquiry?—?Direct observation and interviews within the user’s environment to understand workflows and challenges.
• A/B Testing?—?Running experiments with two or more variations to determine which performs better based on user interactions.
• Diary Studies?—?Participants log relevant activities and reflections over time, providing insights into long-term habits and experiences.
• Usability Testing?—?Users complete specific tasks to identify pain points and areas for improvement in product design and functionality.
• Task Analysis?—?Analyzing the steps users take to complete a task to identify efficiency and usability improvements.

Make a list of potential methods next to your research questions. Only include methods that are feasible considering time, budget, expertise, and other constraints.

Draw lines or otherwise connect each research question to the appropriate method(s) for answering that particular question. An important part of learning new methods is learning the kinds of research questions they are best suited to answer.

3. Develop?Guide(s)

Whenever a person is involved in the collection or interpretation of data, expect bias. Following a guide or standards for each method you use helps reduce that bias. As interviews are often what product teams default to, we’ll explore them here.

Consider interview structure. A fully structured interview follows the guide verbatim. This is ideal for narrow research questions or when it’s crucial to minimize interviewer bias.?My research questions have never been quite that narrow, but taking a more structured approach has helped me provide less experienced interviewers a clear framework to follow.

On the other end of the spectrum is unstructured interviews (i.e. “winging it”). As a rule, I never plan for a user interview to be completely unstructured. That said, if an unexpected opportunity pops up at a conference, on my commute, or some other setting, I am always eager to learn.?

Semi-structured Interview Guide

My initiatives generally land in the middle?—?a semi-structured interview.?

Semi-structured interviews enable the best of both worlds. There is a guide for interviewers to follow, but they are given the freedom to ask their own follow-up questions and explore new directions the participant introduces.

Here is how I structure these guides:

• Best Practices?—?A quick reminder at the top of the guide summarizing key interviewing best practices.
• Introduction?—?Start by thanking the participant, introduce yourself and your role, outline the interview’s goals, obtain consent, and start recording.
• Topic 1 Questions?—?A set of questions focused on exploring the first topic.
• Topic 2 Questions?—?A list of potential questions aimed at delving into the second topic.
• Topic 3 Questions?—?A series of questions designed to explore the third topic in depth.
• Closing?—?Conclude by thanking the participant, inviting additional questions or thoughts, and explaining the reimbursement process if applicable.

When organizing the interview questions, I try to maintain the priority order of our research questions, but I'll mix up that order if it feels like it would provide a more natural flow of conversation. Also, always remember you can skip to the next subject rather than asking every question in a particular category.

In a future post, I’ll cover best practices for avoiding bias in your interview questions. For now, I’ll simply refer you to Erika Hall 's content and specifically her excellent article addressing the common pitfall of mistaking research questions for interview questions.

4. Conduct Research

It’s go time! At least, its go time if you were simultaneously scheduling interviews with your users while preparing your guide. Odds are if you do not already know how this process works at your organization it will be up to you to create it.

Here are some tips for those getting started:

• Create templates for outreach, reminder, and thank-you messages.
• Select a scheduling solution (Calendly, etc.)
• Push for a recruitment incentive budget. Can range from $20-$150 gift cards depending on the user group and length of interview.
• Assign a lead interviewer and notetaker for every interview.
• Create a repository for shared notes.
• Consider which users are not volunteering to participate.
• Schedule a recurring time to meet with those involved in the research process to iterate on your outreach process, research goals, recent insights, and interview guides.

5. Analyze Results

Most product professionals could immediately improve the effectiveness of their research by learning basic qualitative coding practices. There is a lot of depth to qualitative coding practices, but it is basically reviewing and tagging meaningful portions of an interview transcript.

See screenshots from Dovetail’s version of this feature below.

For product research, I typically start with Open Coding?—?reviewing a transcript and creating new tags along the way. At least for the first few interviews.

To the extent possible, keep these codes focused on current research questions.?I tend to break this rule when access to users is especially limited, but very quickly my team’s codebook (list of tags) becomes difficult for anyone other than myself to meaningfully navigate.

6. Share Insights

Data that is relevant to a team’s immediate goals is far more likely to get their engagement. If team members, like engineers, know your findings will impact something they’re actively building or will soon be working on, they will be more invested in the results. Conversely, if the audience you’re sharing results with is too broad, interest will quickly fade. That will be the most important factor determining interest in your research results.

In lieu of adjusting team structure, here are some strategies worth trying:

• Dedicated Slack channel
• Weekly research highlights (E.g. Feedback Friday)
• Topic-specific highlight reel.
• Sharing research updates immediately following standup
• Immediate post-interview summary/hype?

7. Iterate!

This process is always evolving. It changes with every team, product, and research question I work on. Never consider your process “perfect”, but it doesn’t take much to be just enough.

Interested in learning more? Comment below or follow to continue the discussion. More articles on product research are coming soon. Thanks! ??