Your team already has the feedback-synthesis and decision-memo playbooks — the worked recipes for turning a feedback pile into themes and a set of options into a recommendation, step by step. Each is a good move, done once. This module is the layer that turns those separate moves into a judgment engine: a roadmap signal you can defend with receipts, and a decision memo that’s already survived its own best counter-argument before anyone else reads it.
It’s Module 3 of the certifiable Founders & PMs track, and it inherits everything you built in Module 1. Your product-context.md is the contract this module’s bets are graded against: a recommended bet should serve the user and the priorities you already named, not a fresh guess at what matters. M1 mastered what you’re building and for whom; M3 builds the engine that turns scattered signal into a bet you can defend on top of that foundation — and assesses the engine, not one persuasive memo.
“Six customers asked for this” is a sentence that sounds like evidence and can be entirely wrong — five of the six messages might be the same one frustrated account. The free playbooks teach you to synthesize a feedback pile and compare a set of options well, once. This module is where that becomes the standard every roadmap bet meets, every time — because a confident-sounding theme and a real pattern look identical until someone counts distinct people, not messages.
The engine, not the persuasive paragraph
Most founders use Claude as a faster way to write the memo they already wanted to write: paste the options, get a recommendation, ship it. That’s not judgment — it’s confirmation with better formatting. The theme that “feels right” gets treated as validated, the recommendation that matches your gut gets circulated without anyone arguing the other side, and the first time someone asks “says who?”, there’s no answer beyond “it felt true.”
A signal-to-decision engine is two named moves that run the same way every time, on every real bet:
- Synthesize — de-identify the raw feedback, cluster it into themes, separate a real pattern from a loud minority by counting distinct people not messages, trace each kept theme to real quotes, and rank a short list of bets.
- Decide — lay the real options side by side against your actual priorities, get a recommendation with its reasoning and each path’s biggest risk, then have Claude argue the strongest case against its own pick before you write the memo.
Each move has one job and one output, which is what lets you name what’s broken when a bet goes wrong: a synthesis problem (a loud minority got mistaken for a pattern) or a decision problem (the priorities used to weigh the options weren’t actually yours). A system you can diagnose beats a confident paragraph you can only hope was right.
You run both moves in the chat. Open the feedback files and your product-context.md in Claude Desktop, and work one move at a time — no terminal needed on the main path.
Feedback-synthesis — the discipline that earns trust
The playbook gives you the steps: de-identify, theme, separate signal from noise, trace to quotes, rank bets. Mastery is the judgment inside those steps — the calls that separate a roadmap signal you can defend from one that just confirms what you already believed.
- Count people, not messages. Five tickets from one frustrated account is noise dressed as a trend. The discipline that makes a theme trustworthy is weighting by distinct customers, every time — a theme that’s “big” only because one account repeated it a lot gets flagged, not promoted.
- A theme with no quotes behind it is Claude over-generalizing, not a finding. If you can’t pull two or three real verbatim quotes for a kept theme, it was pattern-matched past the actual data. Drop it rather than let an unsubstantiated theme reach a roadmap.
- De-identify before anything enters a prompt — not after. Customer feedback is PII. Replacing names, emails, and account details with
[customer-n]labels is the first step, not a cleanup pass you do later if you remember. - A ranked bet still needs the receipts attached. “Fix onboarding” is a recommendation; “fix onboarding — 9 of 14 distinct customers, quotes attached” is a defensible one. The difference is what survives a stakeholder asking why this bet and not another.
A synthesis that clears this bar reads as a short, ranked list: the recurring themes weighted by distinct people, an honest real-pattern-vs-loud-one-off read per theme, real quotes behind every kept theme, and 2-3 ranked bets each tied to evidence — plus an honest name for the tempting theme you should not chase yet.
Decision-memo — the discipline that survives the room
A recommendation nobody pressure-tested is a guess with good formatting. The move that makes a memo defensible is making Claude argue against its own pick before you ever circulate it.
- Name your priorities before asking for a comparison. “We optimize for shipping speed this quarter, then cost, then flexibility” is what makes a recommendation weighted your way instead of Claude’s default assumptions. Skip this and you get a generic-sounding answer that happens to use your words.
- The reasoning is the actual deliverable, not the verdict. A recommendation you can’t see the logic of is one you can’t defend in the room. “What would have to be true for this to flip” is the single most useful line in the memo — it tells you exactly which assumption to pressure-test before committing.
- Red-team it before you write it up. Having Claude argue the strongest case against its own recommendation, then checking whether the pick survives that argument, is what separates a memo that’s actually been stress-tested from one that just sounds confident.
- Verify the numbers driving the choice. A recommendation built on a wrong cost figure or a hallucinated vendor fee is wrong regardless of how clean the reasoning looks. Check every number in the comparison table against its source, not Claude’s recall.
A memo that clears this bar reads as a one-pager: the options compared on your stated priorities, a recommendation with explicit reasoning, the biggest risk of every path (not just the chosen one), the line that says what would flip the call, and a steelman of the opposing view the recommendation already survived.
A note on Arabic signal
Most of this module’s discipline is language-agnostic — counting distinct customers works the same in any language. One thing genuinely changes: if your customer base is Arabic-speaking, feedback that arrived in Arabic should be themed and quoted in Arabic, not translated into English before clustering — a translated quote loses the register and specificity that makes it traceable evidence. If a memo or a roadmap bet will eventually surface in a bilingual board narrative, note here which language the underlying evidence is in, so M5’s board narrative can cite it accurately.
Your assignment
Build the signal-to-decision engine for one real bet — your own (recommended: the output is a roadmap decision your team genuinely commits to) or the sample brand Mizan, the GCC bookkeeping SaaS whose co-founder, Dana Al-Qassimi, runs throughout this track. Open the chat in Claude Desktop with your de-identified feedback files and your product-context.md — no terminal needed.
Module 3 deliverable — the signal-to-decision engine
Inherits from M1: product-context.md
1. feedback-signal.md (the feedback-synthesis output)
- 5-7 recurring themes, each weighted by DISTINCT customers, not
message count
- a real-pattern-vs-loud-one-off read per theme
- 2-3 verbatim quotes per kept theme, with [customer-n] labels
- 3 ranked bets, each with the theme, distinct-customer count, rough
effort, and the quotes that justify it
- one theme named as tempting but NOT worth chasing yet, with why
2. decision-memo.md (the decision-memo output)
- your stated priorities, in order
- the real options laid side by side against those priorities
- a recommendation with explicit reasoning and each path's biggest
risk
- the line that says what would flip the recommendation
- a steelman of the strongest case against the pick
PII: every customer name, email, company name, and account ID is
replaced with [customer-n] before anything enters a prompt. What you
submit carries the labels, never the real identities.The Foundation toolkit holds the product-context.md template the priorities in this module’s decision memo should trace back to.
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.
Signal-to-decision rubric
1. Themes are weighted by people, not messages
Every theme states a distinct-customer count, not a message count.
At least one loud-minority theme is correctly flagged as such.
2. Every kept theme has real quotes
2-3 verbatim quotes per theme, with [customer-n] labels intact. Any
theme without quotes was dropped, not kept on a hunch.
3. Bets are ranked with receipts
Each of the 3 ranked bets names its theme, its distinct-customer
count, a rough effort, and the quotes behind it — not just a title.
4. The memo's reasoning is real, not a verdict
A reader can follow WHY the recommendation wins on the stated
priorities, not just which option was picked.
5. The memo survived its own counter-argument
A genuine steelman of the opposing view appears, and the
recommendation either holds against it or was revised because of it.The discipline is deliberately what a skeptical co-founder would demand: a theme inflated by one loud account, or a recommendation nobody pressure-tested, fails quietly the moment someone asks “says who?” — 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 synthesized the fallout from a billing incident into a roadmap call.
feedback-signal.md — Mizan, Q2 2026 (excerpt)
Themes (from support tickets, sales notes, and CSAT comments; names
replaced with [customer-n]):
Billing trust — wants confirmation a charge is correct (real: 11
distinct customers, all from the March 1 double-billing incident,
across Starter and Pro tiers — same incident Support found via
tickets and Data independently confirmed via root-cause).
VAT export format — wants a native export, not a CSV workaround
(real: 7 distinct customers across 3 months, recurring ask, not a
single loud account).
Custom invoice branding — wants their logo on invoices (loud
one-off: 1 enterprise-leaning account, mentioned in 5 tickets).
Quotes:
Billing trust — "[customer-3], ticket: I was charged twice for my
annual plan and I don't know if it's fixed or if it'll happen
again." "[customer-7], ticket: how do I know this won't happen next
renewal?"
VAT export — "[customer-2], sales call notes: we export to Excel
and reformat by hand every quarter for our accountant — it's the
most annoying part of using Mizan."
Ranked bets:
1. Flag-a-charge + renewal safeguard — 11 distinct customers, medium
effort, quotes attached. Addresses the billing-trust theme
directly and ties to product-context.md's billing-trust bet.
2. Native VAT export — 7 distinct customers, medium effort, quotes
attached. Ties to the GCC-compliance-depth bet.
3. Improve renewal-confirmation email — 4 distinct customers, small
effort. Lower-cost mitigation for the same billing-trust theme.
NOT chasing yet: custom invoice branding — one loud account, large
effort (would need a template engine), and product-context.md
already excludes enterprise this phase.decision-memo.md — VAT export: build native vs. integrate a third
party (excerpt)
Priorities, in order: GCC-compliance depth (this phase's core bet),
then shipping speed, then ongoing cost.
Options compared:
Build native VAT export — Speed: slow, ~6 eng-weeks. Cost: low
ongoing. Compliance fit: best — exact local format control.
Integrate a third-party export tool — Speed: fast, ~1 eng-week
integration. Cost: per-export fee at scale. Compliance fit: good but
not GCC-specific; format updates depend on their roadmap, not ours.
Recommendation: build native. It's the only option that fully serves
the top priority — GCC-compliance depth is the bet we're staking the
wedge on, and a third-party tool puts our compliance roadmap on
someone else's schedule. We trade six weeks of speed for full control.
Biggest risk — Build: eng time overruns into Q3. Third-party: a format
change request takes weeks to land on their side, during a quarter
when VAT reporting rules just tightened.
This flips to the third-party option if compliance depth stops being
the top bet, or if a format change is needed before native ships.
Steelman against building native: a skeptic would say six eng-weeks on
an export format is exactly the kind of work that should be bought,
not built — and they'd be right if compliance weren't the wedge. The
recommendation holds because this isn't a generic export feature, it's
the thing the whole market-landscape.md wedge depends on.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 scattered feedback pile into a bet you can defend with receipts, and a set of options into a recommendation that’s already survived its own best counter-argument. That’s the Signal-to-Decision stage of “Certified Founders & PMs with Claude.”
From here the track turns a defensible bet into a full product operation, each module assessed the same way:
- 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 de-identify-then-theme structure and the priorities-first comparison are the permanent habits — keep a running feedback folder and re-run the synthesis each quarter so you see what’s rising, fading, or finally fixed. 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.