Priorities, Not Scope

The moment a fixed scope is defined, a negotiation is created. Every conversation becomes about what's in and what's out. The client starts counting. "That's related, it should be included." "That's basically the same work." Arguments follow. Relationships strain. Projects derail. Scope creep isn't caused by clients asking for too much — it's caused by scope existing in the first place.

The Priority Queue

Replace scope with a priority queue. The client maintains a ranked list: most important at the top, least important at the bottom. The developer works top-down, always building the highest-priority thing.

The client wants to add something? Add it. Just decide where it ranks. The client wants to change direction? Reorder the list. There's no "in scope" versus "out of scope" — there's only what's next.

One Thing at a Time

A WIP limit enforces real prioritization. Adding a new task means stopping the current one. When something urgent comes up, the question is simple: does the current work stop, or does this go into the queue? The client chooses. But the choice is explicit. Both can't happen at once.

This kills the "everything is urgent" problem. When everything is urgent, nothing is. The queue forces actual business thinking — what matters more right now, this or that?

What the Client Learns

The client can have anything. The client can't have everything — not all at once. The queue makes that visceral. "Yes, the developer can build that. What stops in order to start this?" It's a hard question. It's also the right question. Better answers lead to better products.

What Both Sides Get

Both sides always know what to work on next. No ambiguity, no scope debates, no defending line items. Just the top of the queue and the work itself. Simple. Effective.