How to get more out of your Brain in Thinkr

Setting up your Brain is the easy part — the three-tab walkthrough takes five minutes. Getting power out of it is a different skill. The Brain is the context every other feature reads from, so it follows the oldest rule in computing: garbage in, garbage out. Feed it sharp, specific context and Thinkr writes like someone who knows your product. Feed it a dumping ground and you get confident, generic mush.

This guide goes field by field and shows the good way to fill each one. One principle runs through all of it: signal, not volume. Thinkr keeps the context it injects into each generation to a budget so drafts stay fast, so every item you add should earn its place. The goal isn't a complete Brain — it's a high-signal one.

Products — start here, and make them specific

What it's for. Products are the foundation. Every PRD ties to one, and the Coach reads them to skip discovery questions it can already answer — so a draft starts from what your team is instead of from zero. A vague product means the Coach has to ask the basics every time; a sharp one means it gets straight to the real questions.

How to write one well. Each product has a Name, a one-line Description, and a Product type. The name does nothing on its own — the description is where the work is. Say what it does and who it's for, not what it's called.

• ❌ Name: "Dashboard" — Description: "Our dashboard." — Thinkr learns nothing it couldn't guess.
• ✅ Name: "Analytics Dashboard" — Description: "Self-serve reporting for B2B ops managers to track usage and spot churn risk." — Type: B2C SaaS — now the Coach knows the user, the job, and the stakes.

Add one row per product or domain area you actually write specs for. If you write for three surfaces, three products beats one generic catch-all — Thinkr can tailor each draft to the right audience.

While you're on this tab, fill in Tech Stack & Integrations too. It's optional, but listing what you actually run — Postgres, Next.js, Stripe, ClickUp — stops Thinkr from proposing tools you don't use and grounds technical sections in your real architecture.

Standards — encode how your team writes

The Standards tab is where your team's taste lives. Four fields, each doing a different job.

PRD template style. Pick Standard (full), Lean (trimmed), or Custom. This sets the skeleton of every generated PRD — which sections appear, in what order. If your team has a house structure, build a custom template (give it a name, a description, and the section instructions) and set it as the default. PMs can still switch per-PRD on the Context step, so one default plus a couple of specialized templates (e.g. Fintech Launch PRD, Internal Tool Spec) covers most teams.

Custom Instructions — your highest-leverage field. Most people skip this. That's a mistake: it's the single highest-leverage field in the Brain because it applies to every interaction — coaching, generation, and critique. One good rule changes a hundred future drafts. The difference between a weak instruction and a strong one is specificity:

• ❌ "Write good PRDs." — Thinkr already tries to. This does nothing.
• ❌ "Be concise." — Concise by whose measure?
• ✅ "Every PRD must include a 'What if we don't build this?' section."
• ✅ "Express success metrics as baseline → target with a date. Reject vague goals like 'increase engagement.'"
• ✅ "Use UK English. Refer to customers as 'members', never 'users'."

The test: could a new hire follow the instruction without a follow-up question? If yes, Thinkr can too. Write them in the imperative, as standing rules, and let them accumulate.

Custom Instructions and the PRD template do different jobs — don't confuse them. The template controls structure (which sections). Custom Instructions are behavioral rules that apply everywhere. The first is the skeleton; the second is the judgment.

Glossary. Small field, compounding payoff. Define your terms and acronyms — ARR = Annual Recurring Revenue, "activation" = first PRD published — so Thinkr uses your language consistently instead of inventing its own. A dozen entries is plenty; this is for the words an outsider would get wrong.

Design System — so prototypes look like you

What it's for. The Default Design System is a Markdown (.md) file you upload on the Standards tab. It becomes the default style for every generated prototype — so mockups come out in your house style instead of generic AI defaults.

How to write one well. It's a document Thinkr reads, not a config file, so write it for a smart designer who's never seen your product. Be concrete: name the actual values, don't gesture at them. A good skeleton:

# Design System

