Arun Godwin Patel · 7 min read
a founder sent me a brief that said "we want AI."
i sent back eight questions. they answered three of them.
we spent the next two weeks in a loop — me asking what the AI needed to know, them describing what they wanted it to feel like. it wasn't a bad conversation. it just was the scoping conversation that should have happened before they sent the brief.
briefing an AI studio is different from briefing a design studio or a development agency. the technology is less constrained — AI can be applied to almost any problem in almost any way — which means the scoping decisions are more consequential, not less. a vague brief for a design agency produces a product that looks wrong. a vague brief for an AI studio produces a product that behaves unpredictably.
why "we want AI" is not a brief
AI is not a feature. it's a category of capability that can be applied to a specific job in a specific context. "we want AI" is closer to "we want software" than it is to a brief a studio can act on.
what makes an AI feature work — or not — is precision about the job it's doing. an AI that summarises documents does a different job from an AI that extracts structured data from documents, which does a different job from an AI that answers questions about documents. each of those requires different architecture, different evaluation criteria, and different decisions about what the AI is allowed to do when it isn't confident.
the job description is the brief. everything else follows from it.
four questions your AI brief needs to answer
what is the user doing manually right now that this AI will do instead? specific and concrete. not "analysing data" — "spending 40 minutes after each customer call writing up notes and tagging them by theme before adding them to the CRM." that level of specificity is what makes an AI feature buildable. it tells the studio what input the AI receives, what output it produces, and what good looks like.
what data does the AI have access to? AI features work from data. the quality of an AI feature is limited by the quality and quantity of the data it can access. a chatbot that can only reference a small FAQ is different from a chatbot that can reference your entire product documentation and user history. before briefing, know: what does the AI need to know to do the job? where does that information live today? who controls access to it?
what should the AI do when it isn't confident? the most important product decision in any AI feature. a confident wrong answer is often worse than an honest "i'm not sure." for customer-facing AI, the failure mode matters as much as the success case. should the AI decline to answer and escalate to a human? say it isn't sure and offer alternatives? attempt an answer with a confidence signal? this decision shapes the entire user experience around the feature.
how will you know if it's working? a measurable success condition. "users find it helpful" is not measurable. "handles 60% of support tickets without escalation" is. "reduces time spent on report generation from 40 minutes to under 5 minutes" is. the success condition tells the studio what to optimise for and gives you a way to evaluate whether the feature is delivering value before you declare it done.
what makes an AI brief different from a regular brief
two things. first, the failure modes are different. software either works or it doesn't, and "doesn't work" is usually obvious. AI features exist on a spectrum — they can be right most of the time, wrong in ways users don't notice, or confidently wrong in ways that damage trust. the brief needs to address what the acceptable failure rate is and what failure looks like.
second, the evaluation criteria need to be defined before the build, not after. it's very easy to build an AI feature that feels impressive in a demo and is marginally useful in production. the brief should specify how the feature will be evaluated in real conditions — what data you'll look at, what user behaviour you'll measure, what threshold constitutes success.
what to include (and not include) in the brief you send
your brief should include four things: the manual workflow the AI replaces, the data the AI has access to, the failure handling decision, and the success metric.
what not to include yet:
- Architecture decisions (e.g., "use GPT-4"). A good agency will determine the right tools for the job you define.
- A full feature list for the whole product. Scope this brief to the specific AI feature or workflow.
- Ready-to-build code. Focus on the problem context and job-to-be-done, not the technical implementation.
examples are the single highest-leverage thing you can include in an AI brief. they communicate intent in a way that written descriptions rarely fully capture. if you have them: include examples of the input (a sample document, a sample customer message, a sample data export) and examples of the ideal output. a studio that sees three examples of good AI output will build something closer to what you're imagining than a studio that reads three paragraphs describing it.
The AI Feature Brief Template
Copy the block below, fill in the blanks, and send it.
Project Goal & Manual Workflow:
Currently, our [user type] spends [time/effort] manually [describe the manual process]. We want an AI to handle this instead.
Data Access & Inputs:
To do this, the AI will need access to [describe data sources, format, location]. Examples of a typical input: [attach/link to examples].
Success Metric:
We’ll consider this successful when [specific, measurable outcome], measured by [data point or user behaviour].
Failure Handling:
When the AI is not confident, it should [e.g., decline and flag for human review / provide a confidence score / offer a fallback option].
Examples of Ideal Output (if available):
[attach/link to 2-3 examples showing what a perfect AI output looks like].
Out of Scope (for now):
[list any related features or adjacent problems that are explicitly NOT part of this initial brief].
FAQ
How long should an AI feature brief be?
Concise. One page is ideal. Use the template above and bullet points. The goal is to provide enough specific context to start a productive scoping conversation, not to write a technical specification.
What if I don't know exactly what data I have?
That's common. Describe the problem and the type of data you believe exists (e.g., "customer support ticket history in Zendesk"). A good agency will help you audit and structure it. The brief is the starting point, not the final map.
Should I include mockups or wireframes?
Only if they directly illustrate the AI's input or output. A mockup of a button that says "Ask AI" isn't helpful. A mockup showing how a summarised report should be formatted is highly valuable.
How many agencies should I send this to?
Start with 2-3. Their responses—especially the questions they ask back—will tell you who understands the nuance of building for outcomes, not just outputs.
at DreamLaunch, AI integrations are a regular part of our work — chatbots, document processing, workflow automation, custom model integrations. the scoping conversation for AI features is the most important part of the engagement. bring us the manual workflow you're trying to replace and we'll work through the brief together.
what's the thing your users are doing manually today that should have an AI doing it instead?
