Feature description template
The short answer
A feature description is one short page that gives the evidence, says what becomes true and says how you will know it is done. It is lighter than a PRD: no personas, no timeline. Use it for work that is already decided. Annsa keeps the same three parts on every priority: the evidence, the why and Done When lines.
A feature description is one short page about one feature. It gives the evidence, says what becomes true, and says how you will know it is done.
TL;DR
- Three parts: the evidence, what becomes true, Done When.
- One page or less. If it is longer, it may be a PRD.
- Done When lines are checks, not hopes. Each one can be tried and passed or failed.
When to use it: work you have already chosen to do. When not: when the decision is still open, or several teams must agree. Use the PRD template for those.
A feature description to paste
Fill it in, keep it short, and put it where whoever builds it will see it: a ticket, a repo file or your spec tool.
# <Name: what becomes true>
## Evidence
<person or account>: "<their words>" (<where, when>)
## What becomes true
<1-2 sentences, present tense>
## Not this time
- <thing a reader might assume is included>
## Done When
- Given <state>, when <act>, then <something checkable>.
- Given <state>, when <act>, then <something checkable>.
## Notes
<file or area, decisions made, rules: AGENTS.md>
What goes in each part?
Name. What becomes true, in words a customer would use. "Export invoices as CSV" beats "Invoice export module".
Evidence. The people or accounts, and their words. One quote is plenty. It tells the builder who this is for and lets you check later whether you got it right.
What becomes true. One or two sentences, present tense. What can someone do, or see, that they could not before.
Not this time. One to three things a reader might assume are included. Optional, but it saves a surprise.
Done When. Two to five lines, each a check: "Given a state, when an act, then a result". If you cannot check it, rewrite it.
Notes. Anything the builder needs and would otherwise guess: a file, a rule, a decision already made.
An example, filled in
This is an example, made up to show the size. It is not a real Annsa feature.
Export invoices as CSV
Evidence. Two accounts this month. "I spend an hour at month end copying invoices into a spreadsheet for my accountant." (Priya, Loom & Thread, Intercom chat, 12 Oct). Fieldnote asked the same on a call, 15 Oct.
What becomes true. A customer can download all invoices for a date range as one CSV file from the billing page.
Not this time. PDF downloads. Scheduled exports.
Done When.
- Given a customer with invoices, when they pick a date range and choose Export, then they download a CSV with one row per invoice.
- Given a range with no invoices, when they choose Export, then they see "No invoices in this range" and nothing downloads.
- Given a member without billing access, when they open the billing page, then there is no Export button.
Notes. Columns: invoice number, date, amount, currency, status. Billing page code is in the billing settings area. Rules are in AGENTS.md.
That is the whole page. A person can read it in a minute, and an agent can build it and check each line.
When is this too light?
Use a PRD when:
- You do not yet know what to build, only that something hurts.
- Two or more people or agents must agree on scope.
- The work will take more than a few days.
- Getting it wrong is costly to undo, such as billing, data or permissions.
For a bug, you can go lighter still: a sentence of what is wrong, one Done When line.
Do I need a template at all?
No. The three parts are the point, not the headings. If you already write "the evidence, what changes, how we'll know" in your tickets, you have this. The template helps when different people (or agents) each write them differently and you cannot find the evidence later.
How does Annsa help?
Annsa is the source of direction for your agents. Each priority has a spec with the same parts.
- Evidence comes in from Slack, Intercom, call transcripts, surveys, imports, GitHub, the API or by hand. Each request keeps the customer behind it, their exact words, the account and its revenue.
- The spec holds the why, the evidence and Done When lines. You write it, your agent writes it over MCP, or Ask writes it.
- Done When is checked by the agent that builds it. Claude Code, Cursor, Codex and Grok record evidence against each line.
- Telling them. When it ships, Share Back drafts a note to each person who asked. You send it.
See the spec and writing a spec.
Sources: Product requirements document, Wikipedia, for how a PRD differs. PRD template, HashiCorp, as a heavier alternative for open decisions.