Writing an AI brief engineering can actually build from
You sit between a business that wants outcomes and engineers who need decisions. With AI in the middle, both sides get vaguer at once. This session gives you the artefacts that make the handover hold: a named user, a journey, a constraint list, and a measure of success that was agreed before anyone built anything.
- €2,000 per workshop
- One day
- Up to 12 people
- English or German
The brief that survives contact with engineering
The complaint from engineering is never "this is too detailed". It is "this does not tell me what to decide". An AI brief that says the assistant should be helpful and accurate contains no decisions at all, so every one of them gets made by whoever writes the code, invisibly.
What makes a brief buildable is small and specific: who the user is, what the journey looks like when it works, which step AI is allowed to change, what it must never do, and what counts as good enough. Five things. None of them technical.
The second half of your job is the part most product training ignores: getting the business perspective attached before the brief moves. A brief with no value case does not get prioritised, and a brief with no constraint list gets built twice.
The column you own, and who has to receive it
The model is the same in every track. What changes is which column you own and what you are expected to hand over.
The user
“Who is this for, and what does their day look like afterwards?”
- A named user at a named moment
- The journey as it should be, end to end
- The step AI may change, and the line it may not cross
- What good enough looks like, as a number
In the room: You, designers, service and support
The business
“What is it worth, what is in the way, and who signs?”
- The value case attached to your brief
- Constraints written as facts, not wishes
- The measure someone will sign
- Priority against everything else
In the room: Finance, sponsor, legal
The technology
“Can it be built, run and defended?”
- Architecture and data access
- Feasibility tested on your samples
- Cost at your volume
- Security and evidence
In the room: Engineering, platform, data, security
What you take back to the backlog
Everyone leaves with both documents, filled in for a real use case from your own organisation.
The use-case briefIncluded
One page per use case: named user, journey, the step AI changes, hard limits, measure of success, and what is explicitly out of scope.
Journey and persona setIncluded
The journey as it should be, with the personas that matter, in a form engineering can read and a form leadership will look at.
Data reality checkOptional
Which data the journey needs, who owns it, what is missing, and what a realistic sample looks like.
Acceptance definitionOptional
What business acceptance means for an AI feature, and how to accept on a branch preview rather than a screenshot.
What belongs in the brief, and what quietly does not
The left column is what makes a brief buildable. The right column is what makes it look thorough while removing no decisions at all.
| Write this | Because | Not this |
|---|---|---|
| "A claims handler with 40 cases open, on the second screen of the intake flow." | Names a person and a moment. Everything else follows from it. | "Improve efficiency for the claims department." |
| "It may suggest a category. It may never close a case." | Draws the line AI is allowed to act inside. This is the single most useful sentence in most briefs. | "AI-powered automation of the claims process." |
| "Good enough is: the suggestion is accepted unchanged 7 times in 10." | A number agreed before the build, so success is not defined by whoever demos it. | "High accuracy and user satisfaction." |
| "Contract data may not leave the EU. This is not negotiable." | A constraint that eliminates whole architectures, early and cheaply. | "Must be secure and compliant." |
| "Here are 40 real, anonymised cases, including 6 awkward ones." | Turns feasibility from an opinion into a test[12]. | "Sample data can be provided if needed." |
One day, spent on your own use case
You bring an idea that is currently stuck. You leave with it unstuck or correctly abandoned.
The user
Personas and the journey, done properly and quickly. The step where AI is allowed to act, and the line it may not cross.
The business
The value case and the constraints, in the form the next perspective needs to receive it. This is gate one and gate two.
The handover
Sitting with the technical questions your brief now has to answer, and finding the ones it does not yet.
One workshop, the results you choose
Same model as every other workshop: €2,000 for the session, €1,000 per written result. Net, plus VAT.
AI for product owners workshop
Pre-session intake, the live workshop with up to 12 people, written results within 5 business days.
€2,000 each, 3 to 4 hours, remote or on-site
Delivered within 5 business days after the last session.
AI for product owners
What people ask before booking.
Do I need to know how AI works?
Enough to know what it can and cannot be relied on for. That is part of the morning, and it is less than people expect.
I am a business analyst, not a product owner. Does that matter?
No. The artefacts are the same. BAs often produce the better constraint lists.
Can I bring an engineer?
Yes, and for the afternoon it helps a great deal. Mixed groups are the format I recommend.
What if my use case turns out to be a bad one?
Then you have saved a quarter. That happens in roughly one session in four and it is a good outcome, not a failed workshop.
Is there homework?
A short intake form before the session, so the day starts on your real case rather than on a made-up one.
Linda Mohamed
I design and build AI and cloud systems on AWS and hybrid platforms, and I teach how they work. I have organised the AWS User Group Vienna for more than seven years, co-organise AWS Community Day DACH, teach AI architectures at Hochschule Burgenland, speak at conferences in Europe and the US, and maintain ai-solutions.wiki. Based in Vienna. Remote or on-site, in English or German.
Where the facts come from.
Prices, service names and limits change. The linked official pages are the reference; figures on this page were checked in September 2026.
- ISO/IEC 42001:2023, AI management systems
- ISO/IEC 27001, information security management
- ISO 9001, quality management
- Regulation (EU) 2024/1689, the EU AI Act
- NIST AI Risk Management Framework
- CNCF TAG App Delivery: Platforms White Paper
- CNCF TAG App Delivery: Platform Engineering Maturity Model
- DORA: DevOps Research and Assessment
- AWS Well-Architected Framework
- Amazon Bedrock AgentCore: observability
- AWS: AI services overview
- ai-solutions.wiki: from AI proof of concept to production
- ai-solutions.wiki: build vs buy for AI
- ai-solutions.wiki: total cost of ownership for AI
- Training Magazine: 2025 Training Industry Report
Start with one conversation.
30 minutes to look at your idea, your data and the right starting point. Or book 15 minutes if you only have a question.
- Which of your use cases is ready for a brief
- What is missing from the one you have
- Whether to run it with engineering in the room
- What the intake would ask for
Vienna, Austria · remote across Europe · [email protected]
