Hertz Premier Curbside, Yatin Patel

Hertz already offered curbside pickup to its top-tier loyalty members. But you couldn’t choose it when you booked. Field teams ran it by hand, on an old operations portal, and often learned about a pickup late. The service depended on people scrambling.

I was asked to fix that in early 2026. I built the first digital product for the service, from zero, and we took it to a live pilot at Fort Lauderdale in July 2026.

The problem

A premium pickup only feels premium if the car is ready when the customer walks out of the terminal. That means the field team has to know three things early: who is coming, whether they want the car at the curb or at a stall, and when they will land.

None of that was captured when a customer booked. So I treated it as an information problem first and a technology problem second.

Before and after: from spreadsheets and phone calls to one question at booking and a live manifest for the field team. Illustrative.

Context

This is a physical service with real constraints:

Field labor is scheduled in whole shifts, so you can’t add a driver for one pickup.
Staff and customers reached each other by phone only.
Every change to the Hertz app waits for app-store review.
The systems that assign vehicles belong to other teams and change slowly.

My role

I was the founding product owner. I framed the problem, wrote the plan and led the build across three surfaces: hertz.com, the Hertz app and a new handheld app for field staff. I trained the first airport team myself, six days before go-live. Later, I booked my own pickup to see the service the way a customer does.

Approach

Field research first. I spent time with operations teams at four airports before writing requirements.
One question at booking. Curbside or self-service at a stall, with both options presented as equals. That one answer lets the field team plan instead of scramble.
Manual first, on rails built for automation. The first version kept people in the loop, but every step wrote to the systems we would later automate.
Feature flags and kill switches on everything, with one master switch for incidents.
Slices that ship on their own, so a delay in one part never held up the rest.
Go and no-go thresholds, with a written rollback plan.

The customer’s four steps: book, choose curbside or a stall, tell us you’re on the way, find the car at the curb. Illustrative.

Key decisions

From one surface to three. The first plan was web only. Customers book in the app and staff work on handhelds, so I widened the scope and kept a web fallback.
Replace the old portal, but not the vehicle system. We built a digital manifest for this tier and left vehicle assignment in the existing system. That kept the launch small and safe.
iOS first. When dependencies slipped, I moved the pilot date by four weeks, said so plainly, and launched iOS first rather than slip everything.
A prototype in week one. I used an AI-generated prototype of the customer and operations apps to get leadership aligned before any code was written.

Results

The Fort Lauderdale pilot went live in July 2026.
It is now a platform we are scaling to more loyalty tiers and markets.

I’m not sharing usage or satisfaction numbers yet. The service isn’t fully public, and the early samples are too small to prove much. We label the satisfaction effect “not established” until there are enough responses, and I’ll add results here when they hold up.

What I learned

The physical world sets the experience. When I booked my own pickup, the wait came from the drive from the lot to the curb, not from the app. Lot distance and dispatch timing matter more than any screen.
Dates slip on dependencies, so plan the slices. Shipping in independent pieces kept us moving when one dependency stalled.
Make the honest call early. Moving the date and saying why cost us a few weeks and kept our credibility.