I spent the last two years as a Technical Product Owner at ZEISS Vision, transforming legacy systems into modern, enterprise-driven architectures. Before that, I worked as an Application Analyst, enabling change management across regions including APAC, EMEA, and LATAM. I'm now dedicated full-time to AI/ML engineering — building products for both B2B and B2C users that solve real enterprise bottlenecks across the entire builder's arc:
As a former Technical Product Owner at ZEISS Vision, my job was translating ambiguous AI capability into scoped, shippable roadmaps — deciding what an event-driven architecture should actually do, which API contract earns partner trust, and where a model needs a human in the loop before it touches production. That's the same muscle an AI PM needs, pointed one level up the stack: instead of specifying a feature for engineers to build, I want to be defining what an AI product should do, how we'll know it's working, and when it's ready to ship.
Since leaving ZEISS, I've been deliberately building toward that next role rather than looking for a lateral move. My project portfolio is the evidence: alongside applied builds — RAG platforms, a multimodal diagnostics assistant, workflow automation — I've added the parts of AI product work that rarely make it into a portfolio: running models under real hardware constraints, instrumenting a system for cost and quality in production, fine-tuning for a narrow task instead of chasing a bigger model, and budgeting latency in a real-time pipeline. Each one is framed the way I'd frame it for a stakeholder — problem, trade-off, evidence — because that's the habit I'm bringing into an AI PM seat, not just a list of tools.
Each project is framed as a stakeholder would need it: the problem, the product bet, and where it stands — including the unglamorous 70% of AI product work that usually gets left out of a portfolio.
Agentic RAG that turns dense documents into trustworthy answers
Enterprises sit on mountains of PDFs and internal documents that people can't search meaningfully, so employees either waste hours hunting for answers or make decisions without the information they already own. Consumer products need grounded, cited answers rather than generic chatbot guesses that erode trust.
Two production-grade RAG systems built on one shared thesis: retrieval quality and answer traceability matter more than raw model cleverness. An agentic architecture orchestrated with LangGraph decides when to retrieve, re-query, or escalate, with Groq for fast inference and Jina AI embeddings stored in PostgreSQL + pgvector — a deliberate choice of a familiar relational store over a specialized vector database to keep operations simple and auditable.
In active development — the target is document queries answered with verifiable source citations in seconds, replacing manual document trawling with a dependable self-serve capability.
AI assistant supporting clinical evaluation across text and medical imagery
Clinicians face mounting diagnostic workloads where symptoms, patient history, and imaging evidence live in disconnected places, forcing slow, error-prone manual synthesis. General-purpose AI tools aren't trusted here because they lack domain grounding.
Scoped as a domain-specific assistant that ingests both clinical text and medical imagery, so one workflow surfaces candidate diagnoses alongside the evidence behind them. Narrow clinical scope over a broad chatbot is a deliberate trade-off: it allows tighter validation and a clearer path to clinician trust.
In active development — the goal is to cut the time clinicians spend reconciling fragmented inputs into a single assisted diagnostic workflow.
Benchmarking small language models entirely offline
Not every AI product decision should default to the biggest hosted model. Privacy-sensitive workflows, on-device use cases, and cost-constrained deployments need a real answer to "how much capability can we get without leaving the device or the budget" — and most teams choose a model on reputation rather than evidence.
Three small language models are run entirely offline through Ollama on identical hardware, with a fixed task set used to benchmark inference latency, throughput, and output quality side by side. The product question being answered isn't "which model is smartest" but "which model is smart enough, fast enough, and cheap enough for this specific job" — the trade-off every AI PM has to defend to engineering and finance in the same conversation.
In active development — the deliverable is a documented quality-vs-speed comparison across the three models, framed as a decision brief: which model to pick under privacy, latency, and cost constraints, and why.
Instrumenting a live RAG system with the metrics that actually run production
Most AI portfolios stop at a working demo. In production, a RAG system that answers correctly once means nothing if nobody can see when it gets slower, more expensive, or less accurate a week later — and regressions ship silently without gating in place.
Tracing, latency tracking (p50/p95), cost-per-request, and answer-quality metrics are being added directly onto the existing RAG platform, then wired into CI as a regression gate — a build fails the same way a broken test fails if quality or latency drifts past a threshold. The product bet: treat evaluation as a release gate, not a dashboard nobody checks, because this is the unglamorous 70% of production AI work that most portfolios leave out entirely.
In active development — the target is a CI pipeline that blocks a deploy the moment a change degrades answer quality or blows the latency budget, turning "it works on my machine" into a measurable release standard.
Task-specific fine-tuning for structured JSON extraction and tool-calling
Prompting a general-purpose model to reliably emit structured JSON or make correct tool calls has a ceiling — it's inconsistent enough that teams either over-engineer prompt scaffolding or pay for a bigger model than the task needs.
A base model is fine-tuned on a narrow task — JSON extraction and tool-calling — using LoRA/QLoRA for parameter-efficient training on limited hardware, with a second pass of DPO preference tuning to sharpen output reliability beyond what supervised fine-tuning alone achieves. The product framing: this is what "ship a smaller, cheaper, more reliable model for one job" actually looks like, not a slide about it.
In active development — the deliverable is a before-and-after comparison with measured accuracy, format-validity, and latency numbers against the un-tuned base model.
A voice assistant built around an explicit latency budget
Real-time AI products live or die on perceived responsiveness, not raw model quality — a voice assistant that's accurate but sluggish fails the same way a fast one that's wrong does. Most builds treat latency as something to fix after the fact rather than a constraint designed for up front.
A streaming voice assistant pipeline is being built with end-to-end latency decomposed into an explicit budget across speech-to-text, model inference, and text-to-speech, so each stage has an owned time allowance rather than an unmanaged total. Graceful degradation and timeout handling are treated as first-class product requirements — the assistant needs a defined fallback the moment any stage misses its budget, instead of failing silently.
In active development — the goal is a documented latency budget with measured stage-by-stage timings and a defined degradation path, the kind of spec a real-time product needs before it ever reaches users.
I'm actively looking for my next role as an AI/ML Product Manager. If you're hiring for someone who pairs enterprise product discipline with hands-on AI/ML fluency — or just want to talk shop — reach out directly or use the form.