Describe the problem together
Bring the people who use a process into the conversation. Ask them to show a real example, explain workarounds, and describe what a better outcome would look like. Those details often matter more than a long feature list.
Map constraints early
An existing database, a third-party integration, or a required approval process can shape the entire product. Identify these constraints before settling on a technical approach. Record assumptions so they can be checked rather than quietly becoming requirements.
Make priorities explicit
Separate the essential end-to-end journey from improvements that can follow. A smaller complete workflow is easier to test and learn from than a broad collection of unfinished features.
Leave with decisions
Discovery should produce a useful brief: the problem, intended users, initial scope, open questions, and a plan for validating the approach. It is the foundation for design and estimation, not just a meeting before development.