Scoping is a Product Decision

Scope decisions are product decisions. They're not project management housekeeping. When you decide what a product does — and more importantly, what it doesn't do — you're making a statement about what problem you're actually solving, what user you're actually serving, and what your theory of value is. And yet most teams treat scoping like logistics: a list to be negotiated between engineering capacity and stakeholder requests.

I've seen this play out in two directions. Teams that scope too broadly build products that do ten things adequately and nothing well. They launch to indifference. Teams that scope too narrowly sometimes miss the point — they solve a symptom and leave the actual problem untouched. The question isn't 'how much can we build?' It's 'what is the minimum set of decisions that validates our core hypothesis?'

The word 'minimum' in MVP is doing a lot of work that most teams don't take seriously. It's not 'minimum effort.' It's 'minimum necessary to learn what we need to learn.' Those are different constraints, and mixing them up is why so many MVPs ship without actually answering the product question they were designed to test.