How is this different from my pitch deck or business plan?

A pitch deck persuades investors; a product-context.md instructs Claude. It's stripped of the narrative arc and the hockey-stick chart and written as flat, factual premises — who the one user is, the exact bets this phase, what you're explicitly not doing — so an AI (or a new hire) can reason from it directly. You build it from the deck, but it's a working tool, not a sales document.

Will the doc make Claude's product decisions correct?

No — it makes them consistent. The doc ensures Claude argues from your actual user, bets, and constraints instead of generic assumptions, which removes a whole class of off-base answers. But if one of your bets is wrong, every answer grounded in it inherits that error. You still own the decision; the doc just guarantees you're debating the right premises.

Is it safe to put my strategy in a doc I paste into Claude?

Keep strategy and direction in the doc; keep the confidential layer out. Cap table, unreleased numbers, legal exposure, and customer PII belong in a separate private artifact, never in a doc you paste into casual chats. The general product-context.md should be safe enough to share with a new employee on day one — write it to that bar.

How often should I update it?

When your strategy genuinely shifts — a pivot, a new core bet, a constraint that changed — not on a calendar. A context doc earns its value by being a stable reference every playbook can trust; editing it weekly turns it back into noise. One owner, versioned, refreshed on real change.

Build a product-context doc Claude can actually use

when to reach for this

When you ask Claude to spec a feature, weigh a decision, or sketch a roadmap, the words "our product," "our users," and "our strategy" mean nothing to it — they're not written down anywhere it can read. So it guesses, and you spend the conversation correcting a generic answer. The fix isn't to re-explain your company every time; it's to extract a concrete product-context.md once — what you're building and the problem it solves, the one user that matters, your north-star metric, this phase's bets, what you're explicitly not doing, and your hard constraints — and paste it into every product task from here on. Build it once and every other Founders playbook (idea-to-spec, decision-memo, feature-to-roadmap) inherits it. It's all a conversation in the Claude Desktop app — drag your files in, ask in plain language, no terminal.

gather this first

Whatever already describes the company: a pitch deck, an old strategy memo, a one-pager, a recent investor update. Drag the files into the file pane in Claude Desktop — don't retype them.
Your own unfiltered brain-dump: a paragraph or two on what you're building, for whom, and why now. Messy is fine — Claude will give it shape.
Your north-star metric and roughly where it stands today, if you track one ("weekly active teams, ~120 now"). If you don't have one yet, that's a finding, not a blocker.
The hard constraints you operate under: team size, runway, platform (web/iOS/Android), and any regulatory reality ("we handle UAE payment data, so PDPL applies").

the workflow

Extract the context from what you already have

Don't write this from a blank page. Open Claude Desktop, drag in your deck and any strategy notes, and let Claude infer the shape from artifacts you've already made — it's far easier to react to a draft than to compose one. When it asks to read the files you dropped in, approve the read in the "Ask permissions" prompt.

you ask

Here's our pitch deck and an old strategy memo. Reverse-engineer a product-context profile from them: what we're building and the specific problem it solves, who the product is really for (the one user that matters most), our north-star metric if you can find it, the strategy and bets for the current phase, and the hard constraints (team size, runway, platform, anything regulatory). Where the source is vague or silent, say so and ask me — don't invent it.

what you get back A first-draft profile that pulls real specifics out of your own materials, plus a short list of gaps — "your deck never names a single north-star metric" or "the ICP is described three different ways; which is it?" Those gaps are the most useful part.

If Claude fills a silence with a confident guess, push back. A context doc that contains made-up strategy is worse than no doc — it grounds every later answer in fiction.
Sharpen the focus — and the anti-focus

The draft will be fuzziest exactly where it matters most: who it's not for, and what you're deliberately not doing this phase. That negative space is where the doc earns its keep — it's what stops Claude (and your team) from treating every shiny idea as on-strategy.

you ask

Two things are still too soft. First, the user: who is the ONE user we're building for right now, and just as important, who are we explicitly NOT for yet? Second, focus: what are our 2–3 bets this phase, and what are we deliberately NOT doing — features, segments, and channels we're choosing to ignore for now, each with a one-line reason. Be concrete enough that a 'should we build X?' question has an obvious answer.

what you get back A tightened ICP with an explicit "not yet for" line, and a short bets-vs-not-doing list — "betting on self-serve onboarding for SMB teams; NOT building enterprise SSO, NOT chasing individual users, NOT on mobile this quarter." The cuts are decisions, so make them yours.

Naming what you're not doing is a founder call, not Claude's. It can propose the cuts; defending them to your team and board is on you.
Assemble one clean, paste-ready doc

Pull it into a single artifact with named sections, short enough to actually get reused. If it sprawls past a page and a half, it stops being something you paste at the top of a chat — and a context doc nobody pastes is just a memo.

you ask

