Scoping a Feature So It Actually Ships

We estimated three weeks for a notifications system. It shipped in four months. Nobody was lazy, nothing was technically hard, and the estimate wasn't especially naive. The scope was.

"Notifications" is not a feature. It's a category. And a category expands to fill whatever time you give it, because every conversation about it legitimately adds requirements.

How it actually expanded

1. 01Week 1: in-app notifications. Simple. Building it.
2. 02Week 2: "Obviously email too." Fine, that's a template system and a queue.
3. 03Week 3: "Users will want to turn some off." That's a preferences model, per type, per channel.
4. 04Week 5: "Some should be digested daily, not sent individually." Scheduling and aggregation.
5. 05Week 8: "Admins need to see what was sent." A log, and a UI for the log.
6. 06Week 12: "It should respect their timezone." Of course it should.

Every single addition was reasonable. That's what makes this failure mode dangerous — there's never a moment where someone asks for something unreasonable and you can push back.

The question that prevents it

Before writing anything: what is the smallest version of this that a real user would be glad to have?

Not the smallest version that technically works — the smallest version somebody would be genuinely pleased about. For notifications, that was: "when someone assigns me a task, I get an email." One event, one channel, no preferences. Two days of work.

Had we shipped that in week one, we'd have learned in week two that people wanted assignment emails and mostly ignored the rest. We'd have built the preferences system for two notification types instead of eleven. The digest feature — three weeks of work — turned out to be used by roughly nobody.

Writing the scope down as three lists

For anything bigger than a couple of days, I write this before starting. It takes fifteen minutes and it's the highest-ROI document in my process.

## Shipping in v1
- Email when a task is assigned to you
- Unsubscribe link in the footer (legal requirement)

## Explicitly NOT in v1
- In-app notification centre
- Per-type preferences
- Digests
- Any channel other than email

## Assumptions — flag if wrong
- Under 500 emails/day, so no queue needed yet
- Everyone has a verified email (checked: 97% do)

The middle list is the one that does the work. "Not in v1" is very different from "not doing." It converts an argument about the roadmap into a note in a document, and it lets you say yes to the idea and no to the timing in the same breath.

The assumptions list is the second-highest value. Half of scope explosions come from an unexamined assumption turning out false in week three — when it's most expensive to discover.

Vertical slices, not horizontal layers

The other scoping failure: splitting by layer. "Sprint 1: the database schema. Sprint 2: the API. Sprint 3: the UI." Nothing is demonstrable until sprint 3, and if sprint 1's model is wrong you find out two sprints late.

Slice vertically instead — one narrow path through every layer. Ugly UI, one hardcoded case, no edge cases handled, but end to end and real. You learn everything the layered approach would have taught you, and you learn it in three days instead of six weeks.

The signals that scope is expanding

• "While we're in there…" — the single most expensive phrase in software.
• A new noun in the conversation. Notifications became notification *preferences*, then notification *templates*. Every new noun is a data model, a UI, and a set of edge cases.
• "It should be configurable." Configurability is a multiplier on scope. Ship a sensible default, wait for someone to actually complain.
• Nobody can demo it yet and it's been two weeks. If there's nothing to show, the slices are horizontal.

What I'd tell my past self

The instinct to build it properly the first time is a good instinct pointed in the wrong direction. "Properly" requires knowing what people need, and until it's in front of them you're guessing — expensively, with the confidence that comes from having thought about it a lot.

You're not choosing between shipping something small and shipping something complete. You're choosing between shipping something small now and finding out in four months that complete was the wrong shape.