Your team already has the idea-to-spec and prototype-to-decide playbooks — the worked recipes for turning a vague idea into a v1 spec and a spec into something clickable. Each is a good move, done once, on one idea. This module is the layer that turns those separate moves into a validation engine: specs sharp enough to estimate against, and prototypes that earn a real build-or-not call before a single engineer is pulled in.
It’s Module 2 of the certifiable Founders & PMs track, and it inherits everything you built in Module 1. Your product-context.md isn’t background reading here — it’s the contract this module’s specs are graded against: every out-of-scope line should trace to your real anti-focus, not a fresh guess at what v1 should skip. M1 mastered what you’re building and for whom; M2 builds the engine that turns a request into a decided, scoped feature on top of that foundation — and assesses the engine, not one lucky good call.
A spec is not just a list of features — it’s a bet about what’s worth building. “Save articles for later, v1: save, find, remove” is a sentence that costs three weeks of eng time if it’s wrong. The free playbooks teach you to spec one idea and prototype one flow well. This module is where that becomes the standard every request meets — because the requester can’t tell a well-scoped feature from a vague one, and it isn’t their job to.
The engine, not the one-off feature
Most founders use Claude as a faster spec-writer: paste an idea, get user stories, move to the next thing. That’s not a system — it’s a faster way to ship an under-scoped feature. The spec that worked for last month’s request gets copy-pasted for this month’s without re-checking the edge cases, the prototype “feels right” without anyone clicking it like a first-timer, and the first time a flow confuses a real user, nobody can point to what was actually tested.
A validate engine is two named moves that run the same way every time, on every real request:
- Spec — read the idea back before specing anything, write tight user stories for the core flow, surface the edge cases a happy-path spec misses, and draw an explicit out-of-scope line.
- Prototype — name the one decision the prototype has to settle, build a single openable page that demonstrates only that, click it like a confused first-timer, and write the five-line decision note that’s the actual deliverable.
Each move has one job and one output, which is what lets you name what’s broken when a feature ships wrong: a spec problem (an edge case nobody decided, a scope line that crept) or a prototype problem (the flow was never actually clicked, the decision note never got written). A system you can diagnose beats a pile of specs you can only hope were thorough.
You run both moves in the chat. Open your spec and your product-context.md in Claude Desktop, and work one move at a time — no terminal needed on the main path.
Idea-to-spec — the discipline the recipe can’t teach
The playbook gives you the steps: read the idea back, write stories, surface edge cases, draw the line. Mastery is the judgment inside those steps — the calls that separate a spec that survives a stakeholder pushing back from one that just looks thorough.
- The read-back is the cheapest bug-catch you’ll ever do. If Claude restates the idea and gets the user or the job wrong, that’s a one-prompt fix now and a rewrite later. Skipping straight to user stories means you might spec four stories for the wrong feature before anyone notices.
- Edge cases decided now are cheap; edge cases discovered mid-build are a meeting. “What happens if the same item is saved twice” is a one-line answer in a spec and a Slack thread full of opinions three weeks into the build. Push past the obvious happy-path stories — that’s where Claude earns its keep, and where most specs stop too early.
- The out-of-scope line is a product decision, not a suggestion to accept. Claude can propose what to cut from v1 with good reasoning; deciding what the first version genuinely won’t do, and defending that to your team, is yours. A spec with no out-of-scope section isn’t tight, it’s incomplete — and it’s the one that quietly grows into a two-month build.
- De-identify a real customer request before it’s a spec input. If the idea came from a customer email, the spec should be about the feature and its users in the abstract — not tied to one person’s inbox.
A spec that clears this bar reads as a one-page document a stranger could hand to engineering for an estimate: 4-6 tight user stories on the core flow, the edge cases decided (not just listed), an explicit out-of-scope section with a one-line reason per cut, and a short list of genuinely open questions.
Prototype-to-decide — built to answer one question, not to impress
A prototype that tries to show everything proves nothing, and a prototype nobody actually clicks like a confused user is a wasted afternoon dressed up as validation.
- Name the decision before any screen gets built. “Does save-then-find feel obvious to a first-time reader?” is a question that bounds the prototype to the fewest screens that answer it. A prototype built without a named decision tends to grow into something that demonstrates everything and decides nothing.
- One self-contained file is what makes it a throwaway, not a head start. A prototype that needs an install step or a build process stops being something you can hand to anyone in thirty seconds — and the easier it is to open, the more likely it actually gets clicked instead of just described in a meeting.
- Click it like the confused first-timer it’s for, not like the person who designed it. The friction you hit clicking around — “wait, where’s the Saved tab?” — is exactly the signal you came for. Skimming the prototype the way you’d skim your own work defeats the point.
- The decision note is the deliverable; the HTML file is not. Once you’ve written the five-line “does it work, what needs to change, is it worth eng time” note, the prototype has done its job. Handing the fake-data HTML to engineering as a head start ships exactly the shortcuts you took to move fast.
A prototype-and-decision pair that clears this bar names the one question it tested, ships as a single openable file with realistic fake data, and ends in a five-line decision note that’s honest when the answer is “not yet.”
A note on Arabic specs
Most of this module’s discipline is language-agnostic — an edge case is an edge case in any language. Two things genuinely change for a bilingual product. First, if the spec’s user-facing copy will ship in Arabic, draft the Arabic strings directly rather than translating the English spec’s placeholder text — a literal translation of “Save for later” rarely reads the way a native Arabic product string should. Second, if you’re prototyping for a Gulf customer to click, build the prototype in the language they’ll actually use the product in; a prototype in the wrong language tests the wrong reaction.
Your assignment
Build the validate engine for one real request — your own (recommended: the output is a feature your team genuinely scopes and decides) or the sample brand Mizan, the GCC bookkeeping SaaS whose co-founder, Dana Al-Qassimi, runs throughout this track. Everything here inherits the foundation files from M1; if you don’t have product-context.md yet, do Module 1 first. Open the chat in Claude Desktop with your context doc and the request — no terminal needed.
Module 2 deliverable — the validate engine
Inherits from M1: product-context.md
1. spec.md (the idea-to-spec output)
- the read-back: who it's for and the one job it does, confirmed
before any stories were written
- 4-6 user stories for the core flow only
- the edge cases, each with a decided behaviour (not left open)
- an explicit OUT OF SCOPE section, each cut with a one-line reason,
checked against product-context.md's real anti-focus
- 3 genuinely open questions
2. prototype.html + decision-note.md (the prototype-to-decide output)
- the ONE decision this prototype was built to answer
- a single self-contained, openable file with realistic fake data
- a 5-line decision note: does the flow work, what must change, is
it worth eng time — honest if the answer is "not yet"
PII: if the request came from a real customer, the customer's name,
email, and account details stay out of every file. Describe the ask,
replace specifics with [customer].The Foundation toolkit holds the product-context.md template this module’s specs are pressure-tested against.
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 two deliverables are scored against five criteria. Each is meets / nearly / not yet, and a “nearly” on any one is a revise, not a pass.
Validate engine rubric
1. The spec is grounded in the real read-back
The user and the job were confirmed before stories were written, and
the stories trace to that confirmed read-back, not a fresh guess.
2. Edge cases are decided, not just listed
Every named edge case has a stated resolution. "Use your judgment"
is not a decided edge case.
3. The out-of-scope line is real and checked
Every cut has a one-line reason, and at least one ties explicitly
back to product-context.md's anti-focus — not invented fresh.
4. The prototype answers ONE named question
The screens built are the minimum needed to test the stated
decision — not a tour of the whole feature.
5. The decision note is honest
A genuine "not yet" or "needs eng time we don't have right now" is
graded the same as a "build it" — the bar is honesty, not optimism.The discipline is deliberately what a skeptical engineering lead would demand: an edge case left undecided, or a prototype nobody actually clicked, fails quietly three weeks into a build — 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, built the week Mizan’s team was deciding how to respond to a billing incident.
spec.md — "Flag a charge" (excerpt)
Read-back, confirmed before stories: this is for a Mizan customer who
sees a charge on their account they don't recognize or think is wrong —
most urgently, anyone affected by the March 1 double-billing incident.
The simplest useful version: a button on any charge that flags it for
review, and a place support can see what's been flagged.
User stories (v1, core flow only):
As a customer, I can flag a charge on my invoice as disputed, so
support knows to look at it without me opening a ticket.
As a customer, I can see which charges I've already flagged, so I
don't flag the same one twice.
As a support agent, I can see all flagged charges in one place with
the customer and amount, so I can triage without searching tickets.
Edge cases, decided:
Flagging the same charge twice → no-op, button shows "Flagged"
state, doesn't create a duplicate flag.
Charge already refunded → flag is accepted but auto-resolved with a
note ("already refunded on [date]"), not left open.
Charge flagged after the invoice is finalized in Finance's books →
still accepted; flag carries an "already closed in finance" tag so
support knows to coordinate before reversing anything.
OUT OF SCOPE for v1 (checked against product-context.md):
No automatic refund — a person reviews every flag before money
moves. Why: product-context.md's billing-trust bet is "every charge
is correct AND provably so" — an automated refund removes the
provable, reviewed part.
No multi-currency dispute handling — product-context.md already
excludes multi-currency beyond AED/SAR/QAR this phase.
Open questions: does support need an SLA on flagged charges? Should a
flag pause the next renewal for that subscription? Who owns the
"already closed in finance" coordination?decision-note.md — "Flag a charge" prototype (excerpt)
Decision this prototype tested: does flagging a charge feel like an
obvious, low-friction action from the invoice view — not buried in a
settings page nobody finds during an actual billing dispute?
What I clicked: opened the fake invoice list, found the flag button on
the first try without being told where to look, flagged a charge, and
could immediately see it marked as flagged when I returned to the list.
What felt off: the flagged state used the same grey as a paid invoice
— too easy to miss at a glance. Updated the prototype to use a clearly
different visual treatment for "flagged."
5-line decision: flow works once the flagged state is visually
distinct; worth building, est. small-medium against the codebase-map.md
scope; biggest open risk is the finance-coordination edge case, not the
UI — recommend a quick sync with Finance before this goes to eng.What you’ve proven — and what’s next
Clear the rubric and you’ve proven something the free playbooks alone can’t certify: that you can turn a vague request into a spec a stranger could estimate from, and a prototype into a real, defensible build-or-not call. That’s the Validate Engine stage of “Certified Founders & PMs with Claude.”
From here the track turns a validated idea into a full product operation, each module assessed the same way:
- 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 this reusable: the spec structure and the prototype’s decision-note format are the permanent artifacts — save them as a note you reuse for every request, so next month’s idea starts from structure, not a blank page. And if you’re rolling this across a team, the operating guide is the decision-and-data-safety layer that goes underneath the whole system.