A Definition Has Three Parts

Target user, core value, and scope boundary—miss any one and every later decision wobbles.

For whom, solving what, and where it stops. Settle these three sentences early—if you can't, every decision that follows will wobble, and wobbling gets more expensive as you go.

What you'll run into:

• The debate over whether to build a feature is evenly split, and you end up deciding by gut feel
• Six months in, nobody can say who the product is actually for
• Every release adds features, but no release ever makes anyone feel "now it's actually good"

What qualifies each part

Each of the three parts has its own bar. Check against these:

The second row is the easiest to paper over. "Boost efficiency" sounds fine precisely because it's true of every product—and a claim that's true of every product says nothing at all.

The cheapest way to test a definition is to push it one step forward: derive the core entities, the primary tasks, and the things you don't need to consider at all. If you can't derive entities and tasks, the three blocks are still stuck at the adjective level. And the corner marked "explicitly not in scope" is exactly what makes every later decision faster—it shuts down whole categories of debate instead of rehashing them each time.

Write the target-user part with the most critical eye. Early products are wasted less by too many features than by building for an imagined "everyone." Prefer "freelance designers who take on client work" over "an efficiency tool for all small businesses"—the former is specific enough to produce entities and tasks, the latter isn't. chasm-wiki

How to check it

Once written, run the three questions. If you can't answer any one of them, go back and revise.

• Can you name one concrete person? If not, the target-user block is still empty.
• What do they use today, and why should they switch? "Ours is better" isn't an answer; say specifically which step is painful.
• What are you explicitly not building? If you can't name one thing, the boundary isn't set.

Compare two definitions. The failing one: "an efficiency tool for teams," smoother collaboration, task/docs/schedule/chat all supported—usable by everyone, so nobody would switch their current tools for it. The passing one: "for freelance designers who take on client work," archive the requests and revision notes scattered across WeChat, organized by project, so billing is clear in one pass; no team collaboration, no online drawing. That one derives straight into an information architecture: core entities are projects and revision records, primary tasks are archiving and billing, and everything about teams and drawing is out of scope.

Note for the AI

Put the three parts in the project's first document, and attach it every time you ask the AI to build a feature:

This project's definition follows, and all design and implementation
must defer to it:

Target user: [a concrete person: job, device, skill level, daily work]
Core value: [how they cope today → what we turn that step into]
Scope boundary:
  In: [list]
  Explicitly out: [list]

Please do two things first, without writing code:
1. Based on this definition, list what you consider the core
   entities and primary tasks, and state which sentence of the
   definition they derive from.
2. Point out where the definition is vague or self-contradictory.
   Ask me one item at a time; don't fill in gaps yourself.

From now on, whenever I request a feature that conflicts with
"explicitly out", call it out instead of silently implementing it.

That last line is the most valuable sentence in the prompt. It turns the AI from an executor into a gatekeeper of the boundary, and it blocks a lot of whim-driven features.