## Brand voice
Calm, precise, never hypey. Sentence case everywhere. No exclamation marks.

## Colour
- Paper / background: #FAF9F6
- Ink / text: #1A1A1A
- Accent: #2D6BFF (primary actions only)
- Use accent sparingly — one primary action per screen.

## Typography
- Headings: Geist, semibold
- Body: Geist, regular, 16px base, 1.6 line-height

## Components
- Buttons: 8px radius, solid accent for primary, ghost for secondary
- Cards: 1px border #E5E5E5, no drop shadows
- Inputs: underline style, not boxed

## Don'ts
- No gradients, no glassmorphism, no neon.

The more specific the values, the closer the prototype lands. "Use our brand colours" tells Thinkr nothing; a hex list and a "don'ts" section tells it everything. Update the file when your real design system moves.

Knowledge Base — keep it lean and current

What it's for. Reference material Thinkr pulls from during coaching and generation — the source-of-truth docs your specs should build on. It accepts PDF, TXT, Markdown, and CSV, up to 25 files / 10 MB each / 25 MB total. Those caps are generous, which is the trap: there's room to hoard, and hoarding hurts you, because Thinkr fills its injection budget with your most recent files first. A library stuffed with stale one-pagers can crowd out the doc that actually mattered.

What earns a spot:

• Source-of-truth docs — your metrics framework, a tech-architecture overview, the doc that explains how your team really decides.
• Things Thinkr can't infer — internal constraints, regulatory rules, why a past bet failed.
• Recent and live — currency beats completeness, because the newest files win the budget.

What doesn't:

• Superseded PRDs — just publish the new one; published specs become context automatically.
• Giant exports where the useful part is two paragraphs. Thinkr extracts text up to a cap, so a 200-page PDF gets truncated anyway — trim it to the part that matters before uploading.
• Anything you wouldn't want quietly steering a draft.

The precision move: when a specific document must be used for a PRD, don't rely on the automatic budget — open the Context step and tick that document by hand. A hand-picked selection always beats the recency budget. Use the library for ambient context; use per-PRD selection for the one doc you can't afford to have trimmed.

Memory — curate the rules it learns

Memory is the part of the Brain that fills itself. As you coach and critique, Thinkr learns patterns and writes them back as one of four types — Preference, Pattern, Domain Fact, Rejection — capped at 50 entries of 500 characters each. Small on purpose: it's a curated rule set, not a transcript. Two habits make it pay off:

1. Prune what's wrong. If Thinkr learned something off, toggle it off (no need to delete) so it stops steering output. An unwatched memory list drifts from how your team actually works.
2. Seed what it hasn't learned. Click Add memory for rules that haven't come up yet: "Team uses RICE for prioritization." / "We don't ship dark patterns — flag growth tactics that rely on confusion." That last one is a Rejection, the most underused type — it stops Thinkr from re-suggesting things you've already ruled out.

Where the work pays off

Each thing you sharpen shows up somewhere specific:

• Sharp products and glossary → the Coach asks fewer basic questions and speaks your language.
• Strong Custom Instructions and templates → generated PRDs and critiques judge against your bar, not a generic one.
• A concrete design system → prototypes come out in your house style.
• A lean, current Knowledge Base → drafts build on what's true instead of guessing.
• A curated memory → Thinkr stops repeating mistakes you've already corrected.

A Notebook can also push research straight in with Send to Brain, and every PRD you publish becomes context for the next — so the loop compounds on its own. A monthly five-minute pass to prune stale docs and tighten one instruction keeps the signal high.

The short version

Volume dilutes; signal compounds. Make products specific. Write Custom Instructions a new hire could follow. Give the design system real values, not gestures. Keep the Knowledge Base lean and hand-pick the doc that matters per-PRD. Prune memory like a garden. Do that, and Thinkr stops sounding like a tool and starts sounding like it works on your team.

Ready to sharpen yours? Open Thinkr and click Brain.