Scoping with Explicit Non-Goals

Foundations

So far, each requirement added something to the design. Now, what if the product has many plausible features, and the hard part is deciding which ones the first version will not have?

Scope by subtraction. Keep the smallest set of verbs that delivers the core value, then attach the few rules that make that core hard, such as a freshness limit or an extreme user. Every other feature becomes a non-goal with a one-line reason tied to the work it would add. A reason turns a refusal into a decision a reviewer can challenge.

Take a product with seven candidate features. Three verbs deliver the core: publish, subscribe, and read the latest items. Two rules make them hard: items appear within seconds, and one publisher may have millions of subscribers. The other four, such as ranking and search, are out, each with its reason: ranking needs a model, search needs an index.

• Requirements

  Estimates and APIs start from an agreed list of what the system must do.

  Open lesson

Case Scenario

To see how non-goals keep a design small, consider a news feed like X's home timeline: users post short text, and followers see posts from accounts they follow, newest first. Posting, following, and reading home are the core; freshness within seconds and a 20-million-follower account are the hard rules; ranking, ads, stories, and search wait.

A text feed can quietly expand into ranking, ads, stories, recommendations, media, and moderation before its core behavior is settled. Those additions hide the two cases that actually stress the first version: a reader following 500 accounts and an author with millions of followers. Home must remain reverse-chronological, fresh within seconds, and under 200 ms for the 500-account reader.