Most requirements are dumb

"Your requirements are definitely dumb. It does not matter who gave them to you."

That's Elon Musk. Provocative, yes—but he's pointing at something most teams refuse to acknowledge: requirements are rarely challenged. They're passed through.

Someone says "the customer wants a faster horse." The team builds a faster horse. Nobody stops to ask: do they want a horse, or do they want to get from A to B quickly?

This isn't a knowledge problem. It's a curiosity problem.

Extracting the real need requires effort. You have to ask why. Then ask again. You have to hold multiple hypotheses in your head without collapsing to the first plausible answer. You have to think ahead to consequences, trade-offs, second-order effects.

Most people don't do this. It's easier to execute than to question. Easier to say yes than to push back. Easier to add the feature "just in case" than to defend its absence.

But here's the uncomfortable truth: you're going to piss people off either way.

Push back on wishes, and you lose short-term credibility. Accept too many, and you lose long-term credibility when the product becomes a bloated mess that solves nothing well.

I'd rather do what's right.

Engineers: stop executing blindly. Challenge the requirement. Either you're right, or you learn something about the customer. Both are wins.

Product people: stop collecting wishes. Your job is to create understanding deep enough to make real trade-offs—not to pass along requests with a Jira ticket attached.

The most dangerous requirements come from smart people—because nobody questions them. Question them anyway.

Requirements aren't sacred. Most of them are lazy hypotheses dressed up as facts.