Product Owner (2026)
No handover. No runway.
Full ownership from the start.
In February 2026, I stepped into a Product Owner role mid-roadmap, mid-sprint with a team already in motion and stakeholders expecting delivery. No structured transition. No Scrum Master. I ran backlog, discovery, refinement, sprint planning, stakeholder alignment, and release coordination simultaneously. Not because I had to figure it out. Because 10+ years of building consumer mobile products at Mercedes-Benz and Volkswagen had already taught me how decisions get made, where features fall apart, and what a team needs to do their best work. I oriented fast. I decided well. I delivered.
How I work.
Before any feature reaches the team, I've already walked the user journey mapped the flow, identified the gaps, flagged the technical ambiguities, and framed the questions that need stakeholder answers before they become sprint blockers. The team gets clarity from day one. Not after three rounds of back-and-forth.
Scope mapping for Remote Seat Configuration user journey and edge cases mapped before refinement began.
I start every feature with data. Before discovery begins, I analyze existing usage patterns in Firebase — drop-off rates, adoption curves, feature engagement — to understand where users struggle and where opportunity exists. I define the tracking strategy before a single line of code is written: which user actions get instrumented, which KPIs measure success, and what good looks like at launch. Data informs the brief. The brief informs the backlog.
I structure backlogs around outcomes, not outputs. Problem statements with a defined user. Measurable acceptance criteria in BDD format (Given / When / Then). Every refinement session is treated as a discovery checkpoint — using App Store sentiment, Firebase data, and user research to challenge assumptions before they become sunk cost.
I use AI agents and Copilot actively across my workflow — reading epics at scale, synthesizing meeting transcripts, aligning requirements across teams, generating ticket drafts from discovery outputs, surfacing inconsistencies in acceptance criteria before they reach engineering. The product environment is always changing. This is how I stay ahead of it.
And I keep the team empowered. I own the what and the why. They own the how. That distinction — held consistently, every sprint — is what changes how a team feels about its work.
The results
Two quarters. Two big deliveries. One incredible team.
133
Unique items delivered
across two quarters
208
Story points shipped
Q1 + Q2
66%
Retro positive sentiment
(up from 56% in Q1)
The last number is the one I'm most proud of. It means the team felt better about how we were working — not just what we were shipping. That doesn't happen by accident. It happens when the PO protects the team, makes decisions quickly, and owns the ambiguity so the team doesn't have to.
What I learned.
On trust
Trust isn't built through explanations. It's built through consistent decisions, fast responses, and protecting the team from noise they don't need to carry.
On scope
The hardest call isn't saying no — it's saying "not now, and here's why." Holding that line, calmly and consistently, is what keeps a team focused and a roadmap honest.
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 requires as much ownership as the backlog.
Two features.
Full product ownership from discovery to delivery.
Ownership isn't a title. It's a posture. You show up before the problem is visible. You make the call before consensus is comfortable. You protect the team from unnecessary noise and absorb the ambiguity they shouldn't have to carry. The best product decisions I made weren't in refinement sessions. They were in the moments before — when I'd already walked the journey, analyzed the data, identified the gap, and arrived with a point of view instead of a question. That's the kind of PO I am. And it's the kind of product work I want to keep doing — at scale, in fast-moving environments, on products that matter to millions of people.
Remote Variable Seat for Vans
Mercedes-Benz App
Planned for launch September 2026 with the new Van lineup
Mercedes-Benz vans offer rear seats that reconfigure into multiple layouts — from passenger mode to cargo space. Before this feature, drivers had to do it manually. This feature brings that control to the app.
Users will be able to remotely select from preset seat configurations before reaching their vehicle. The feature handles complex safety logic — the vehicle must be stationary, locked, and unoccupied — push notifications for success and failure states, and 12V battery blocking conditions, all surfaced clearly in the UI.
Data & tracking: Pre-discovery analysis of remote feature usage across similar MB App functions identified adoption patterns and drop-off points that informed the feature scope. Pre-launch Firebase instrumentation covers feature open rate, configuration completion rate, preset selection distribution, error and blocking state rate, and retry behavior.
Stakeholder alignment & vehicle constraints: Coordinating this feature required alignment across SDK, engineering, and QM teams — navigating hardware constraints that define what the vehicle can and cannot do remotely, and what safety conditions must be met before any action executes. I owned the scope decisions, defined the edge cases, and drove QM alignment on acceptance criteria before refinement began.
I owned the full product scope: discovery, story mapping, refinement, cross-functional alignment, edge case definition, and handover to QM.
Remote Control | Safety Logic | SDK Integration
EV Charging Provider Management
Feature complete — currently in QM validation
MB.Charge connects drivers to 4,000+ charge point operators under a single contract. The problem: no way to filter, prioritize, or personalize. Drivers faced an unmanageable list with no structure and no preferences saved.
Users will be able to search providers by name, rate them with a three-tier preference system (Love / Like / Dislike-Avoid), and have those preferences automatically applied to charging station results and electric route planning — synced to the vehicle's head unit.
Data & tracking: Pre-discovery analysis of charging feature usage in Firebase revealed significant drop-off in the provider search flow and low engagement with the full CPO list — validating the opportunity. App Store reviews confirmed user frustration with provider complexity. Pre-launch instrumentation covers search adoption rate, provider rating rate, preference application rate in EVRA route planning, head unit sync success rate, and 30-day preference return rate.
Stakeholder alignment & vehicle constraints: This feature required simultaneous alignment across three engineering teams — backend, charging services platform, and head unit — each with different timelines and cross-dependencies. Key decisions included where preference logic lives (app vs backend vs head unit), how vehicle sync latency affects the user experience, compatibility constraints across MB vehicle models, sponsored network handling when a preferred provider is marked as Avoid, and MainUser vs SubUser permission logic for multi-driver accounts.
I drove this from kickoff through technical alignment, scope decisions under ambiguity, 9 acceptance criteria covering all edge cases, and delivery to QM.
EV charging UX | Safety Logic | Route Planning | SDK Integration
The team behind the numbers
Behind every metric, there's a team that made it possible.
We started the quarter with a PO transition and no structured handover. Mid-sprint, we lost our designer. The team absorbed every change without losing pace, quality, or focus. They were the most committed, most resilient group I've worked with — and the results reflect that. At the end of H1, in the Sprint Review, in front of all stakeholders, I paused the metrics. Because numbers matter — but the people behind them matter more.
I took time to recognize each person individually. Their ownership, their craft, their willingness to keep showing up through every change. The stakeholders were proud — impressed by the data, moved by the team's resilience, and vocal about how glad they were to have that kind of product leadership driving the work.
That moment mattered as much as any feature we shipped. Recognition is part of leadership. When a team feels seen — publicly, specifically, sincerely — they bring more of themselves to the work. That's not a soft skill. That's how good products get built.
That's the kind of leader I am. And the kind of team I want to build again.
