Bring a representative task to the first conversation
You do not need a specification to discuss development. You do need an example that another person can follow. A vague complaint such as “the portal is unreliable” leaves too many possible problems open; a short account of one failed renewal gives the conversation a starting point.
The example should be representative, not simply the most memorable incident. If a failure happens once a year under unusual conditions, say so. If staff reconstruct the same information every morning, show that ordinary work. The frequency and consequence help determine which question deserves attention first.
Write down four things before explaining the cause
Record the initial situation, the action, the observed result and the expected result. For a fictional association, the initial situation might be an active member changing employer. The action is submitting the new organisation. The observation is that the old employer remains on an invoice. The expected result still needs clarification: should historical invoices change, or only future correspondence?
That final question is valuable. It shows that the project may contain an unresolved rule rather than a straightforward software defect. A good initial conversation discovers such distinctions before somebody prices the wrong change.
Keep a suspected cause in a separate sentence. “This began after the hosting move” is useful evidence about timing. It is not proof that the host caused the failure. A developer should be able to investigate without first having to agree with an unsupported diagnosis.
Include the people outside the screen
Explain who handles the result after the user finishes. A booking request might reach a coordinator, a tutor and finance. One of them may keep a separate list because the official system does not show a useful status. That list is evidence about the work, even if the long-term intention is to remove it.
Name the person who can say what the correct result means. A project sponsor can approve spending without being the authority on membership eligibility or document review. The first discussion becomes more productive when those responsibilities are understood.
Use safe examples
A fictional record often demonstrates the relationship without exposing private information. Keep the structure that matters: one attendee, one paying employer, an organisation change and a dated invoice. Replace names, account identifiers and sensitive details. Do not send credentials or a full member export to prove that the issue exists.
If a later investigation needs protected information, discuss the necessary access and purpose separately. The initial enquiry should help decide whether an assessment is appropriate, not become an uncontrolled transfer of production data.
Leave with a next decision
The result of the conversation might be a bounded investigation, a content review or a proposal for a defined feature. Record what was understood, which questions remain and who will supply the next piece of information. Avoid treating a list of possibilities as an agreed implementation scope.
An honest unknown is more useful than a confident guess. If nobody knows which system owns a field, write that down. It may be the most important finding of the meeting.
Use the brief builder for prompts, read planning responsibilities, or send a short example when you are ready to begin.