Product Context

Tell Frankee what you are building

Product Context is the background Frankee draws on every time it writes a story for your team. It is the difference between a generic story about a login form and one written for your product, your users, and your stack. Filling it in takes about ten minutes and it is the highest-leverage setup step in the product.

What it is for

Frankee has no idea what you build until you tell it. Without Product Context it can still produce a well-formed user story, but it has to guess at the domain, the vocabulary, and who the story is for. The result reads like a textbook example rather than something from your backlog.

Product Context is set per team, on the Product Context tab of Settings › Team Setup. Two teams in the same organization can describe two different products, and neither sees the other's context.

The fields

Nothing here is required, and partial context is better than none. These are the fields, roughly in order of how much they change what you get back.

• Product name. What the product is called. Short, and the name your team actually uses.
• Product description. What the product does and who it helps. The single most useful field. A couple of sentences is plenty.
• User personas. Who your stories are written for. Frankee writes from these perspectives instead of inventing generic ones, so this is what stops every story starting "As a user". Give each persona a name and a line about what they are trying to do.
• Domain. The industry you operate in, such as fintech, healthcare, or ecommerce. Shapes vocabulary and the kind of edge cases Frankee thinks to raise.
• Tech stack. A comma-separated list. Keeps acceptance criteria grounded in what you can actually build.
• Product vision. Where the product is heading. Helps Frankee judge whether a request fits the direction you have set.
• Additional context. A free-text notes field saved alongside the rest. Frankee's context review reads it when it assesses how complete your Product Context is. If something needs to shape the stories themselves, put it in one of the fields above or in an uploaded document rather than here.

After you save

Saving is a plain save: nothing is generated and nothing is sent anywhere. Once it succeeds, Frankee follows up with a short review of how complete your context looks and what would most improve it. That feedback is advice only. It is not stored, and ignoring it costs you nothing.

Uploading documents

Structured fields cannot hold a PRD. On the same tab you can upload documents such as a product strategy, a PRD, a vision deck, or your OKRs, and Frankee will draw on the relevant parts when it generates stories.

• Formats: PDF and DOCX only.
• Size limit: 10 MB per file.
• How many: there is no fixed limit on the number of documents per team.

What happens after you upload

1. The upload is accepted immediately

   Processing happens in the background, so you are not left waiting on a spinner. The document appears in the list straight away marked Processing.

2. Frankee extracts the text

   It reads the text out of the file, splits it into overlapping passages, and indexes each one so it can be searched by meaning rather than by keyword.

3. The document becomes ready

   The status changes on its own once indexing finishes. Only documents that have reached ready are used during generation, so a document still processing is simply skipped rather than half-used.

Deleting a document

Deleting removes the document and everything indexed from it, so it stops influencing new stories straight away. Stories already generated are unaffected: they were written when the document was still there, and Frankee does not revise past work.

How Product Context is used during generation

When you generate stories, Frankee assembles a picture of your team before it writes anything. Product Context reaches the prompt two different ways, and knowing which is which explains a lot about what you get back.

The fields are always included

Your product name, description, domain, tech stack, vision, and personas are sent every time, alongside your team's name, framework, sprint length, and members. These are short, so they cost little and always apply.

Documents are retrieved selectively

Documents are far too large to send whole, so Frankee retrieves from them instead. It compares what you typed on the Generate page against every indexed passage and pulls only the closest matches, up to a handful of passages per generation.

This has three consequences worth knowing:

• Your request wording decides what gets retrieved. A vague request matches vague passages. Naming the feature, the area of the product, or the persona involved pulls in far more relevant background.
• A passage that is not close enough is not used at all. Frankee would rather send nothing than send something loosely related, because loosely related context is what produces confidently wrong stories.
• Uploading more is not automatically better. A focused, current PRD beats five overlapping strategy decks, because only the closest passages are ever used and near-duplicates crowd each other out.

The generation response tells you how many of your documents contributed, so you can see whether your uploads are actually being drawn on.

Getting more out of it

• Write personas as jobs, not job titles. "Scrum Master: runs ceremonies and watches team health" is far more useful than "Scrum Master".
• Say what the product is not. A description that rules things out prevents whole categories of off-target story.
• Upload the document you would hand a new joiner. That is almost always the one worth indexing first.
• Re-read it after a pivot. Stale context is worse than thin context, because Frankee has no way to know it is out of date.