Start with a job to be done
Before choosing a title, describe the work in plain language. “Help our support team find the right answer in approved documentation” is more useful than “build an AI agent.” Identify who uses the result, what they do today and what should improve.
Separate the unknowns
List what you know about the workflow, data, existing product and expected outcome. Then list the questions you still need to answer. If the problem itself is unclear, discovery may come before a specialist hire. If the problem is clear but the data is fragmented, data engineering may be the immediate need.
Choose the smallest useful scope
Define one workflow, one user group and one first milestone. Specify what is out of scope as carefully as what is in scope. A limited first release makes it easier to evaluate both the solution and the collaboration.
Make the evidence visible
Write down how you will know the work is useful. This might be response quality on an agreed set of examples, less manual handling or a working integration. Include failure cases and decide who will review the result.
Turn the outcome into a role
Match the work to the expertise. Custom model development points toward AI / ML engineering. Language-based applications point toward LLM development. Connecting existing systems points toward automation. Many projects need more than one discipline, but not necessarily all at once.
Bring a clear brief to the conversation
Include the business goal, current workflow, relevant systems, data access, decision maker and desired timeline. Describe your constraints openly. A good brief gives a specialist enough context to challenge assumptions and propose a sensible first step.
Put it into practice.
Turn the useful questions into a project brief you can keep, edit and share.
Create your brief