The Observation

Last month, I walked into a premium car showroom to get a minor dent fixed. It was a two-hour job at best—a bit of panel beating and a touch of paint.

The Service Advisor took one look and gave me an estimated delivery time of 20 days.

I was baffled. I asked, “Why?” He gave me a vague answer about “parts availability” and “paint booth queue.” But when I looked around, I saw hundreds of cars zooming in and out of the service bay for their periodic maintenance—oil changes, filter checks, washing. They were entering at 10 AM and leaving by 4 PM.

My curiosity as a Product Manager kicked in. I decided to dig deeper. I interviewed 10 car owners who had faced similar repair delays. The pattern was identical: Minor damages (scratches/dents) were consistently deprioritized, with wait times ranging from 15 to 25 days.

Why does a complex engine overhaul happen faster than a simple bumper repair? The answer isn’t incompetence. It is a classic case of incentive design and resource optimization.

The Conflict: Throughput vs. Latency

In Product Management and Systems Design, we often talk about two competing metrics:

• Throughput: How many units can I process in a given time? (Volume)
• Latency: How long does it take to process one specific unit? (Speed)

Car dealerships are businesses optimized for Throughput.

1. The “Service Lane” (The Happy Path)

Periodic servicing is the dealership’s “Happy Path.” It is predictable, standardized, and high-volume.

• Inventory: Oil filters and coolants are always in stock.
• Process: Standard Operating Procedures (SOPs) are fixed.
• Outcome: A technician can clear 5 cars a day.
• Revenue: High turnover.

2. The “Repair Lane” (The Edge Case)

Accidental repair is the “Edge Case.” It is unpredictable and high-variance.

• Inventory: You never know which door handle or bumper clip is broken. Parts must be ordered (External Dependency).
• Process: Insurance surveyors need to visit and approve estimates (Bureaucratic Latency).
• Outcome: A car might sit in the bay for 3 days just waiting for a signature.

The Incentive Mismatch

This is where the system breaks for the user.

I found that Service Advisors are heavily incentivized on volume targets. Their monthly bonus depends on how many “Job Cards” they close.

• If they focus on the Service Lane, they can close 20 cards a day.
• If they focus on my dented car, they might close 1 card in 20 days.

From the dealership’s perspective, my car is a bottleneck. It occupies a parking slot that could have been used to service 50 other cars over those 20 days. To them, my repair job isn’t just low priority; it’s an opportunity cost.

So, what do they do? They batch the repairs. They let the “difficult” repair cars pile up in the back until they have enough free capacity to deal with them without disrupting the high-speed service lane.

They have optimized their system for their efficiency, not my experience.

The Product Management Lesson

This is exactly what happens in software teams if we aren’t careful.

We often build products that work beautifully for the “Happy Path” (the 90% of users who do the standard thing). We optimize our dashboards for standard data, our support for standard queries, and our onboarding for standard users.

But when a user hits an edge case—a failed payment, a forgotten password, a legacy data import—they fall into a “20-Day Dent” hole. They enter a manual, slow, broken process because we never designed a system to handle variance.

Great Product Management is about designing for the exception. It’s easy to build a system that works when everything goes right. The real skill is building a system that flows even when things go wrong.

Conclusion

The next time a showroom tells you a dent will take 20 days, know that you aren’t waiting for paint to dry. You are waiting for their business model to find a slot for you.

The Takeaway for PMs:

Look at your own product backlog. Are you prioritizing the “quick wins” (Service Lane) so much that your “complex problems” (Repair Lane) are rotting in the queue? Efficiency is good. But if your efficiency comes at the cost of user suffering, you haven’t optimized the system—you’ve just hidden the mess.