Why We Read the Support Inbox Before We Read the Spec
The spec tells you what someone wants built. The support inbox tells you what's actually broken.
Every project we take on comes with a spec. Sometimes it's a polished document, sometimes a Notion page, sometimes a founder's voice memo transcribed into bullet points. We read it. But we don't read it first.
Before we open the spec, we ask for the support inbox. The tickets, the Slack complaints, the one-star reviews, the "quick questions" that turned into three-email threads. This is where the actual product lives, not the one someone imagined when they wrote requirements, but the one people are using right now and struggling with.
Specs are aspirational by nature. They're written before the hard parts are discovered, which means they're optimistic about edge cases, forgiving about ambiguity, and usually silent on the stuff that actually eats engineering time. The support inbox has none of that generosity. It's just users hitting walls and describing, often badly, where the wall is.
We've caught entire categories of technical debt this way before writing a line of code. A pattern of "why did my upload fail" tickets tells us more about a broken retry mechanism than any architecture diagram will. A recurring "I lost my work" complaint tells us the autosave logic is a fantasy, not a feature. These aren't things you find in requirements, because nobody specs out how a system fails. They only show up in the aftermath.
This habit also keeps us honest about priorities. It's easy to build what's interesting. It's harder to build what's actually costing someone their afternoon. Reading support tickets first forces us to see the gap between the roadmap and the pain, and usually those two things only partially overlap.
By the time we do read the spec, we read it differently, less as instructions and more as a hypothesis to test against what we already know is going wrong. That's usually where the real project begins.