Product Owner (2026)
I inherited a team in motion.
No handover. No manual.
In February 2026, I was invited to take on the Product Owner role for the Unicorns team, inside our team that owns the Mercedes-Benz App, following the previous PO's departure. There was no structured transition. Mid-roadmap, no structured transition, no Scrum Master. I owned the backlog from day one: discovery, refinement, sprint planning, stakeholder alignment, and release coordination, all simultaneously.
What I brought wasn't just product willingness. It was a compounded advantage: 10+ years of UX research instinct, deep systems thinking from enterprise design, and a continuous discovery mindset trained across five years of consumer mobile product work at Mercedes-Benz. I knew how to read user signals, frame opportunity spaces, and challenge assumptions before they became sunk cost.
I also brought a different way of working. I use AI agents and Copilot actively across my product workflow, reading epics and tracking patterns at scale, synthesizing meeting transcripts and minutes, aligning requirements across teams, generating ticket drafts from discovery outputs, and surfacing inconsistencies in acceptance criteria before they reach the team. This isn't a productivity hack. It's how I stay ahead of complexity in a fast-moving environment where context is always shifting.
The team had commitments in flight. Stakeholders expected delivery. My job was to orient fast, decide well, and earn trust through outcomes — not explanations.
.
Discovery instinct.
Product discipline.
My UX background didn't slow me down as a PO — it accelerated the quality of decisions. Where other POs might write a user story from a stakeholder request, I was trained to ask: what problem are we actually solving, for whom, and how would we know we solved it? That's continuous discovery thinking (Torres) applied in the room, before refinement even starts.
I also bring something most POs can't: I arrive at every feature with a UX vision already formed. Before handing anything to design, I map the user journey myself — identifying scope gaps, technical ambiguities, and edge cases that need stakeholder clarification before they become blockers. I don't wait for a designer to prepare the ground. I come in with a working model of the flow, challenge it in refinement, and hand the team clarity — not questions. This approach directly accelerated delivery and reduced back-and-forth across both features we shipped in H1.
I structured the backlog around outcomes, not outputs. Epics were framed with a clear problem statement, a defined user segment, and measurable acceptance criteria written in BDD format (Given / When / Then). I treated every refinement session as a discovery checkpoint — using real user data, App Store sentiment, and analytics patterns to challenge assumptions and protect the team from building the wrong thing right.
And I kept the team empowered. Following an empowered teams model (Cagan/SVPG), I owned the what and why — and gave the team the space to own the how. That distinction, held consistently, is what drove retro sentiment from 56% to 66% in a single quarter.
.
133 items. Two quarters.
One team that felt it.
The retro sentiment number is the one that matters most to me. Going from 56% to 66% in one quarter means the team felt better about how we were working — not just what we were shipping. That doesn't happen by accident.
133
Unique items delivered
across H1
208
Story points shipped
Q1 + Q2
66%
Retro positive sentiment
(up from 56% in Q1)
What owning a product
actually feels like.
💜 On trust
You don't earn it by explaining yourself. You earn it by showing up consistently, making decisions quickly, and protecting the team from noise they don't need to deal with.
✏️ On the "what vs how"
The hardest product skill isn't saying no — it's saying "not now, and here's why." Especially when stakeholders want everything and engineering needs clarity yesterday.
😊 On team sentiment
56% → 66% in one quarter. The most important product I was shipping wasn't the feature. It was the team's sense of working well together. That required as much ownership as the backlog.
Two features. Both shipped
Remote Variable Seat for Vans
Mercedes-Benz vans come with rear seats that can be reconfigured into different layouts — from passenger mode to cargo space. Before this feature, drivers had to physically configure the seats themselves. Seat Ballet brought that control to the app.
Users can now remotely select from four preset seat configurations before reaching their vehicle. The feature handles safety logic (vehicle must be off, locked, empty), push notifications for success/failure, and 12V battery blocking conditions — all surfaced clearly in the UI.
The feature was the first of its kind for the MB App in this vehicle segment — and it became the feature the CFO still mentions in conversations. I owned the full product scope: discovery, story mapping, refinement, stakeholder alignment with engineering and QM, edge case definition, and launch.
Remote Control | Safety Logic | SDK Integration
Preferred Charging Providers
MB.Charge aggregates charging services from over 4,000 charge point operators (CPOs) under a single contract. For EV drivers, finding and filtering by preferred providers was impossible — they were presented with the entire list with no way to narrow results.
CPO Filter & Search lets users search CPOs by name, rate them with a three-tier system (Love / Like / Dislike-Avoid), and have those preferences automatically applied to charging station search results and electric route planning via EVRA — synced to the vehicle's head unit.
I drove this from kickoff through technical alignment with three engineering teams (backend, CSP, HU), navigated scope decisions under ambiguity (app vs HU routing, MVP vs full feature), and defined 9 acceptance criteria covering permissions, persistence, sync, and sponsored network handling.
Remote Control | Safety Logic | SDK Integration
The Pitch
Most corporate AI presentations look the same — dense slides, bullet points, feature lists. Mine don't.
When I pitched Agentic Chat and House of AI at MBition's company-wide AI Week, and later presented the platform redesign to the entire organization, I brought something different: a narrative, a visual story, and a point of view.
I build pitches the way I build products — with a clear problem, a sharp idea, and enough craft to make people lean in.
I show the thinking, not just the conclusion.
I use design to make complex ideas feel obvious.
And I bring enough energy that even a simple concept lands with conviction.
The result: two ideas I originated went from internal concept to company-wide initiative — not because I had authority, but because I knew how to make people see what I saw.
The hardest part was never the AI.
On originating ideas
The concept was clear in my head long before anyone else saw the need. Turning personal conviction into organizational initiative requires framing the problem in business terms first — not the solution.
On platform thinking
Designing a platform is a different cognitive mode than designing a feature. You're designing possibility space, not a specific outcome. The metaphor (a "house") was a product decision as much as a design decision.
On adoption
People don't adopt tools because they're good. They adopt them because they remove pain from something they already do. The Figma plugin existed entirely because of this insight — distribution is product strategy.
On AI-Product framing
Calling it "chat with your user" created immediate buy-in. Calling it "AI-powered persona simulation" created skepticism. The language you choose for an AI product is part of the product itself.