Cloud Native Days Austria 2026: Stop Building AI Models. Start Building AI Products.
On September 30, I spoke at Cloud Native Days Austria 2026 in Vienna. It was my second time at this event, after KCD Austria 2024. A great event, a good size and a friendly crowd: I met a lot of people and had many interesting conversations.

Photo: Gisela Taschner and Carl Hohenbalken
The Talk in Short
Most AI initiatives do not fail because the model does not work. They fail because nobody defined the product: no clear goal, no measurable value, and an expense that never reaches production or brings value. The talk is about building products that happen to use AI, not AI that hopes to become a product.
Key Takeaways

Start with the goal, not the model. Without a goal there is nothing to optimize, and the project fails from a business point of view, no matter how good the demo is.
A rising metric is not proof of value. When a KPI becomes the target, it stops measuring what you care about (Goodhart’s law).
From the outside, AI changes nothing. The customer sees a request go in and a result come out. “AI inside” is marketing, not product. There are exceptions of course (e.g., a brand new AI pair programming agent, like Claude Code), but in most projects it holds.
Go from value to build in three layers:
- Product (why): business value and goal, with tools like the business model canvas, Working Backwards, the Product Box, Wardley Maps and a North Star.
- Domain (what): strategic design with Domain-Driven Design, using Domain Storytelling, EventStorming, a context map and the Bounded Context Canvas.
- Solution (how): tactical design, with the API Product Canvas1, the Architecture Communication Canvas and API specifications.
Know which of the five phases you are in, and what each one adds:
- Mock: align the idea. Just a sketch, often a clickable mock and 30 minutes with the customer instead of an overloaded PoC.2
- Proof of Concept (PoC): prove the unknown. You may need none, or several, depending on the project. A PoC should solve one risk, isolated. If nobody sees a technical or data risk, skip it.
- Minimum Viable Product (MVP): cross the gap. Now we bring value and go live, with data quality, basic compliance, minimal SLAs and monitoring.
- Product Strategy: portfolio, not project. The solution reaches product maturity and serves many uses, with full SLAs and A/B testing. Not to be confused with the product layer above: this phase is about running the solution as a product, not about defining it.
- Scaled: systemic and transformational. The operating model changes, with governance, MLOps, cost optimization and observability.3
Not every product needs every phase, and the features of each phase depend on the use case.

Links and Resources
- Slides (PDF)
- Cloud Native Days Austria session page
- Book: Crafting Great APIs with Domain-Driven Design
Related Talks:
- AI Summit Europe Riga 2026: the 45 minute version of this talk
- DevOps for AI: More than Just Models, Success through Collaboration and Automation
- Spring I/O 2026: Crafting Great APIs with Domain-Driven Design
- Podcast: Loosely Coupled: Domain Storytelling
More on the API Product Canvas in my talk How to Design AsyncAPIs in Workshops: The API Product Canvas. ↩︎
Domain Storytelling is one way to align the idea with the business before anything is built. More in the podcast Domain Storytelling on Loosely Coupled. ↩︎
How to run and scale AI in production with MLOps is the topic of my talk From Problem to Production: DevOps for AI with Kubeflow, also given as DevOps for AI at IT-Tage 2025. ↩︎
