Why we cut scope before we design anything

Most teams design broadly and cut scope later, under deadline pressure, which means the cutting happens badly: rushed, resentful, and usually in the wrong places, because there's no time left to be thoughtful about what to remove. We do it in the opposite order. We cut scope until the product does one thing genuinely well, before a single screen gets designed, and only then do we start building.

This sounds like a small sequencing choice. It isn't. A feature that survives an early, unhurried scope review earns its place for a real reason. A feature that survives a late, panicked one survives because nobody had the energy left to argue against it. Those are different kinds of feature lists, and they produce different products.

The uncomfortable part of this discipline is that it requires saying no to good ideas, not just bad ones. Nothing ships by default is easy to agree with in principle and hard to practice, because most of what gets cut isn't obviously wrong, it's just not essential yet. Cutting the merely-good is where the actual discipline lives.

Cutting the merely-good is where the actual discipline lives.

We think the fear behind resisting this, that a smaller v1 looks unambitious, has it backwards. An unfocused v1 tries to prove ambition by doing many things adequately. A focused v1 proves it by doing one thing well enough that people notice. We'd rather ship the second kind and add the rest later, once we know it's earned, than ship the first kind and hope nobody notices which parts don't work.