Everyone tells engineers to talk to users. But what should you ask, and how do you turn the answers into better product decisions? Sara Iacozza is a Senior UX Researcher and Product Strategist with 7+ years of experience helping teams understand user behaviour and decide what to build.
Sara walks through a practical way to build your interviewing skills: prepare questions with a researcher, practise with colleagues and an AI coach, then get support in your first real interviews. We also explore how to get beyond polite answers, spot patterns across conversations, and bring what you learn into engineering decisions.
Listen on YouTube, Spotify or Apple Podcasts
In our conversation, we discuss:
- How understanding users helps engineers make trade-offs and find simpler solutions
- How to practise user interviews with colleagues, an AI coach, and a researcher’s feedback
- How to avoid leading questions, use plain language, and ask about real experiences
- How to turn interview notes into shared insights and check AI analysis against the evidence
- How to get closer to users by shadowing interviews, watching recordings, and talking to colleagues
Where to find Sara Iacozza:
Lessons Learned
- Start with a question you need to answer. Research has a purpose. You might need to understand whether people can navigate a screen, or whether a product solves a worthwhile problem. Be clear about what you want to learn before choosing how to investigate it.
- Use user context to challenge the proposed solution. Sara describes engineers who recognised that a branching questionnaire could meet users’ needs without a chatbot. Understanding the problem gave them a basis for proposing a simpler implementation.
- Learn interviewing through practice and feedback. In Sara’s workshop, a researcher prepared the questions and colleagues took turns interviewing each other. Treat your first attempts as practice, with someone who can help you notice where your questions or follow-ups need work.
- Rehearse with an AI interview coach. Sara used a custom GPT that could hesitate, contradict itself, and evaluate the interviewer’s approach. Practise responding to those moments, review the feedback, and try again before taking those skills into conversations with real users.
- Get support for your first real interviews. Sara joined early interviews to take notes and ask additional questions. Having an experienced researcher present gives you room to learn while helping the conversation reach useful detail.
- Listen long enough to ask a useful follow-up. A quick answer, especially one that confirms your expectations, can hide the detail you need. Ask why, request context, and invite an example instead of moving straight to the next prepared question.
- Ask about a specific past experience. Questions such as “Would you use it?” invite speculation, while “You like the feature, right?” suggests the answer. Explore when someone actually used something, what happened, and why it mattered to them.
- Use words your users recognise. Even familiar product terms can be confusing outside your team. Match your language to the person you are interviewing, and review your questions for jargon that might prevent them from explaining their experience.
- Share what you learn while it is fresh. Bring observations into regular team conversations. Comparing stories helps colleagues question assumptions, notice contradictions, and connect individual interviews to the decisions the team is making.
- Look for patterns across interviews. A shorter transcript is only a summary. Synthesis means connecting observations across conversations and examining which themes recur. Check how many people support an apparent insight before treating one person’s experience as a broader finding.
- Review AI analysis against its sources. Ask for supporting references and inspect the underlying interview evidence. Apply the same care you would bring to reviewing generated code: a convincing answer still needs to hold up when you check it.
- Start with the access you have. Ask to observe an interview or watch a recording if you cannot run one yourself. If you build internal tools, your colleagues are users too; a short conversation about how they use your work can be a useful starting point.