Bring the problem as it happens today
A first conversation is most useful when you can describe a recent, ordinary example of the work. Explain who starts it, which tools it passes through, where someone waits and what a successful result looks like. You do not need a finished specification. Bring the business decision you hope the conversation will help you make: whether to build, what to investigate or how to rescue an existing product.
Create a safe example before the meeting
For a fictional customer-service workflow, replace names, email addresses and order references with invented values. Preserve the structure that explains the problem, including error states and manual steps. Check screenshots for browser tabs, notifications and account details. A redacted spreadsheet can still contain hidden sheets or comments; a small purpose-built example is often easier to review safely.
Share constraints, not credentials
Useful context includes user groups, approximate transaction volumes, important integrations, deadlines and who can approve scope. Mark estimates as estimates. Do not send passwords, API keys, payment-card details, full production databases or confidential customer documents through the enquiry form. If a later technical assessment needs access, establish an authorized, limited and revocable access process separately.
Separate observed facts from assumptions in a short brief
A useful preparation note can fit on one page: the decision you need, the people involved, the current sequence of work and the consequence of leaving it unchanged. Add one ordinary example and one exception. A clear description of a delayed approval is more useful than a long feature list when nobody yet knows why approval is delayed.
Suppose a fictional sales team sends quotations from a spreadsheet, while managers approve discounts by email. The ordinary example follows one quotation to approval. The exception shows a revised price sent before the manager sees the latest version. Identify which version was approved, where the salesperson looked and what the customer received. Do not assume the answer is a new CRM; the problem may concern a missing revision rule or unclear responsibility.
Label each statement as observed, estimated or still to be checked. If someone says revisions happen frequently, record who reported that and what sample could clarify it; do not turn it into an invented monthly count. Describe required record relationships and communication channels using fictional identifiers. You can explain that two versions belong to one quotation without sharing the real customer’s identity or commercial terms.
Ask for a next step that resolves a specific uncertainty
Compare the smallest useful options during the conversation. Configuring the existing tool may be enough if it can preserve approved versions. A prototype may clarify how managers review changes. A technical check may be needed to establish whether the current system exposes the required records. A full build becomes a more credible option after those uncertainties are understood. Record why an option was preferred and what evidence would change that choice.
Assign an owner to each unanswered question. The sales lead can define which price changes require fresh approval; an authorized system administrator can check available exports or integration access. Give each investigation a deliverable, a boundary and an agreed review point. A bounded discovery task should leave something the business can use even if development does not follow, such as an agreed workflow, a tested constraint or compared scope options.
Send or agree a written recap covering the desired outcome, options considered, open questions and next decision. Record any proposed cost or timing as a scoped proposal, with its assumptions; it is not a confirmed estimate for an unseen integration. Correct misunderstood terminology before planning depends on it. A transcript alone is a poor substitute for an agreed decision record: the useful result is knowing who will establish the next fact and how it will influence the project.
Leave with a specific next decision
Use the project form to tell Orvun Labs about the outcome and the main obstacle. The conversation should produce a shared problem statement and the next evidence needed, not pressure to authorize an undefined build.
- Which ordinary example best shows the problem?
- What must improve, and what can remain as it is?
- Who will answer workflow questions and make decisions?
- Have the shared files been checked for secrets and personal data?
