Your team already has the product-context, market-landscape, and read-the-codebase playbooks — the worked recipes for capturing your strategy, mapping the field, and reading your own repo in plain English, step by step. This module is the layer above the recipe. It’s where you master the three things every later spec, prototype, and decision inherits — what you’re building and for whom, where you genuinely win and lose, and where a feature would actually live in your own code — build them for real, and prove, against a rubric, that you can.
It’s Module 1 of the certifiable Founders & PMs track, and it’s the one we leave open. Read it, do the assignment, and you’ll know exactly what the depth is worth before you put a team through the rest.
Every spec you write, every prototype you build, every decision memo and board narrative you ship is a withdrawal from three accounts: what you’re actually building and for whom, where you actually win in the market, and what your own code actually does. Most founders never fund those accounts in writing, so every conversation with Claude re-explains the company from scratch, every roadmap call argues from a different memory of the competition, and every “how hard would this be” question becomes a meeting. The foundation is the hour where you fund all three once, and it’s the highest-leverage hour in the whole track.
Why the foundation is the highest-leverage hour you’ll spend
A vague company is a confident-sounding one. Ask Claude to weigh a feature without a context doc and it won’t refuse — it’ll guess at your user, your priorities, and your constraints, and answer fluently from the guess. The answer reads like advice. It’s actually fiction wearing a confident voice, and the failure is invisible because nothing about the output looks uncertain.
Two failure modes account for nearly every roadmap call that goes sideways. The first is the un-grounded spec — a feature gets pressure-tested against an imagined user instead of the real one, because nobody wrote down who the real one is. It sails through every review because the spec is internally consistent; it just isn’t consistent with your actual strategy. The second is the un-verified codebase claim — a founder asks Claude to scope a feature, gets a confident “this touches three files, small effort,” takes that number into an eng conversation, and discovers it was a plausible-sounding guess about code Claude had never actually opened. At small scale that’s an awkward correction. At the scale of a quarter’s roadmap, it’s a commitment made on fiction.
Three things fix both failure modes before a spec is ever written. A product-context doc means “our user,” “our bets,” and “what we’re not doing” point at something concrete, so a spec gets pressure-tested against your real strategy instead of a guess. A market-landscape brief means you know where you actually win and lose — including against “do nothing” and “a spreadsheet,” not just the rivals you already worry about — so a roadmap call answers the market that exists, not the one in your head. A codebase map means “where would this live” is answered from the real repo, opened and read, not inferred from the feature’s name. Build these three and every later module inherits them: the spec in M2 gets pressure-tested against your real anti-focus because M1 already named it; the decision memo in M3 weighs options against your real priorities because M1 already wrote them down; the board narrative in M5 doesn’t re-derive your market position from scratch because M1 already built it.
Skip this module and Claude just helps you move faster toward a guess. That’s worse, not better — a confident wrong spec ships faster than an honest “I don’t have enough context to answer that.” Fund the three accounts first and every decision downstream gets sharper and safer for free.
The product-context doc — what makes it load-bearing, not decorative
The playbook gives you the steps: drop in your deck, extract a draft, sharpen the focus. Mastery is the judgment inside those steps — the calls that separate a context doc Claude can actually reason from, from one that reads well and decides nothing.
- A confident guess is worse than an honest blank. If your deck never names a north-star metric, the right move is a context doc that says so plainly — not one where Claude infers a plausible-sounding metric to fill the gap. A doc that contains invented strategy grounds every later answer in fiction; a doc with an honest gap tells you exactly what to go figure out before you trust anything built on it.
- The anti-focus is the part that earns its keep. Most context docs are strong on “what we’re building” and weak on “who we’re explicitly not for” and “what we’re deliberately not doing.” That negative space is what stops a “should we build X?” conversation from defaulting to yes — it’s the line a spec gets checked against, not the positive description.
- One canonical doc, one named owner. A context doc that drifts because three people quietly edit it in different directions is worse than no doc — it gives every reader false confidence that they’re reading the current strategy. Name an owner, version it, and treat a change as a reviewed decision, not a typo fix.
A context doc that clears this bar reads as a one-page premise sheet: what you’re building and the problem it solves, the one user that matters (and who it’s explicitly not for yet), your north-star metric and where it stands, this phase’s bets and the anti-focus, and your hard constraints — short enough that you’d actually paste it at the top of a chat, not a strategy essay nobody opens twice.
The market-landscape read — the wedge you can actually defend
A landscape that only lists the rivals you already worry about isn’t a landscape, it’s a confirmation of your priors. Mastery is the discipline that makes the read honest enough to plan against.
- “Do nothing” and “a spreadsheet” are competitors. For most early products, the real alternative to switching to you isn’t a rival’s product — it’s the customer’s current workaround. A landscape that skips the non-consumption options is missing the competitor you actually lose to most often.
- “Strong” and “loud” are different things. A competitor with a polished landing page and a competitor with a real retention advantage are not the same threat. Push past the marketing-page version of each rival to where you genuinely lose, not just where they’re well-marketed — the honest read is the one worth planning against.
- The wedge has to survive a customer asking “why you, though?” Three candidate positions that are merely different from the competition aren’t the same as one that’s defensible — tied to a real strength of yours, hard for a rival to copy quickly, and something you can actually back up if a customer or a board pushes on it. Pick the one you can defend, even when it isn’t the cleverest on the list.
A landscape that clears this bar names the real and adjacent competitors (including non-consumption), an honest win/lose read per rival, the few market shifts that actually move your bets, your chosen wedge with its rationale, and a short watch-list — built to be refreshed in under an hour each quarter, not re-derived from zero.
The codebase map — verified, not assumed
The playbook gives you the steps: get the shape, trace a flow, ask the basic questions, scope a feature. Mastery is treating every answer as a claim to verify, not a fact to repeat.
- A map you can’t point to in the actual files isn’t a map. “This would touch the article list and the data layer” is only useful if it names real files Claude actually read —
SignupForm.tsx,db/users.ts— not a plausible-sounding guess shaped like an answer. If Claude hasn’t opened the folder, it’s pattern-matching from the feature’s name, and that’s indistinguishable from a real trace until someone takes it into an eng conversation and it’s wrong. - The scope you carry into eng is a starting estimate, not a number to defend. A grounded “likely touches X, probably needs Y” is exactly the right level of confidence to walk in with — it’s a question for an engineer, not a verdict. Treat it as anything firmer and the first correction from eng costs you credibility you didn’t need to spend.
- Confidentiality travels with the read. Your own repo can hold secrets, customer data, or proprietary logic — opening it for understanding is fine; pasting snippets anywhere public is not. The map stays inside your sanctioned environment the same way a cap table would.
A map that clears this bar names the real top-level shape of the repo, traces one real user flow naming actual files in order, answers two or three plain “I’d be embarrassed to ask this in a meeting” questions with grounded answers, and scopes one real feature against what it would actually touch — captured in notes you bring into the next eng conversation instead of narrating from memory.
The Arabic standard — what a bilingual context actually requires
For a founder operating in Arabic or pitching a Gulf board, this is not a translation pass run over the finished English doc. It’s a standard the foundation sets from the start, because the failure mode is specific: an Arabic strategy doc that reads like a foreign report because it was translated rather than authored.
- Build the Arabic doc from your Arabic materials, not from the English one. If you pitch and operate in Arabic, the context doc, the landscape, and later the board narrative should be reasoned from your actual Arabic sources — a strategy framed for an English-speaking investor reads differently than one written for a Gulf board, and the user, the bets, and the regulatory reality (PDPL, local payment rails) are best captured in the language you actually run the business in.
- Adapt the market read locally, don’t translate the global one. The relevant competitors, the “do nothing” baseline, and who the buyer trusts can all differ between a global landscape and a GCC one. A wedge that’s wide open globally may already be crowded locally, and the reverse.
- One source of truth, in your working language. If your leadership decides in Arabic, the context doc that grounds every later decision should be the Arabic one — not a document your team nods through in English and re-derives in Arabic for the board.
Your assignment
Build the three foundation documents for your own company (recommended: the output becomes the doc you paste into every product conversation from here on) or the sample brand Mizan, a GCC bookkeeping SaaS whose co-founder and Head of Product, Dana Al-Qassimi, runs throughout this track. Open a folder with your deck, notes, and repo in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.
Module 1 deliverable — the founder's foundation
1. product-context.md (under 1.5 pages)
- what you're building and the problem it solves
- the one user that matters, and who it's explicitly NOT for yet
- north-star metric and roughly where it stands today
- this phase's bets, and what you're explicitly NOT doing — with a
one-line reason for each cut
- hard constraints: team size, runway, platform, regulatory reality
2. market-landscape.md (one page)
- direct and adjacent competitors, INCLUDING "do nothing" and
"a spreadsheet"
- an honest win/lose read per competitor, sourced not flattered
- 3-4 market shifts that actually affect your bets
- your chosen wedge, with the rationale and what you'd have to back up
- a short watch-list of signals that would change the picture
3. codebase-map.md (one page, for your own repo)
- the top-level shape: which folders do what
- one real user flow traced end to end, naming actual files in order
- 2-3 plain "basic question" answers, grounded in the code
- where one real candidate feature would live, and the rough shape
of the work
Bilingual founders: note where this context doc's eventual specs and
board narrative will need an Arabic version, authored from Arabic
materials rather than translated from this English draft.The Foundation toolkit gives you a fill-in template for each of these and the prompts that build them, so you’re filling in structure, not staring at a blank file.
How it’s graded — the rubric
This is the part the free playbooks don’t have, and the part that makes the credential mean something. Your three files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.
Foundation rubric
1. The context doc is honest, not invented Gaps in the source material
are flagged, not filled with
a plausible guess. The
anti-focus names real cuts
with reasons, not a vague
"we'll see."
2. The landscape includes the boring "Do nothing" / "a spreadsheet"
competitors appear where relevant. The
win/lose read is honest, not
flattering.
3. The wedge is defensible Tied to a real strength, with
a stated "what we'd have to
back up" — not just different
for the sake of different.
4. The codebase map is verified Every claim names a real file
Claude actually read. The
feature scope reads as a
starting estimate, not a
number presented as final.
5. Bilingual standard is right Arabic materials (where they
(bilingual founders) exist) ground the Arabic
version directly — it isn't
a translation of the English
draft.The discipline is deliberately what a skeptical board member would demand: a context doc that’s vague, a landscape that flatters, or a codebase claim that was never verified each fail quietly on every decision built on top of it — so it has to be caught here.
The bar, shown — a worked model answer (Mizan)
You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample brand — your own doesn’t need to look like this, it needs to clear the same bar. These are Dana Al-Qassimi’s documents, Mizan’s co-founder and Head of Product, built the week she started scoping the team’s response to a billing incident.
product-context.md — Mizan (excerpt)
Summary: Mizan is bookkeeping software for GCC small businesses, built
to handle VAT and local payment rails out of the box so a 5-person
business doesn't need a part-time accountant just to stay compliant.
What we're building: Cloud bookkeeping — invoicing, reconciliation, VAT
reporting — for SMBs in the UAE and wider Gulf, in Arabic and English.
Who it's for: An SMB owner or office manager doing their own books,
0-30 staff, who currently uses a spreadsheet or an external bookkeeper.
NOT for: enterprise finance teams needing multi-entity consolidation —
that's a different product, not this phase.
North star: Active Customers. 9,460 as of May 2026, growing steadily
on word-of-mouth referral inside GCC small-business networks.
This phase's bets: (1) billing trust — every charge is correct, once,
and provably so; (2) GCC compliance depth — VAT export and local
formats done better than anyone; (3) Arabic-native product, not a
translated English one.
NOT doing this phase: multi-currency beyond AED/SAR/QAR (too few
customers ask; revisit at 50+ requests), a mobile app (web covers the
job-to-be-done), enterprise SSO (no enterprise motion yet).
Constraints: 14-person team, 18 months of runway at current burn,
web-only, UAE PDPL applies to all customer financial data.market-landscape.md — Mizan (excerpt)
Competitors:
Legacy desktop bookkeeping software — strong with accountants who
already know it, loud in the channel, genuinely weak on GCC VAT
specifics and on anything cloud-native. We win on compliance depth
and on being built for the owner, not the accountant.
Regional cloud bookkeeping rival (unnamed, GCC-only) — the closest
direct competitor; strong on price, weak on Arabic-native UX (built
English-first, Arabic is a translation layer). This is where our
wedge lives.
"A spreadsheet + an external accountant" — the real competitor for
the smallest segment. Not a product at all, but it's who we lose to
when onboarding feels harder than just hiring a bookkeeper for a day
a month.
Market shifts that matter: UAE VAT reporting requirements tightened in
2026 (raises the cost of "good enough" bookkeeping); GCC accelerators
are pushing portfolio companies toward compliance-by-default tooling.
Wedge: Arabic-native, GCC-compliance-first bookkeeping for owner-run
SMBs — not a translated international tool, not an accountant's tool
repackaged for an owner. To back this up we have to keep shipping VAT
and local-format depth faster than the regional rival, every quarter.
Watch: if the regional rival ships a real Arabic-native rebuild, the
wedge narrows fast — that's the single signal worth tracking quarterly.codebase-map.md — Mizan (excerpt)
Shape: app/ is the customer-facing web UI, api/ handles requests and
billing logic, db/ is the data layer, billing/ holds the Stripe
integration and the invoice/renewal pipeline — the module the team
rebuilt this quarter.
Flow traced — an annual plan renewal: 1. a scheduled job in
billing/renewals.ts fires for each annual subscription on its renewal
date; 2. it calls the Stripe webhook handler in billing/webhooks.ts to
charge the saved payment method; 3. on success, invoice.ts generates
the invoice record. If a renewal looks like it ran twice, start in
billing/renewals.ts — that's the job that fires the charge.
Basic questions answered: customer payment data is tokenized via
Stripe, never stored raw in our db. A cancelled account's invoices are
retained for compliance but flagged inactive, not deleted.
Candidate feature scoped: a customer-facing "flag this charge" button
would touch the invoice list component in app/ and need a new
flagged_charges table in db/, plus a route in api/ — small-to-medium,
doesn't touch the renewal job itself. I'm using this to scope the eng
conversation, not to write it myself.What you’ve proven — and what’s next
Clear the rubric and you’ve done something the free path can’t certify: you’ve built a real, professional-grade foundation and demonstrated the judgment behind it. That’s the Foundation stage of “Certified Founders & PMs with Claude.”
From here the track turns the foundation into a working product operation, each module assessed the same way:
- Module 2 — from idea to prototype: pressure-testing a request into a v1 spec, and building a clickable prototype to decide before anyone writes real code.
- Module 3 — signal to decision: synthesizing scattered feedback into a defensible roadmap signal, and turning options into a decision you can defend.
- Module 4 — the roadmap pipeline: running the weekly stakeholder system, and chaining the whole arc from request to roadmap-ready.
- Module 5 — planning & the board: running quarterly planning with a real cut list, then the capstone — Roadmap-in-a-Box, the full product system taken from foundation to certificate.
First, make what you built reusable. Grab the Foundation toolkit — the founders CLAUDE.md and the three templates that turn the documents you just wrote into files your whole team pastes from on day one. And if you’re rolling this across a team, the operating guide is the decision-and-data-safety layer that goes underneath all of it.