Structure
Create your company
Department

product

what gets built and why — the decisions before the code

Holds the decisions before the code: the principles calls are made against and what a spec has to answer before anyone builds from it. Take it when the same argument about what to build keeps coming back.

structure generate department product

Product — Mission

what gets built and why — the decisions before the code.

Purpose. One paragraph, written as what this department is accountable for rather than what it does all day. Product's is the hardest to write honestly: "we decide what gets built and what gets refused, and we write down why" is closer than anything about roadmaps. Name the person the decisions serve.

How work gets done here. Steering docs live at this root — the principles decisions are made against, and the bar a spec has to clear. Repeatable how-tos in processes/; accumulating collections in records/.

Also in the folder

Product Principlesdepartments/product/principles.md

Product Principles

The calls we make the same way every time, so they are argued once instead of weekly. Three to five. Each one has to be capable of losing — a principle that never costs you a feature you wanted is a slogan.

The principles. Numbered, one line each, followed by a sentence naming what it rules out. "Fewer, deeper" is a slogan until it reads "fewer, deeper — we ship one surface finished before starting a second, which is why the integrations page has been waiting since spring."

What we say no to. The requests that come back every quarter and get the same answer. Write the answer down; it is the most reused paragraph in the company.

How a decision gets made. Who decides, what they need in front of them, and how long a call takes. If a decision has been open for a month, say what that means here.

How we know we chose wrong. The signal that reopens a settled decision. Without it, a principle becomes something the company has to defend rather than something it uses.

Spec Standarddepartments/product/spec-standard.md

Spec Standard

What a spec has to answer before anyone builds from it. Short, because the point is that the questions get answered — not that the document gets long.

The questions every spec answers. A numbered list a writer can check themselves against. Start here and cut what you don't mean: who it is for, what they do today instead, what changes for them, what it deliberately does not do, how we will know it worked.

How long, and in what form. Say the ceiling out loud — a page, two — and what belongs in a diagram, a table, or a link instead of prose.

What is not a spec. A ticket, a screenshot, a conversation someone remembers. Name the shapes that keep arriving in place of one.

Who reviews it, and what they are checking for. Not spelling. The review question is whether a builder could start on Monday and disagree with nobody about what "done" means.