"Collect everything, decide later" sounds safe. In practice, I've found it's one of the more expensive defaults a data product can adopt, because every field collected "just in case" keeps costing something long after the case never arrives.
The cost that doesn't show up on a dashboard
More fields mean more to crawl, more to validate, more edge cases in QA, and more surface area for something to break quietly. None of that shows up as a single line item — it shows up as a pipeline that's slower to change, harder to reason about, and more expensive to keep healthy, for the benefit of data that never gets used. I wrote more about this specific pattern in the most expensive data is the data that changes nothing.
Relevance over volume
The useful question isn't "can we collect this," it's "does this earn its place." That's one of the principles I return to often: the objective isn't maximum collection, it's maximum usefulness — covered as one of six principles behind how I think about systems. In practice this has meant categorizing data by relevance and business priority rather than treating every available field as equally worth collecting, which is exactly the shift described in the Too Much Data → Less Noise case.
“The useful question isn't "can we collect this," it's "does this earn its place."”
A worse product, not just a slower one
Unused data doesn't just cost engineering time. It makes the product itself harder to use — more fields to filter through, more noise around the signal that actually matters. Reducing what gets collected, done deliberately, is often the highest-leverage change available, and it's frequently more valuable than adding another feature on top of an already-cluttered dataset.
Read the case behind this
Too Much Data to Less Noise is one of four patterns in what changed because I worked on it.
What Changed Because I Worked On It · How I Think About Systems