How can engineers get involved in product work when they usually receive a roadmap, finished designs, and a ticket to implement? Teresa Torres, product discovery coach and author of Continuous Discovery Habits, explains how engineers can participate while the team is still learning about customer problems and deciding what to build.

We talk about building relationships with your product manager and designer, asking for the context behind a decision, and learning from people who experience the problem your product solves. Teresa shows how to collect specific customer stories and bring what you learn back to the team. We also explore why AI tools still need shared expertise, and how changing your own habits can make you a more useful contributor to product conversations.

Listen on YouTube, Spotify or Apple Podcasts

In our conversation, we discuss:

  1. Why getting involved before sprint planning gives engineers more room to contribute
  2. How to build relationships and ask for customer and business context
  3. How to find people with the problem your product solves and collect specific stories
  4. Why AI coding agents still need product, design, and engineering expertise
  5. How to bring what you learn to the team and influence change through your own habits

Where to find Teresa Torres:

  • Product Talk: producttalk.org
  • LinkedIn: https://www.linkedin.com/in/teresatorres/
  • X: https://x.com/ttorres

Lessons Learned

  • Get involved while the solution is still open. Teresa argues that engineers should participate when the team is learning about customer problems and exploring possible solutions. By sprint planning, requirements and designs already represent a lot of work. Bringing technical expertise in earlier gives the team a chance to discover an approach it would otherwise have missed.
  • Connect technical suggestions to the customer outcome. If you see a simpler way to achieve the same outcome, there is still room to raise it during sprint planning. Explain what the alternative makes possible and how it serves the customer. Discussing it with your product manager or designer one to one can help when a meeting would make the suggestion feel confrontational.
  • Build a relationship before you need to challenge a decision. Get to know your product manager and designer as people, including what they care about and what they are learning. Teresa suggests a regular cadence of informal conversations for remote teams. Coffee or a shared lunch can create space that a task-focused meeting rarely provides.
  • Ask for context before proposing a solution. Start by asking which customer problem the team is addressing, what it has learned, and what goals the product manager needs to deliver. A different solution may sound reasonable to you while missing context your colleagues already have. Let their answers shape the point of view you bring to the discussion.
  • Use your expertise without assuming customers share your preferences. Engineers see possibilities in technology that other people may miss. That knowledge is useful in product work, but it can also make an engineer’s preferences unlike those of the target customer. Explain what is technically possible and connect it to what you have learned about the people you are building for.
  • Find people who experience the target problem. Existing customers are one source of learning. If access is difficult, use your network or relevant communities to find someone who experiences the problem your product is designed to solve. Start with their experience and ask who else you should speak to. Work with your product manager and designer as you build that understanding.
  • Ask for one specific story. Teresa teaches story-based interviewing: collect a particular past experience from beginning to end. Ask what happened first, who was involved, and what happened next. When the person generalises or skips a step, return to that moment and ask for detail. Practising with friends helps you become more comfortable with this kind of listening.
  • Look for places your product would fall short. Stories reveal the handoffs, workarounds, and exceptions that broad questions can miss. After an interview, ask how your product would fit into what the person actually did. The gaps offer a starting point for discussing unmet needs, pain points, and desires with your team.
  • Bring learning back as a contribution to the conversation. Ask why the team chose its current approach before deciding that one customer story proves it wrong. Your product manager may know about other customers or constraints. Share what you heard and ask how it compares with the team’s existing learning. This gives everyone a fuller picture to work from.
  • Make it easier for colleagues to work across roles. Engineers can help product managers use coding agents by documenting patterns, shared packages, testing expectations, and the architecture. Product managers can help engineers by making customer and business context available. Teresa sees this mutual support as a way to improve collaboration as more people do parts of each other’s work.
  • Keep expert colleagues involved when using AI. An agent can help you learn about another discipline, but it does not remove your blind spots. Teresa contrasts code that misses engineering requirements with a technically polished product that has no clear customer. Product managers, designers, and engineers still bring different expertise to deciding what to build and how to build it.
  • Start with habits you can change yourself. You may not be able to overhaul the way your organisation works. You can start learning from people, add useful context to decisions, and repeat. Teresa describes influence spreading when colleagues notice the value and ask how you are doing it. Stay curious about what others know, especially when an AI tool makes unfamiliar work seem easy.