product definition
PRODUCT.md is the durable product-truth artifact: who uses this, what success means, and the principles that decide arguments later.
what it teaches
- name the users by their arrival state. not "developers" but people who already know AI-generated UIs have quality problems and want a practical solution, not education about the problem.
- define success as observable behavior. two measures: the user steers AI output with design precision instead of vague prose, and the output passes professional design review — not "looks like an AI made it."
- principles are constraints, not vibes. the five that govern the product:
- Practice what you preach — the product must pass its own anti-pattern detector; shipping anything it would flag is losing.
- Show, don't tell — the site is the demo; no words about design quality in place of executed quality.
- Expert confidence — direct and opinionated; hedging reads as inexperience.
- Editorial over marketing — a design publication's register, not a SaaS landing page's.
- Purposeful restraint — every element earns its place; nothing included because "landing pages usually have that."
- accessibility as baseline, not feature — WCAG 2.1 AA with verified contrast (not eyeballed), keyboard navigation, reduced motion, semantic HTML first, plain-language copy.
why
without a written product truth, every design session re-litigates identity from vibes: "modern and sleek," "approachable and warm," "more premium." no one has written down who the user is, so six months later the surfaces contradict each other — one page minimal and technical, another colorful, the homepage glossy, the app stark. the file settles arguments by existing: it is the reference both designers reach for, not vibes or seniority.
when to use
read PRODUCT.md before any design work; write it (via an init interview) before the first surface of a new product.
good and bad
bad
purpose: empower the future of work
the slogan cannot decide a product or design argument. every dispute gets settled by whoever argues loudest, each surface encodes a different assumed user, and the contradictions surface only when the whole product is seen together — at which point the fix is a redesign, not an edit.
good
user: operator who needs to observe and correct a workflow runsuccess: the operator can identify the blocking step and take the next action
names a user state and observable success that downstream surfaces can test. a named user with an observable outcome converts taste disputes into checkable questions — does this surface let the operator find the blocking step? — so decisions are reproducible across sessions and contributors, and the product accumulates one identity instead of a committee average.