I build and scale digital products at the intersection of mobile, AI, customer engagement and enterprise transformation.
With 12+ years across technology, quality engineering and product management, I bring an unusual combination: I can shape the product direction, understand the platform underneath it, and stay close enough to execution to get complex products shipped.
At Deutsche Telekom Digital Labs, I work on OneApp — a consumer platform serving 10M+ monthly users across nine European markets. My work spans engagement platforms, experimentation, AI-assisted experiences, release transformation and multi-market product delivery.
My career started in quality engineering, where I learned to question assumptions, find what breaks in real-world usage and understand how product decisions translate into working software. That perspective eventually took me into product management.
Today, I work across business, engineering, design, analytics, legal, compliance and market teams to turn ambiguous problems into clear product strategies and executable roadmaps. I am comfortable moving between a leadership discussion, a customer journey, a technical architecture and a release decision.
The case studies below show how I approach four different product challenges: building an enterprise engagement framework, improving growth through experimentation, defining quality for an AI assistant, and taking a consumer product from idea to launch.
Some details have been simplified or anonymized to respect company confidentiality. The product problems, decisions, responsibilities and outcomes are presented accurately.
Creating a scalable engagement foundation for a 10M+ user, multi-market platform
The request that landed on my desk was simple: add more notification use cases. I pushed back. More campaigns was never the problem — the platform underneath them was.
Notifications had grown one team at a time, one market at a time, across nine European markets. Different triggering, different configuration, different delivery — a different stack in almost every corner. You couldn't give customers a consistent experience, you couldn't measure performance in one place, and every new use case meant more glue code. Piling more campaigns onto that would only make it worse, faster.
So I reframed the work: not "more notifications," but "one framework everything runs on" — operational and engagement messages both, with room for consent, quiet hours, priority overrides, market-specific rules, and central measurement.
I split notifications into three categories — service, system, and engagement — and gave each its own rules for consent, priority, quiet hours, expiry, fallback, and channel. Instead of every team redefining behavior per campaign, they inherit a category and its defaults.
Underneath, I separated three jobs that had been tangled together: configuration (the journeys, content, and rules), orchestration (who gets what, and when), and delivery (getting it there reliably). That separation is what made it obvious where the existing engagement platform could do more, and where we still needed specialized delivery.
Centralize everything and no market adopts it; leave it fully local and I'm just blessing the fragmentation I set out to kill. So I standardized the core capabilities and the measurement model, and let markets configure inside that.
Reach vs. trust.The goal was never "send more." More volume is the easy, lazy win — and it's the one that quietly burns the channel. I optimized for relevance, consent, and frequency control instead.
Quick wins vs. the platform.Several teams needed backend-triggered notifications yesterday. I treated every one of those requests as a way to pull them onto the shared platform, not as a reason to spin up another parallel solution. I used the urgency; I didn't fight it.
One product direction across configuration, orchestration, and delivery. One model for service, system, and engagement — with real transparency into consent, delivery status, and performance. Four fragmented systems consolidating toward one. The platform and SDK work drove:
Enterprise platform work almost always shows up as a feature request. The real opportunity sits a level below it. The job is to solve today's use case without making tomorrow's platform harder to run.
Improving reachability without compromising customer choice
Only about 39–40% of eligible users had notifications turned on. That's a lot of people we simply couldn't reach — for service messages, not just marketing. The team had plenty of ideas to lift it. Every one of them ran into the same rule: we don't buy opt-ins at the cost of informed consent.
Before running anything, I wanted to know whether the journey itself was the problem. We were asking users to clear privacy consent and a notification-education screen before they ever saw the OS permission prompt — three decisions stacked back to back. My hypothesis: the friction wasn't the ask, it was the order and the timing. If people understood the value at the right moment, with fewer competing decisions in the way, more would say yes — without hurting consent completion or satisfaction.
Most eligible users stayed on the existing flow. A smaller slice went into a clean control/treatment split so we could compare fairly. The variants were all about sequence and clarity — reorder education and consent, simplify the copy right before the system prompt, test whether education even needed its own screen, and move the ask to a more natural moment. No pre-ticked boxes, no dark patterns. That was a hard line, not a nice-to-have.
Notification permission activation rate.
Secondary.Reachable users, CTR, push-led sessions, opt-out → opt-in, downstream engagement.
Guardrails — the ones I watched hardest.Privacy-consent completion, immediate opt-outs, onboarding completion, satisfaction. If activation went up but consent completion dropped, that wasn't a win. It was a problem wearing a win's clothes.
Someone floated the obvious lever: default the toggle on. It would have moved the number. I said no — it's inconsistent with informed choice, and it trades a short-term metric for legal and trust risk you can't easily buy back. We competed on clearer value and better timing instead.
The wider reachability work — journey and SDK improvements together — moved the numbers over roughly three months, and left behind a repeatable way to run consent-sensitive experiments:
Durable growth almost never comes from pushing harder. It comes from explaining the value, asking at the right moment, and watching what happens after the first yes.
Defining what “good” looks like when the answer is generated
We were building an assistant that answers customers in natural language. The hard part wasn't shipping it — it was defining "good." The same question can produce a different answer every time. A feature can be technically working and still be wrong, irrelevant, or unsafe. Pass/fail acceptance criteria don't survive contact with that.
I came at this with both hats on — product and quality. Before anyone argued about models, I wanted the assistant's job pinned to five questions: Is the answer relevant to what the customer actually meant? Is it grounded in approved information? Does it avoid making things up? Does it respect what it's allowed to see and say? And does it know when to stop — to clarify, fall back, or hand off?
I structured quality in four layers — did we retrieve the right source, was the answer good, was it grounded and safe, and did the conversation actually get the customer somewhere. Then I built evaluation to match, because one method isn't enough:
It runs in the pipeline, not as a quarterly audit.
I'd rather the assistant say "let me check" or hand off than produce a fluent answer it can't support. Fluency is easy; being right is the product.
Automation vs. judgment.Automated eval gives you scale and regression coverage. It does not get the last word on a high-risk journey. I kept both, on purpose.
Quality vs. latency.More retrieval and more checks buy quality and cost time. I treated latency as a product metric and tuned within a quality bar, rather than pretending the trade-off wasn't there.
A definition of AI quality the team could actually measure — relevance, faithfulness, safety, and whether the customer's task got done. Reusable datasets and criteria for release regression. Quality checks that moved earlier in the lifecycle instead of living at the end. And a shared language that replaced "this feels off" with something specific — plus the monitoring to keep watching fallback, escalation, and feedback in production.
AI product work isn't bolting a chatbot onto a journey. You have to design the limits as carefully as the capabilities. A trustworthy assistant knows what to answer, what not to, and when to ask for help.
From a living-room observation to a multilingual product on two app stores
After we became parents, my friend and I kept watching the same thing at every family get-together: our kids crawled past the toys and went straight for our phones. Screens were going to be part of their lives — that fight was over. But most of what was on them was passive, repetitive, or built to hold attention rather than earn it. So instead of waiting for someone to build something better, we did.
Kids Kala is a free learning app for kids aged 2+ — tracing, numbers, shapes, colors, puzzles, and a daily challenge, in environments built for how young kids actually learn. It's live on Android and iOS. My friend led engineering; I owned the product end to end — problem, research, PRD, prioritization, journeys, QA, store readiness, launch, and everything after.
Parents with more than one kid kept telling us the same thing: an app that fits a 2-year-old is too basic for a 7-year-old, and one built for the older kid frustrates the younger one in seconds. So we didn't bury a difficulty slider in a settings menu. The whole app changes based on the child's stage — three different worlds, not one experience with a dial.
Two people, nights and weekends. Every requirement got a P0/P1/P2, and we meant it. The stroke-scoring engine was P0 — meaningful feedback was the whole point, so shipping without it made no sense. The parent dashboard everyone assumes you need? It could wait. And we wrote down what we would not build: no social feed, no leaderboards, no embedded video, no subscription gate at launch. The non-goals list ended more arguments than the priority list did.
We used Claude, Claude Code, Cursor, Copilot, and AI design tools across product thinking, engineering, debugging, and art. Two people got the leverage of a much bigger team. But AI accelerated the execution — it didn't make the judgment calls. What to build, what to leave out, what's right for a child, what quality bar is good enough: those stayed human, and they were the hard part.
From a living-room observation to a shipped product with a two-person team — and a real feedback loop with the parents and kids using it.
Building 0→1 makes prioritization real. When time and people are limited, every yes has a visible cost. Product management is not the production of documents; it is the discipline of making the right decisions from problem discovery through launch.
Working on OneApp, a multi-market consumer platform serving more than 10M monthly users. Product responsibilities have included notification and engagement, release transformation, AI-assisted customer experiences, onboarding, experimentation and regulated digital initiatives. Earlier, I led quality engineering across mobile and platform products, managing engineers and building automation, release-quality and AI-evaluation capabilities.
Led quality strategy and delivery for a regulated US healthcare SaaS platform, working closely with engineering and product teams on complex, high-impact releases.
Worked across OTT, healthcare, hospitality and consumer-platform products.
If you are working on a digital platform, AI-enabled product or enterprise transformation that needs both strategic thinking and hands-on ownership, I would be happy to talk.