Platform Product Management Carvana · ADESA Oct 2024 – Dec 2025

From Spreadsheets to Unified Platform

How I led the discovery, design, and delivery of ARC — a centralized arbitration management platform at one of America's largest used car marketplaces — by going where the work actually happened, inheriting a fragile legacy system, and shipping to every auction in the network before I left.

Project Overview
Role Senior Product Manager
Company Carvana
ADESA Wholesale Marketplace
Team 6 Engineers
FE · BE · Architect · Lead
Platform ARC · AMS Integration
Timeline Oct 2024 – Dec 2025
Status Deployed
<1 day
First touch time achieved — down from 1.12-day baseline
99%
Data sync issues resolved in a focused 2-week hardening sprint
100%
Of auction locations live on ARC before I left Carvana
4
Roadmap phases delivered or in-flight across the platform

A process held together by tribal knowledge and spreadsheets

At Carvana's ADESA wholesale marketplace, arbitrations — buyer claims against vehicle condition after a sale — are a direct cost against wholesale revenue. Every claim that drags on too long, gets misrouted, or bounces between the wrong people costs money. And in Q1 2025, the numbers told a clear story: the average arbitration claim lived for 22.2 days, resolution took nearly 12 days, and first contact with a claim averaged over a day from submission.

The tooling matched the problem. The Centralized Arbitration Team in Tempe was juggling AMS, Zendesk, and phone calls to local auctions. Physical auctions were tracking inbound vehicles on spreadsheets. Gate personnel at auctions had no reliable way to know whether a vehicle pulling in was an arbitration unit or a routine return — which meant it sometimes went straight back into the sales funnel.

The Deeper Issue

The tools were a symptom. The underlying problem was that no one had a shared view of what was happening to a claim — not the central team, not the local auctions, and certainly not the buyers waiting on a resolution. Everyone was operating with partial information and filling the gaps with phone calls, emails, and judgment calls.

Inheriting a concept, shipping a platform

I joined as Senior Product Manager owning the ARC platform and the end-to-end arbitration product vision. My predecessor had laid conceptual groundwork for an online arbitration submission portal — mockups, some early requirements — but nothing had shipped. I took those mockups and made them real.

That delivery was the first proof point. But the larger ambition — building ARC as the single platform for arbitration management across every sales channel and every auction location — that started from scratch on my watch. I owned the roadmap, the stakeholder relationships, the backlog, and the delivery.

I went where the work actually happened

Before I committed to a roadmap direction, I did something that doesn't show up in any requirements doc: I got on planes. I spent time shadowing arbitration clerks and managers at physical auction locations and at Carvana's headquarters in Tempe, Arizona — watching the process unfold in real time, asking questions, and observing what people actually did versus what the documented process said they should do.

Most of what I learned wouldn't have surfaced in a stakeholder interview or a Jira ticket. You had to be in the room — or on the auction floor — to see it.

What Field Research Revealed

The tools weren't the root cause. The communication breakdown between people was. The Centralized Arbitration Team in Tempe would request action from a local auction and hear nothing back. One auction would ship a vehicle to another auction for defect inspection without any heads-up. Gate personnel processed arbitration vehicles as normal returns because no one told them otherwise. Every gap in the process was a gap in communication — and the tools were making it invisible.

That insight shaped everything that followed. The platform I needed to build wasn't just a better AMS. It needed to make the status of every claim visible to everyone who needed to see it — and automate the handoffs that were falling through the cracks.

A phased roadmap built around the most complex user first

The Centralized Arbitration Team was the right place to start. Their workflow was the most complex — navigating multiple AMS instances, toggling between Zendesk for communications, and relying on local auctions to respond in a timely way. If the platform worked for them, the physical auctions would benefit automatically as the shared foundation improved.

Complete
Online Submission
  • Buyer self-service claim portal
  • Integrated claim validation
  • Reduced non-arbitrable disputes
  • Online claim status view
Q2 — Foundations
Centralized ARC Platform
  • Single portal across all locations
  • Claim validation & resolution
  • Automated buyer notifications
  • File attachments & admin assignment
