Book, Hertz, 2026

The Hertz app as a travel companion

Strong at booking, thin after pickup. In four weeks, a familiar phrase became a test, an evidence base and an honest scoreboard.

At a glance

My role
Product lead for the Hertz app since August 2026
Team
Two product managers on my team (US and India), the app engineering team and design
When
August to November 2026
What changed
A shared test for what counts as companion work, a trip-stage map of the app, an experiment tracker and a proposed way for partner teams to build in one app.

I took over the Hertz app in August 2026. It was good at one thing: booking. After pickup, it had much less to offer. People had been calling it a “travel companion” for over a year, but the phrase had outrun the evidence.

Design had already drawn the vision and a roadmap. What was missing was evidence, priority and a way to measure progress. That was my job.

The problem

“Travel companion” meant something different to everyone. Without a shared picture, every feature could claim to be companion work, and nothing could be prioritized against anything else.

Context

The app had just moved to a new codebase. It is shared by many teams, each with its own goals for the trip they own: booking, pickup, the rental itself, returns and help.

The app's strengthPlanBookPickupRentalReturnHelp
The app’s strength at each stage of a rental trip: strong at booking, thin after pickup. Illustrative values.

My role

  • Built the evidence and framing package, and ran the design working session that shaped it.
  • Wrote the capability phasing and the success measures for the leadership strategy.
  • Re-scoped a stalled booking-form project in my first week.
  • Built an experiment tracker for leadership.
  • Proposed how partner teams can build together in one shared app.

Approach

  • Audit the real thing. With AI agents, I audited the live app end to end in a day, including one real booking changed through every scenario, and five competitor apps.
  • Map everything to the trip. I mapped more than 200 capabilities against the stages of a rental trip. The map showed the gap at a glance: strong at booking, thin after pickup.
  • A three-question test. Does the app move first? Does it use what it knows about the trip? Does it close the loop in the app, without a call? If a feature fails all three, it isn’t companion work.
  • Baselines before claims. No result gets credited until we know what would have happened anyway.
Does it move first?Does it use what it knowsabout the trip?Does it close the loopin the app?
The three-question companion test.

Key decisions

  • Trip stage is the main axis. An empty stage proves the gap better than any slide.
  • Keep the sponsor’s framing as an alternate view, so the work speaks the language leadership already uses.
  • Don’t take credit we didn’t earn. Calls about bookings fell during the period, but the app didn’t cause most of that. I pointed our scoreboard at contacts during the trip, where the app can make a difference.
  • No false precision. The roadmap shows direction and order, not invented dates.
  • One team builds, partners own the rules. My proposal: one engineering team builds for everyone, partner teams own the business rules and results for their part of the trip, and one intake and one scorecard govern the work. Success is measured per trip, not by daily use.
  • Check every test result. I re-checked every A/B read before it drove a decision. That caught a “roll back” signal caused by an uneven traffic split, and a reported booking drop that didn’t reproduce.
A proposalPartner teamowns its rules and resultsPartner teamowns its rules and resultsPartner teamowns its rules and resultsPartner teamowns its rules and resultsOne engineeringteamOne intakeOne scorecard
A proposal: one engineering team builds, partner teams own their rules and results, one intake and one scorecard. Illustrative.

Results

These are team results for the app I lead. Most of the work behind them happened before I took over in August 2026.

  • Rated 4.8 stars from about 547,000 App Store ratings.
  • App bookings convert at more than twice the web rate, and about 4 in 10 Hertz bookings happen in the app.
  • Product changes this year show about a 2% lift against a holdout group.
  • In my first week, I reconciled a stalled booking-form redesign against its engineering tickets, closed the gaps and re-sequenced the work so it could ship. The team’s A/B test then showed the redesigned booking screens lifted bookings by about 1.3%.
  • I took over delivery of a feature that shows loyalty members their car and parking spot in the app, split it into phases so the core view shipped first, and got it live in September 2026. About a third of Gold members shown the card use it.
  • The app has shipped a new release every few weeks since August.

What I learned

  • Trip order is a diagnostic, not a layout. Laying capabilities along the trip shows where the product is missing.
  • Redefine the measure instead of caveating the target. If a target counts the wrong thing, change what it counts.
  • Use the sponsor’s own words as labels. People read faster when the page speaks their language.
  • Set a baseline before attributing. Otherwise the product gets credit for things it didn’t do.
  • Search for prior work first. Much of what I needed already existed in someone’s drawer.