Write the spec like a regular doc — free to start, no credit card.
the specgit blog
Your non-goals list needs a commit history
· the specgit team
Keep the spec next to the code
Write like a normal doc in GitHub. Saves are commits, comments are PR threads, publish is a merge — free to start.
Free to start, no credit card. Zero Content Retention — we never keep a copy.
A limitations slide is the most quotable thing a product manager makes. It is short, it sounds final, and sooner or later somebody reads it aloud in a customer meeting as a list of things worth wanting.
Then the answer changes. A constraint that held in March gets sold in July, and whoever wrote down the reason is not in that room. Nothing travels with the slide, so the change lands as news instead of a decision anyone can look up.
The limitation slide is the best sales asset you own
Every product has a list of things it deliberately does not do. A rate limit you will not raise, an integration parked until the data model settles. Each line cost an argument to settle, and the reasoning from that argument is the part people need six weeks later.
The list gets flattened onto a slide, because slides travel. A slide keeps the answer and loses the reasoning. Sales gets handed an inventory of objections already handled, and they read the room correctly, because a customer who hears a firm boundary wants the price of moving it. So the boundary sells. Somebody counts the closed deals, and by the next planning meeting your non-goals are commitments that nobody calls a reversal, since nothing recorded those lines as decisions.
The bill lands on whoever maintains the doc
When a non-goal flips, every spec that assumed it goes wrong quietly. The file still opens and still reads cleanly. A paragraph explaining why the bulk import is out of scope sits there looking like fact, and an engineer skimming it three weeks later designs around a limit sold away in a room she never entered. That is the ordinary way documents rot, a mechanism we took apart in why product specs go stale.
The expensive part arrives when someone asks why the import was ever out of scope. That reasoning sits in a Slack thread nobody can find, or in the head of an engineer who changed teams in April. So the PM re-derives a decision she already made once, on a Thursday, between scoping meetings for the feature the slide accidentally promised.
Meanwhile the people who most need the current answer are not asking a person. They are reading the repository, and so are the AI coding agents working in it. Both take the file at its word.
Keep the boundary where the changes land
A page in Notion or Confluence is a decent place to write the list. Google Docs too. Trouble starts after the boundary moves, because the product changes in the repository and a page outside the repository updates only when a person remembers to go edit it. Raw GitHub puts the file in the right place, then asks a PM to learn branches and pull requests to change one sentence. That trade-off is the subject of Notion vs GitHub for product specs.
specgit is a visual editor on the Markdown docs already in your GitHub repo. You type the way you would in any document. Saving writes a commit with your name on it, so the week a non-goal flips there is a diff of the exact sentence that changed. Comments become pull request review threads, so an engineer questioning a constraint gets an answer sitting next to the code that constraint governs. Publishing merges the file and honors the approvals your repo already requires, which means moving a documented boundary needs a named reviewer. Docs as code for product managers covers what that changes for you.
Where this document lives matters more than it does for almost anything else you write, because the list of things you do not do is what Sales quotes and what everything working in the repo reads. Put it where changes land, and moving it leaves a trace with a date and a reviewer on it. The real editor is open on the demo with no sign-up. GitHub stays the source of truth and specgit never keeps a copy of your documents or comments, spelled out on privacy and security. Pricing covers the rest of the team.