Q3 — Automation
Communication & Logistics
  • Integrated messaging within ARC
  • OneGuard inspection scheduling
  • Automated auction vehicle return flow
  • Inbound vehicle notifications
TBD — Buyer
Enhanced Buyer Experience
  • Enriched claim view with issue status
  • Real-time resolution updates
  • Automated claim notifications

The communication and logistics features landed in Q3 deliberately — not because they were lower priority, but because they depended on a stable foundation to build on. You can't automate auction handoffs until you have a platform both sides are actually using.

Building new while keeping the old alive

The most significant technical challenge on this project wasn't the new platform — it was the legacy system sitting underneath it. AMS, the existing arbitration management system, was built on PowerBuilder and relied on database triggers to keep data synchronized across tables. There was no application logic layer to interrogate. The business rules lived inside the database itself, undocumented and tangled.

The team responsible for maintaining AMS was in the process of being sunset. The remaining engineers had limited familiarity with the codebase, and any question we needed answered — "what happens when a claim reaches this state?" — required one to two days of them digging through legacy code before we got a response.

The Technical Inheritance

We had to keep AMS synchronized with ARC in real time because downstream systems — auction logistics, title operations, finance — still depended on it. Building the new platform without breaking the old one meant operating in the dark on the business logic that held everything together. Every integration decision carried risk we couldn't fully quantify. (In hindsight, this would have been a textbook use case for AI-assisted code analysis — but at the time, the tooling wasn't there yet.)

The two weeks that fixed 99% of the problems

As development progressed, data synchronization issues between ARC and AMS started surfacing. Claims would update in one system and lag in the other. Edge cases in the legacy trigger logic would produce unexpected states. The volume of issues wasn't catastrophic, but it was consistent enough to be a risk to any features we built on top of an unstable foundation.

Rather than continuing to ship features and accumulate technical debt, I made the call to pause all new development for two weeks and redirect the team to find and fix the synchronization issues. It was an easy call to second-guess — two weeks is visible on any roadmap — but the right one.

The Right Call

The two-week sprint resolved 99% of the synchronization issues the team had been chasing. With a stable data layer, every feature we built afterward worked as designed. The brief pause bought us a much cleaner delivery track for the rest of the roadmap — and avoided a much more expensive debugging effort down the line.

Every auction in the network. Before I left.

By the time I left Carvana, ARC was live across every auction location in the network. The online submission portal — available to dealer-buyers on both mobile and web — had launched and immediately validated a hypothesis I'd carried into the build: buyers would submit claims on the weekend if you gave them a self-service experience worth using. That channel took off, and first touch time crossed below the one-business-day target — not just on paper, but in practice.

Resolution time improved. The lifespan metric moved toward the target. But the outcome I'm most proud of wasn't a number — it was the reaction from the people who had lived with the old process.

User Delight

Local auction teams were especially energized by one specific capability: for the first time, they could see which auction an arbitration vehicle belonged to before it arrived. That sounds small. For teams who had been coordinating cross-auction vehicle transfers via phone and email — and sometimes not at all — it was a fundamental change in how they worked. The new interface, the ease of access, and the roadmap features generated genuine excitement from end users who had spent years frustrated by the old system.

What I'd do differently

1
Move faster on feature sequencing decisions

There were moments in the roadmap where I deliberated longer than necessary on which feature to tackle next. The discovery work had given me a strong user signal — I should have trusted it more and moved with more urgency. In a platform build with this many stakeholders, speed of decision-making compounds. Slow choices at the top of the queue slow everything downstream.

2
Push the engineering team harder on pace

There were stretches where the team's velocity didn't reflect the urgency the business had for this platform. I worked constructively with the team throughout, but in hindsight I could have been more direct in raising the expectation — with the team and with leadership — when pace fell short. Protecting the team from pressure is part of the job; shielding them from accountability isn't.

What this project required

Platform Product Management User Discovery & Research Legacy System Integration Stakeholder Management Roadmap Prioritization Cross-functional Leadership Agile / Scrum Backlog Management Operational Process Design Go-to-Market Planning Data Synchronization Strategy Field Research