Constraints are a gift

Ask a team what would help them most and they'll say the same thing: more. More engineers, more budget, more scope, more time. It's a reasonable answer and almost always the wrong one, because products built with everything they asked for tend to arrive with everything included, including everything nobody needed.

Constraints do something that resources never do: they force decisions. A tiny budget forces you to pick the one thing that matters. A two-person team forces you to delete the feature that was only ever a rumour. An awkward legacy system, which everyone curses, quietly guarantees that you only build what's genuinely worth the pain of building it there.

The best product decisions I've been part of all had an artificial shortage at their centre. “We can only change one screen.” “The migration can't happen this year, so it has to work inside the old thing.” “No new hires until this pays for itself.” Each one felt like a hand tied behind our back at the time. Each one produced a simpler, sharper product than the unconstrained version we'd have happily built instead.

So when I get a new constraint now, I try to catch myself before mourning it. The question isn't “how do we work around this?” It's “what is this constraint trying to tell us about what actually matters?”

Unlimited scope produces mediocre products with total freedom. Constraints produce good products on purpose.