In-Product User Interviews: When They Fit
An in-product interview is useful when you can already reach a user and the question depends on a real workflow. UserTold lets the participant complete that workflow first, then asks about the concrete moment while it is still fresh. It does not recruit participants, guarantee responses, or replace scheduled research for every question.
Use an in-product interview when
- you need to understand why onboarding or activation stopped
- the user must navigate setup, pricing, checkout, or an integration to expose the problem
- behavior and explanation need to stay connected
- one focused question is more useful than a broad feedback request
- the resulting evidence needs to remain inspectable before an agent creates work
The method lowers the distance between action and explanation. It does not manufacture user motivation: the team still needs an appropriate, consenting participant and a reason for that person to engage.
Choose another method when
- you need participant recruitment or a representative market estimate
- the question is primarily about brand perception or a long-term customer relationship
- the important churn signal happened outside the product
- you need a broad discovery conversation without a product task
- the user should not encounter research inside the workflow
A scheduled interview can be the better choice for broad context. Analytics and replay can be the better choice when you first need to locate a pattern at scale. UserTold is for the narrower question: what happened in this workflow, and what did the user expect at that moment?
Choose the method by the question
| Method | Best question |
|---|---|
| Product analytics | Where do users stop or behave differently? |
| Session replay | What happened on screen during this visit? |
| Feedback widget | What did a motivated user decide to report? |
| Scheduled interview | What broader context, decision, or relationship matters? |
| Focused UserTold study | What happened in this task, and what did the user expect? |
These methods can be used together. A funnel may locate an onboarding drop-off, replay may reveal repeated navigation, and a focused interview may explain the expectation behind it.
What the participant experiences
- The product presents a clear invitation and recording disclosure.
- The participant receives one neutral task.
- UserTold stays quiet while the participant works.
- The interviewer asks about the observed moment after the task.
- The participant closes the study and returns to the product.
Observation comes before explanation so the interviewer does not rescue the user or change the behavior the team needs to understand.
What the team receives
When consent, permissions, and available capture allow, the recording, transcript, navigation, interaction timeline, and derived Evidence keep the observed moment reviewable. Evidence may connect what the participant did with what they later explained, but interpretation remains separate from the source record.
A human or project-aware agent reviews the source, grouping, uncertainty, and current product context before draft Work becomes ready. Core Concepts defines the source record and Evidence model.
The study shape
UserTold studies use three segment modes:
| Mode | What happens | Best use |
|---|---|---|
speak | Read a scripted instruction or transition | Welcome, consent, task setup, closing |
observe | Record while the participant uses the product | Onboarding, checkout, setup, usability tasks |
talk | Conduct a focused voice interview | Debrief, discovery, follow-up questions |
A common sequence is speak -> observe -> talk -> speak: set the task, preserve natural behavior, ask about what just happened, and close. Keep the instruction neutral and tell the debrief which study goal it should investigate rather than scripting a desired conclusion.
For a pricing-comprehension study, for example:
- Ask the participant to choose a plan for a specific situation.
- Observe comparison loops, missing information, or unexpected backtracking.
- Ask what information they expected at the point of hesitation.
- Review the resulting source moments before creating Work.
Continue from evidence to a decision
Use Find Why Users Get Stuck when the immediate problem is unexplained abandonment. When the study returns Evidence, continue to Prioritize Fixes With Evidence before anything enters Linear or GitHub.