Most AI ideas are under-specified when they first meet potential collaborators. The founder can see the possibility, but engineers, designers, operators, mentors, and backers need a clearer object. A collaborator-ready project brief turns the idea into something others can evaluate and join.
Start with the user. Do not describe the project as "AI for healthcare" or "AI for sales." Name the specific user and situation: a clinic administrator preparing patient follow-ups, a founder qualifying investor leads, a compliance analyst reviewing vendor evidence, or a support manager triaging urgent tickets.
Then describe the workflow. What happens before the product exists? What is slow, expensive, inconsistent, risky, or emotionally draining? AI is most useful when it changes a repeated workflow, not when it floats above a broad category.
Next, define the first output. The output might be a ranked list, a draft, an alert, a summary, a data extraction, a recommendation, or a completed action waiting for approval. Make the output concrete enough that a collaborator can imagine building it.
Add the evidence you already have. This might include user interviews, manual tests, example inputs, competitive products, waitlist demand, domain expertise, or a painful process from your own work. Evidence does not need to be huge. It needs to be honest.
Name the risks. NIST's AI Risk Management Framework is useful because it reminds builders to map and manage AI risk early. A project brief should mention data sensitivity, accuracy requirements, user trust, workflow consequences, and where human review is required.
Define the first prototype. Keep it narrow: one user, one input type, one workflow, one success measure. A prototype that proves a small real behavior is better than a large vague platform.
Finally, make the ask. Do you need a technical cofounder, a domain expert, a design partner, a data source, a backer, a customer interview, or a weekend build partner? Collaborators respond faster when the next step is specific.
A good project brief does not eliminate uncertainty. It organizes uncertainty so the right people can help. For Startable builders, that is the point: move from isolated idea to shared project, from excitement to evidence, and from "someone should build this" to "here is the first version we can test."
