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.
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 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.
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.
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.
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.
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.
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.
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.
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.)
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 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.
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.
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.
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.
There were stretches where the team's velocity felt inconsistent with the scope of work ahead. I was too patient. A more direct, data-grounded conversation about delivery expectations — earlier in the project — would have created better accountability without damaging the team dynamic. Cycle time and sprint completion rates were there to make the conversation factual rather than personal. I should have used them.