A lesson from Yale's Introduction to Medical Software course focuses on how engineers should gather requirements from clinical users rather than assume they already know the problem. The instructor draws a line between the engineer's framing of a task and the customer's actual voice, then walks through how to run a first meeting with a user: asking about their background, their stake in the project, and open-ended questions that surface needs the user has not articulated. The lecture covers restating problems back to users to test understanding, and pushes past surface complaints to diagnose underlying issues involving cost, quality, and the user's own skill level. It closes by widening the definition of user to include every stakeholder touched by the software, from clinicians to administrators, each with distinct requirements the design has to satisfy. Twelve minutes, aimed at engineering students building tools for clinical settings.