Why I stopped serving our biggest customer (and they thanked me, later)
The 200-person department that taught me everything about strategic focus.
"I let it be ugly for the sake of actually building a great business." - Selina Tobaccowala, SurveyMonkey
Back in PayPal's scaling days, the company made a choice that seems unthinkable today. As user numbers grew exponentially, they completely ignored customer complaints. We're talking 10,000 angry emails per month, customers calling so frequently they had to block corporate phones, people literally showing up at the office to complain in person. The customer service team? Three people.
Reid Hoffman—a pretty big guy—had to physically push complaining customers out of the offices.
This wasn't negligence. It was strategic resource allocation. Every hour spent on customer service was an hour not spent on the core product that would eventually serve millions. They let massive problems burn because they knew trying to fix everything would kill their ability to scale.
If you only have 5 minutes: here are the key points
Legendary companies like PayPal let customer service crises burn to focus on core growth—strategically ignoring problems to scale.
Great product managers don’t extinguish every fire—they decide which to let burn based on long-term impact.
The author shares a real-life example of halting support for a large department to prioritize strategic work, which led to better outcomes for everyone.
Not every complaint is a real fire; true fires cause compounding damage and must be prioritized.
Premature perfection (the quality trap) can be more damaging than fast, iterative delivery.
Clear communication—especially when things go wrong—is what enables teams to tolerate short-term pain for long-term gain
Most product managers today would call this insane. The OKR gospel tells us every metric should be green, every customer satisfied, every fire extinguished immediately. Customer satisfaction drops from 4.2 to 4.1? Emergency meeting. Support tickets hit 25 hours instead of 24? All hands on deck.
But here's what I learned after managing products for over seven years: the best product managers don't fight every fire. They choose which ones to let burn.
The 200-person department I stopped serving
As PM of an internal data team serving 700 employees across the company, I faced a choice that would define everything. We needed to execute a major strategic shift following a company pivot, but we were spread across five different departments.
The biggest fire? A 200-person department that consumed 60% of our resources with endless requests for custom reports and dashboard tweaks. Every week brought new "urgent" demands that pulled us away from strategic work.
Most PMs would optimize for the largest customer segment. I did the opposite.
I simply stopped serving them.
I put three departments on the back burner and focused entirely on the smallest department—only 15 people, but the most strategically important for the company's future. The 200-person department was furious, called multiple meetings with me and some higher executives. They demanded explanations for why their "critical business needs" were being ignored.
But here's what happened: Within a year, that 200-person department built their own BI team, which served them far better than our centralized approach ever could. Meanwhile, our focused effort on the strategic department delivered results faster than we'd ever achieved.
The fire I let burn—angry users demanding immediate attention—allowed us to build something that made their complaints irrelevant. They got better service by solving their own problem, and we delivered transformational value where it mattered most.
What qualifies as a real fire
After three years of letting problems burn, I learned to distinguish between real fires and noise:
Not fires: Feature requests, nice-to-haves, the "wouldn't it be cool if..." category.
Probably not fires: Legal edge cases with low probability. We once needed signed permissions for marketing materials but decided the 5% lawsuit risk wasn't worth two weeks of legal back-and-forth when we had a 50% chance of not surviving the next year anyway.
Actual fires (that we might still let burn): Problems that cause real pain, real damage, real consequences that compound daily.
The key insight: putting out fires consumes resources exponentially. If you spend your day fighting fires, you're not moving forward. For startups, that means fading into irrelevance while competitors ship the features that actually matter.
The quality trap that kills products
"You could've spent more time on quality," is what everyone says after something breaks.
Yes, and strategic burners will tell you: hindsight is 20/20. You could have spent more time, but moving slower doesn't guarantee quality—it guarantees delays. And delays push you into uncertain waters where your product might not get used at all.
Quality is only a problem on features that are used heavily. Heavy usage is a sign of success.
When we rolled out a new analytics tool to a few dozen users, we used a simple AWS EC2 instance—the fastest way to get it running. We considered a Docker cluster with built-in redundancy, but that would've added two weeks.
The instance broke within a week. Then it broke again when we replaced it with a larger one. The third time it held for months. Only when user numbers hit an all-time high did we finally implement the redundant setup.
I wouldn't do it any other way.
The communication rule
The biggest learning isn't about tactics—strategic burners still let problems burn every day. The difference is communication.
When things break, communication disappears first. Without it, you lose all basis for evaluating importance. The key is explaining: "YES, we see the problem, but we have to solve a bigger one first (scale, adoption, speed), and THEN we'll solve this much more efficiently."
After using our manual backup system once, we built an automated one that restored service in 30 minutes instead of hours. Sometimes the best way to solve problems is to outgrow them.
Why this feels impossible
The hardest part isn't the strategy—it's living with the discomfort. Users will complain. Teammates will question your priorities. You'll wake up at 3 AM wondering if you're making the right call.
But here's the truth Reid taught PayPal: every fire you don't fight is time you can spend building something that makes those fires irrelevant. While others optimize satisfaction scores, strategic burners build products so valuable that customers forget to complain.
The best product managers don't fight fires. They slowly build fire-resistant products.