# Product brief template

Use actual product evidence for every claim. Omit unverified capabilities rather than filling them with plausible numbers.

| Field | What to write |
| --- | --- |
| Intended reader | Person or team with the supported job |
| Customer task | Concrete input, useful output and completion condition |
| Product promise | One sentence supported by actual behavior |
| Demonstration | Public sample, expected result and a clear way to try |
| Inputs and limits | Supported formats, languages and limits from verified specs |
| Integrations | Working integrations with documentation; distinguish planned work |
| Data handling | Current published terms and actual relevant controls |
| Pricing | Current plan, usage charges and material exclusions |
| Evidence | Source, test method/date and limits for any numerical claim |
| Next action | Appropriate trial, docs, purchase or pilot route |

## Fictional example: DocuPulse

Reader: developer connecting an invoice workflow or a finance team evaluating extraction.
Task: process the supplied sample invoice, review the listed fields and export the expected record.
Proof asset to prepare: sample input, expected fields and an accessible demonstration.
Candidate activation: completed export matching the expected fields.
Qualified enquiry: relevant recurring workflow, intended integration and a concrete evaluation question.

No accuracy percentage, working integration, retention policy or commercial price is established for this fictional product. Populate a real product brief from evidence.