Product, finance and engineering working from the same brief
Most AI programmes fail in the handover, not in the model. Product writes a wish, finance writes a number, engineering writes a system, and none of the three ever sees the other two. This is the enablement that connects them: the same use case, walked through all three perspectives, with the handovers written down and the evidence collected as it goes.
- €2,000 per workshop
- €1,000 per written result
- Per role or mixed
- English or German
Where AI programmes actually lose time: the handovers
Ask a product owner why the AI project stalled and you get: engineering said it was not feasible. Ask engineering and you get: nobody told us what it was for. Ask finance and you get: nobody could tell me what it costs or what it saves. All three are right, and all three are describing the same missing artefact.
Training people role by role does not fix this, which is why so much AI training changes nothing. A product owner who has done a prompt-engineering course still cannot hand a buildable brief to an engineer. An engineer who has done an agents course still cannot tell finance what it will cost at volume.
What fixes it is running one real use case through three perspectives in a fixed order, with a gate between each, and putting every artefact in the same place. The skills arrive as a side effect of doing the work. That is the part people remember.
People first, then business, then technology
The order is not decoration. A use case nobody will use does not improve with a better model, and a use case with no business case will not survive its first budget review, however well it is built. Governance sits across all three rather than at the end[1][5].
The user
“Who is this for, and what does the day look like afterwards?”
- Users and personas, named, not assumed
- The journey as it should be, end to end
- What people do today and what breaks
- Which part of it AI is actually allowed to touch
In the room: Product owners, business analysts, designers, service and support
The business
“What is it worth, what is in the way, and who signs?”
- The value chain the use case sits in
- Constraints that are real: legal, contractual, political
- The business case, with the numbers written down
- What success is measured by, before anyone builds
In the room: Finance, business owners, legal, compliance, leadership
The technology
“Can it be built, run and defended?”
- Architecture, data access and the layer decision
- How it is built, reviewed, tested and deployed
- Security, certification evidence, audit trail
- What it costs to run and who is on call
In the room: Engineering, platform, data, security, operations
Two points where work stops until something is written down
The handover is where AI programmes lose information, so it is the thing to make explicit. Each gate has a written condition, and work does not move until it is met. This is the same idea as a definition of done, applied to the joins between departments rather than to a sprint.
One repository, including the things that are not code
The journeys, the business case, the sample data, the PDFs the system has to read, the labelled results, the infrastructure, the implementation and the audit evidence. In one place, versioned, with an owner per directory. This is the single change that saves the most time, and it is the one teams resist most[6][7].
docs/journeys/docs/decisions/business/value-case/data/samples/data/labelled/input/source-documents/infra/app/evidence/The same process, seen from the seat you actually sit in
Each track teaches the whole model, from the seat the person actually sits in. Mixed groups work best; single-role groups go deeper. Both run as one workshop or as a series.
For decision makers
What AI costs, what it is worth, and how to tell a real project from a good demo. The questions to ask before signing.
For product owners
Turning an idea into something engineering can build: personas, the journey, the constraint list, the measure of success.
For engineering
The build side: everything as code, branch previews, review that lets non-specialists contribute safely, and the evidence trail.
For designers
Prototypes as evidence: what changes in a journey when AI is in it, and how design work feeds the business case.
The same three steps you already see on the other pages
Enablement is not a separate product. It is the three-workshop series run so that the people in the room can do it again without me.
Perspective one and two
The use cases, scored. The personas and journeys written. The value case and the constraints agreed. Gate one and gate two.
Perspective three
Architecture per surviving use case, priced per service, tested against the real data. The repository gets its shape here.
All three, together
ROI, MVP scope, the funding case, and the organisational change that has to happen for any of it to survive contact with the quarter.
Letting non-specialists build without letting go of the rails
The promise of AI tooling is that more people can build. The risk is that they build things nobody can review, secure or operate. The answer is not to stop them; it is to make the safe path the easy one[6][8].
| What the non-specialist does | What the platform does for them | What that removes |
|---|---|---|
| Starts from an idea and a journey | A template repository with the directories and the decision-record format already there | The blank-page problem, and the missing context later |
| Works on a feature branch | Preview environment per branch, created and destroyed automatically | "It works on my machine" and the queue for a shared test system |
| Opens a change for review | Automated checks: tests, security scanning, cost estimate, policy rules | The review that is a taste argument instead of a factual one |
| Asks for business acceptance | The branch preview is what business accepts, not a screenshot in a slide | Sign-off on something other than the thing that ships |
| Merges | Pipeline deploys, evidence is collected, the decision record is updated | The gap between what was approved and what is running[2] |
Agent swarms turn out to be a review problem
Once several agents implement in parallel against the same brief, the constraint moves. Producing changes gets cheap; deciding which of them is correct, safe and consistent with the last twelve decisions gets expensive.
That is why the gates and the repository come first in this programme. Agents working from a repository that contains the journeys, the constraints, the labelled examples and the decision records produce work that can be reviewed against something. Agents working from a ticket produce plausible work that cannot.
The same applies to running them. An agent in production needs the step-level trace, the token cost and the error rate to be visible, or nobody can say whether it is doing its job[10]. Enablement covers that, because the team that builds it is the team that will be paged for it.
Per workshop, the same as everything else
No separate training price list. Tick the results you want.
AI enablement 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.
One role, one workshop
Three roles, three workshops
What people ask before booking.
Is this a course or a workshop?
A workshop. People bring a real use case from their own organisation and leave with it further along, not with a certificate. If you want a course on AI architecture specifically, there is one in preparation.
Can you mix roles in one room?
Yes, and it is usually better. The point of the model is the handover, and the handover is easier to teach when both sides of it are present. Single-role groups go deeper on their own perspective.
How many people?
Up to 12 for a working session. Beyond that it turns into a lecture, which I also do, but it changes less.
Do you cover the tools?
Only as far as the decision needs. Tools change faster than this material does. What stays true is the order of the questions and the shape of the evidence.
What about ISO certification?
Does this work for a department that does not build software?
Yes, and those are often the most useful sessions. The three perspectives and the gates do not require anyone to write code. The repository part changes shape, but the principle holds.
What does corporate training normally cost?
For context: the 2025 Training Industry Report puts average spend per learner at $874, with 62% of instruction outsourced rather than delivered in-house[15]. A workshop for 12 at €2,000 sits below that per head.
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 departments are losing the most time in handovers
- Whether to start with one role or mix them
- What a first session would cover
- Whether the full programme fits your quarter
Vienna, Austria · remote across Europe · [email protected]
