A useful brief gives an engineer enough context to ask better questions. You do not need to choose every framework or describe every screen. Start with the person using the product, the problem they face and the change you want to make possible.
Describe one complete user journey
Instead of “we need an AI dashboard,” describe a specific task: a support lead uploads approved documents, asks a question, checks the supporting sources and exports a draft response for review. This makes the inputs, outputs and responsibility boundaries visible.
Then identify where this journey starts and ends. Does uploading include document cleanup? Does exporting mean downloading a file or writing into another system? These small distinctions can change the work considerably.
Separate the first release from later possibilities
| Include now | Discuss later | Explicitly outside scope |
|---|---|---|
| One workflow for a defined user group | Additional roles and integrations | Work another team already owns |
| Basic review and recovery paths | Advanced workflow automation | Unsupported platforms |
| A measurable acceptance check | Broader reporting | Unverified performance promises |
The entries above are prompts, not a standard package. Replace them with the boundaries of your project. A smaller release is useful when it answers a real question and can be operated by the people receiving it.
Make assumptions visible
List the systems already in place, available design assets, access requirements, data sources and any fixed date. If an integration has not been investigated, record it as an open question. An estimate should distinguish known work from work that depends on discovery.
Ask for a short explanation of what would change the estimate. Examples include undocumented APIs, inaccessible source code or a requirement to migrate historical data. Agreement on these triggers is more useful than presenting a precise number without context.
Agree on responsibilities and review points
Identify who can approve scope, who answers product questions and who accepts a release. For a Fone-led engagement, the scope should also say which work I handle directly and where collaborators are involved. Team access and responsibilities should be agreed before work begins.
Choose review points tied to visible outcomes: a working journey, an integration operating in a test environment, or a release candidate with an agreed checklist. Each review should lead to a decision, not just another status meeting.
Start with the free brief
A short Markdown template you can edit with your own team. No account required.
When you are ready, share the problem and your current setup. Unanswered questions are welcome.