Assemble everything into a clean product-context.md with these sections: a one-paragraph summary, What we're building & the problem, Who it's for (incl. who it's NOT for), North-star metric & how we measure progress, Strategy & bets this phase, Explicitly NOT doing, and Hard constraints. Keep the whole thing under ~1.5 pages — tight and skimmable, not a strategy essay.

what you get back A single, well-sectioned product-context.md you can read top to bottom in two minutes. When Claude writes it, you'll get an accept/reject diff in Desktop — read it before you accept, then save the file.

Save this file. It becomes the first thing you paste — or the file you drag in — at the start of every other Founders playbook from here on.
Battle-test it on a real product call

Prove the doc is grounded enough to reason from by making Claude use ONLY it to weigh an actual decision. If a sharp recommendation falls out of the doc alone, it's load-bearing. If Claude has to ask for context the doc should already hold, you've found the next thing to add.

you ask

Using ONLY this product-context.md and nothing else you know about us, answer: should we build [a real decision you're facing — e.g. a Slack integration]? Walk through it against our user, our bets, our 'not doing' list, and our constraints, and give me a clear recommendation. If the doc doesn't contain what you'd need to decide, tell me exactly what's missing instead of guessing.

what you get back Either a crisp, doc-grounded recommendation ("no, not this phase — it serves a segment your 'not for yet' line excludes") or a precise list of gaps. Both are wins: one proves the doc works, the other tells you what to add before you trust it.

make it your own

Pre-deck / pre-revenue: no pitch deck yet? Skip step 1's file drop and start from the brain-dump — paste your raw paragraphs and have Claude interview you, asking one sharp question at a time until the profile is complete. The interview is the extraction.
Arabic-first or bilingual company: if you operate and pitch in Arabic, build the doc in Arabic from your Arabic materials — adapt, don't translate. A strategy framed for an English-speaking investor reads differently than one for a Gulf board or a regional accelerator; the user, the bets, and the regulatory reality (PDPL, local payment rails) are best captured in the language you actually run the business in. One source of truth, in your working language.
Two-doc split for sensitive work: keep a general product-context.md that's safe to paste anywhere, and a separate private doc for the rest. The general one grounds every chat; the sensitive one never goes into a casual prompt (see pitfalls).
Make it load automatically (Power Track): advanced teams can drop product-context.md into the project so it's always in context, or in the terminal save it as project memory in a CLAUDE.md file — then you never paste it, it's just there. On Desktop, keeping the file in your project folder and dragging it in is the no-code equivalent.

watch out for

A context doc makes decisions consistent, not correct. It ensures every answer reasons from the same picture of your business — but the picture can be wrong, and a confident answer built on a flawed bet is still a flawed answer. You own the call; the doc just makes sure Claude is arguing from your premises, not generic ones.
Keep the sensitive stuff out of a general doc. Cap table, unreleased financials, legal exposure, and especially customer PII do not belong in a doc you paste into casual chats. Capture strategy and direction; leave the confidential layer in a separate private artifact, and never paste real customer names, emails, or account data into a prompt.
One canonical doc, one owner. A context doc that three co-founders quietly edit drifts into three strategies. Keep a single source of truth, name an owner, version it, and treat changes as a reviewed decision — not a free-for-all.
Refresh on real shifts, not on schedule. Update it when the strategy genuinely changes — a pivot, a new core bet, a constraint that lifted. Re-litigating it weekly turns a stable reference into noise and quietly un-grounds every playbook that depends on it.

you'll end up with A one-page `product-context.md` that captures your product, user, north-star, bets, anti-focus, and constraints — so every other Founders playbook reasons from your real strategy instead of a generic guess, and "our product" finally points at something concrete.

Questions people ask

How is this different from my pitch deck or business plan?: A pitch deck persuades investors; a `product-context.md` instructs Claude. It's stripped of the narrative arc and the hockey-stick chart and written as flat, factual premises — who the one user is, the exact bets this phase, what you're explicitly not doing — so an AI (or a new hire) can reason from it directly. You build it *from* the deck, but it's a working tool, not a sales document.
Will the doc make Claude's product decisions correct?: No — it makes them consistent. The doc ensures Claude argues from your actual user, bets, and constraints instead of generic assumptions, which removes a whole class of off-base answers. But if one of your bets is wrong, every answer grounded in it inherits that error. You still own the decision; the doc just guarantees you're debating the right premises.
Is it safe to put my strategy in a doc I paste into Claude?: Keep strategy and direction in the doc; keep the confidential layer out. Cap table, unreleased numbers, legal exposure, and customer PII belong in a separate private artifact, never in a doc you paste into casual chats. The general `product-context.md` should be safe enough to share with a new employee on day one — write it to that bar.
How often should I update it?: When your strategy genuinely shifts — a pivot, a new core bet, a constraint that changed — not on a calendar. A context doc earns its value by being a stable reference every playbook can trust; editing it weekly turns it back into noise. One owner, versioned, refreshed on real change.