How to Conduct Better Interviews with HubSpot

Start with the decision the interview must support

An interview objective should be more specific than “learn more about the customer” or “collect good quotes.” Those intentions are too broad to guide question selection or determine whether the conversation was useful.

Write the objective as a decision statement. For example:

• Decide which customer problem should lead the next campaign.
• Understand why qualified prospects stop progressing in the sales process.
• Identify the language customers use when describing a service problem.
• Document how a team currently handles a process before changing its CRM workflow.

Then identify the evidence needed to support that decision. If the decision concerns a sales bottleneck, you may need the sequence of events, the people involved, the point where momentum was lost, and the consequence of delay. If the objective is a case study, you may need a clear before-and-after story, but you should not assume the outcome was positive or measurable until the interviewee explains it.

Choose the right interview structure

The interview format should match the type of information you need. A structured interview uses the same questions in the same order, which makes answers easier to compare. It is useful when several people need to comment on the same process or experience.

A semi-structured interview uses a consistent set of core questions while leaving room to investigate unexpected detail. This is usually the most practical format for customer discovery, sales research, process mapping, and content interviews. An unstructured conversation may be appropriate during early exploration, but it is harder to compare and easier to steer accidentally toward the interviewer’s assumptions.

Design questions that produce evidence

Good questions invite a person to describe what happened rather than confirm the interviewer’s preferred explanation. Begin with context and recent events before asking for opinions or general conclusions. Specific memories are usually easier to examine than broad statements such as “the process was inefficient.”

Use a practical question sequence

1. Context: What is the person responsible for, and where does the relevant process occur?
2. Trigger: What event caused them to take action or look for a change?
3. Process: What did they do next, and which tools or people were involved?
4. Friction: Where did delay, confusion, rework, or missing information appear?
5. Consequence: What happened because of the problem?
6. Evaluation: How did they judge possible solutions or decide what to do?
7. Future state: What would a better process need to make easier or more reliable?

Questions such as “Can you walk me through the last time that happened?” are usually more useful than “Would an automated workflow help?” The first explores actual behavior. The second introduces a solution before the problem is understood.

Keep language neutral

Leading questions create answers that sound supportive but may not reflect reality. Instead of asking, “How much time did our new feature save?” ask, “What changed in your process after the feature was introduced, if anything?” This gives the interviewee room to describe a positive result, a limited result, no result, or an unintended consequence.

Avoid combining multiple questions. “How did the implementation, onboarding, and reporting improve?” asks the interviewee to answer three different subjects at once. Separate them and allow the answer to determine the next question.

Build trust without losing structure

Rapport is not a substitute for preparation. It is the condition that makes honest detail more likely. At the beginning, explain why the conversation is taking place, how long it should take, how notes or recordings will be used, and whether comments will be attributed.

Ask permission before recording. If a person is uncomfortable being named, establish whether their comments can be used anonymously or only for internal analysis. These details are especially important when the interview may influence marketing content, hiring decisions, product priorities, or changes to a team’s operating process.

During the interview, listen for the interviewee’s own terms. If someone says that information is “always getting lost,” ask for the most recent example. If they describe a workflow as “manual,” ask which steps require copying, checking, re-entering, or waiting. Do not immediately translate their words into a CRM field or automation idea. First understand the underlying business state.

Use follow-up questions to move from opinion to detail

Follow-up questions are where much of the useful evidence appears. They should clarify the sequence, ownership, frequency, and consequence of what the person described.

• What happened immediately before that?
• Who noticed the issue first?
• What did you do when the information was missing?
• How often does this occur?
• What is the impact when it is not resolved?
• What would the next person in the process need to know?
• Is that the normal process or an exception?

Use paraphrasing to check meaning: “So the request is received in one system, but the approval is tracked somewhere else. Is that accurate?” This protects against building a process map from a misunderstanding.

Silence is also a useful technique. People often add important context after a short pause. Interrupting too quickly can replace a detailed answer with the first, safest answer that came to mind.

Convert interview findings into usable business information

A transcript is not a system. After the conversation, separate the material into categories that support the original decision. One practical set of categories is:

• Observed behavior: What the person actually did.
• Business state: The condition the work was in, such as awaiting approval, missing information, or ready for handoff.
• Friction: The delay, ambiguity, duplicate work, or error risk.
• Need: What the person must be able to do reliably.
• Evidence: The quote, example, document, or process detail supporting the finding.
• Action: The decision, experiment, process change, or follow-up required.

This distinction prevents a common failure mode: turning every interesting comment into a requirement. An interviewee may suggest a dashboard, an integration, or an AI assistant. That suggestion is worth recording, but it is not automatically the right solution. First define the decision, the business state, and the control needed.

Example: using interviews to improve a CRM handoff

Imagine a sales and delivery team reporting that handoffs from sales are inconsistent. A weak interview asks whether the team wants “better CRM automation.” A stronger interview asks the delivery lead to describe the last handoff, what information was available, what was missing, who had to chase it, and when the work became ready to start.

The answers may show that the real problem is not a missing notification. The opportunity may be an unclear definition of “closed won,” inconsistent required information, or no visible owner for the transition. Automation could help later, but only after the business state and handoff rule are agreed.

In HubSpot, the resulting design might involve clearer pipeline stages, required properties, task ownership, or reporting that highlights records waiting for action. The interview does not decide the configuration by itself. It provides evidence for a process decision.

For related work involving HubSpot architecture, pipeline design, automation, and reporting, see HubSpot consulting. For broader questions about CRM ownership, data structure, and handoffs, CRM consulting may be the more relevant starting point.

Review the interview process, not just the answers

After each interview, review both the findings and the method. Identify which questions produced specific examples, where the conversation became leading, and which important subjects remained unclear. Update the guide carefully. If every new interview uses a completely different script, comparison becomes difficult. If the script never changes, the process stops learning.

For a hiring example, the same principle applies. A recruitment interview should not only collect impressions about a candidate. It should test clearly defined capabilities using comparable questions and documented evidence. A tailored recruitment workflow can then make ownership and progression visible, as illustrated by this ConsultEvoInternational Talent Recruitment and ClickUp Hiring WorkflowAn example of making candidate sourcing and recruitment workflow stages more structured and visible.→

The same operating rule applies whether the interview supports marketing, sales, operations, or hiring: capture evidence in a form that makes the next decision clearer. Use automation only after the decision logic is understood, and use AI only when it has a defined job such as summarising approved transcripts, grouping themes for review, or identifying unanswered questions. Human ownership remains necessary for interpretation and action.