How I lead research from a messy question to a clear direction

Frame a question the team can act on

I begin by separating the symptom from the unknown. A page with low conversion is a symptom. Whether people are confused, unconvinced, unqualified, or simply not ready is the unknown—and each answer leads to a different product decision.

Then I align the research question with both a user decision and a business decision. That makes the study easier to scope and harder to dismiss later as interesting but unactionable.

A useful research question names the uncertainty, the decision it informs, and what will change when we know the answer.

1. 01

   Name the request

   I write down what the team is asking for—such as “redesign the page” or “improve conversion”—without treating it as the research question.

2. 02

   Find the unknown underneath it

   For Medicare, the unknown was why sign-up felt hard. For Running Point, it was whether people could not use the site or simply did not find it persuasive.

3. 03

   Define the decisions the study must unlock

   I agree on what could change after the study: content, positioning, flow, product direction, or the decision not to redesign.

4. 04

   Align user and business goals

   I make the overlap explicit before recruiting. In Medicare, earlier education supported both confidence and better-qualified leads.

Choose methods that answer different parts of the question

I rarely expect one method to carry the whole answer. Behavioral data can show where a funnel breaks, but not why. Interviews can reveal language and emotion, but not the size of a pattern. Usability testing can show whether a proposed fix works, but only if the task and audience are realistic.

The goal is not methodological variety for its own sake. It is enough triangulation to know what the evidence does—and does not—support.

1. 01

   Use counts to establish the pattern

   The Medicare survey showed how widespread confusion, anxiety, and negative reactions to marketing were across 40 participants.

2. 02

   Use conversation to explain the pattern

   Moderated interviews captured the language people used, the moments they hesitated, and why “more information” could make the experience worse.

3. 03

   Use tasks to separate usability from persuasion

   For Running Point, task-based testing showed that people could navigate. Preference work showed that the missing pieces were positioning, proof, and differentiation.

4. 04

   State the limit of each method

   Short Medicare sessions surfaced perception and emotion but did not prove that a new tool would work. That required a later prototype study.

Make synthesis a team decision-making tool

I synthesize in layers: observations, clusters, insights, user needs, and opportunities. Keeping those layers visible lets a product manager or stakeholder trace a recommendation back to evidence instead of treating research as a polished conclusion they had no part in.

I also share patterns early. That gives teammates a chance to challenge an interpretation before it hardens into a recommendation—and creates ownership before the final presentation.

The deliverable is not the research deck. It is shared clarity about what the team should do next.

1. 01

   Move observations onto one surface

   I pull quotes, behaviors, survey counts, and stakeholder evidence together so contradictions remain visible.

2. 02

   Cluster before naming

   I group repeated evidence first, then name the theme. This reduces the chance that an early assumption decides where every quote belongs.

3. 03

   Translate each theme

   Every cluster becomes an insight, user need, point of view, and How Might We question.

4. 04

   Prioritize with the decision in mind

   I rank opportunities by strength of evidence, user risk, business relevance, and what the team can realistically act on.

5. 05

   Bring stakeholders into the reasoning

   I share patterns before the final presentation so the team can challenge the interpretation and understand how the direction was formed.

Close the loop honestly

Research leadership includes being precise about what happened after the study. I separate tested findings, design recommendations, shipped work, and measured outcomes. A strong insight does not become an impact metric because the concept looks convincing.

When work ships, I stay with the numbers. When it does not, I document the risk, what would need to be tested next, and what the team can still learn from the direction.

1. 01

   Recommend at the right level

   Some findings call for language changes; others change a journey or create a new product opportunity. I do not force every insight into a screen.

2. 02

   Make the direction tangible

   When a recommendation is difficult to understand in a deck, I prototype it so the team can react to a concrete experience.

3. 03

   Separate research truth from product proof

   The Medicare findings were delivered and presented. The Plan Finder remained unshipped, so I describe it as a hypothesis grounded in research—not a measured outcome.

4. 04

   Measure or define the next test

   Running Point shipped and produced business signals. For the Medicare concept, I documented the moderated comparison tasks and accessibility checks needed next.