Everything about your product, in one place every team reads
Marketing, positioning, development and support all describe the same product. Give them one source to describe it from.
Who it’s for: Product managers, support leads and marketing teams who all explain the same product.
Four teams, four descriptions
Support explains a feature one way, marketing another, and the docs a third. An assistant that has read none of it fills the gaps with plausible inventions.
Write it once, in Markdown
Keep feature descriptions, tutorials, known limitations and naming in a product repository. Support drafts replies from it, marketing checks claims against it, and developers look up how a feature is meant to behave.
Read-only by design
The assistant can search, list and read files. Write tools don’t exist, so the repository only changes when someone commits to it, and every change has an author and a reason in the Git history.
How to structure the repository
- Write one file per feature: what it does, who it is for, how it behaves at the edges, and what it does not do. Limitations are the part assistants most often invent.
- Keep a naming file with the official name of every feature and the names to avoid, so drafts and replies stay consistent with the interface.
- Link tutorials to the feature files they cover, so the assistant can move from a how-to to the detail behind it.
Setting it up
-
Step 1: Collect the product knowledge you already have (docs, support macros, release notes) into Markdown in one repository.
-
Step 2: Assign it to the people who describe the product: support, marketing and engineering.
-
Step 3: Each team connects it to its own assistant. When a feature changes, one commit updates every answer.