Project Manager Onboarding

Punch's core methodology — design and content fuse

Design and content cannot exist without one another. Neither is more important. They fuse to communicate.

This is the operating principle underneath every project Punch ships. As PM, you're not making design or content decisions — but you ARE the operational owner of the conditions that let fusion happen. Three consequences for the PM specifically:

1. You schedule fusion moments, not solo moments. The strategist + designer work together on themes presentation. The strategist + designer + writer all converge at G5 (per-batch QA). The lead designer + writer collaborate during Phase 1. Your scheduling has to put the right people in the room at the right time — not let work happen in parallel silos that converge late.
2. The Big Idea is the spine of the project, and your job is to protect it. Every locked artifact downstream of G2 (copy-brief.md, the chosen homepage, the per-page content) is supposed to reinforce the same Big Idea. When something drifts — a writer's draft doesn't feel like the Big Idea, a designer's hero loses the emotional truth — that's a signal to slow down and re-anchor, not to push through. PMs notice this early because you're seeing the work cross-role.
3. Your status reports tell the fusion story. Status to the client isn't "design is 60% done, copy is 40% done." It's "the chosen direction is landing — the homepage hero feels like [Big Idea], copy is reinforcing it, we're on track for G5 next Tuesday." Frame the work in terms of how it's coming together, not which silo is at what percentage.

You're the human glue. The fusion methodology is the test for whether the glue is holding.

This module sits on top of the Client-Facing Team training

Every Punch PM reads the internal Client-Facing Team training before reading this. That training is the foundational doc on how Punch communicates with clients — the "be a professional, don't act professional" standard, the words to remove from client comms entirely (final, approval, deliverable, batches, high value pages, etc.), the internal-terms-never-with-clients translations, the pre-send email checklist, the "say fewer words" and "hear the meaning, not just the words" principles.

This onboarding assumes all of that as the foundation. Module 6 (Client comms & gate facilitation) layers on top with the PM-specific patterns: when to send what kind of comm, how to frame the pulse-check artifact, how to handle change requests, how to send status without slipping into "60% done" language. If you haven't read the Client-Facing Team training, do that first.

What you own across the project

Five things, none of them small:

1. The Asana project board. The canonical task list (Module 3), owners per task, due dates, dependencies, gate links. The board is the source of truth — if it's not in Asana, it's not happening.
2. Timeline + scope. The 8-week sprint stays 8 weeks because you're enforcing the locks. Change requests get logged, scoped, and either absorbed (with timeline impact noted) or pushed to a future engagement (Module 7).
3. Client touchpoint orchestration. Scheduling, agendas, pre-meeting comms, post-meeting follow-ups, the pulse-check feedback artifact distribution. You're sending the comms in Module 6's scripts — the strategist co-presents and owns the strategic content; you own the operational mechanics.
4. Internal team coordination. Multi-designer Phase 0 (Module 4), the writer-strategist-designer handoffs in Phase 1, per-batch G5 rhythm in Phase 2, dev cleanup in Phase 3. You see across silos and intervene early.
5. Risk management + blameless post-mortems. When something slips, you log it, surface it, run a no-blame retro at project end so the next project doesn't repeat the same friction (Module 8).

What you don't own

The strategic and creative decisions. Specifically:

• The Big Idea — strategist owns; you protect it.
• The brief, themes, sitemap, copy-brief.md — strategist owns; you schedule the work.
• The visual direction — designers own; you coordinate.
• The copy — Primary Writer owns; strategist QAs.
• Technical decisions about CMS, performance, a11y — TDM and dev own; you track.
• Client brand sign-off, theme pick, homepage pick — client decisions; the CCO + strategist guide the conversation.

Your value is in making all of these things happen on time, in the right order, with the right people in the right rooms. Not in making the decisions yourself.

How this onboarding is structured

• Module 2 — Your role per phase. Phase-by-phase walkthrough so you know what to expect when.
• Module 3 — The Asana template. The canonical task list for an 8-week Punch website project. This is the meat of the onboarding. There's a companion CSV file (punch-website-asana-template.csv) you can import directly into a new Asana project.
• Module 4 — Phase 0 multi-designer coordination. The specific scheduling work for the themes exercise (3 designers in parallel), the post-G2 build-out designer, and the lead client designer handoff.
• Module 5 — Running the 9 gates. The canonical 9-gate model, scheduling, attendees, agendas, post-meeting comms for each.
• Module 6 — Client comms & gate facilitation. How the PM runs each client gate touchpoint, schedules, captures decisions, frames pulse-checks vs formal gates, keeps client informed between gates.
• Module 7 — Change requests, risk & blockers. Distinguishing change requests from pulse feedback, logging and scoping with the CCO, tracking source/_missing.md chase items, watching for Phase-3 surprises.
• Module 8 — Post-launch: verify, retro & quick reference. The 48-hour production verification, owning the post-launch retrospective, and a condensed PM quick-reference card.

Self-check before moving on

• I can explain Punch's fusion methodology (design + content) and why it matters for PM scheduling
• I've read the Client-Facing Team training and understand it's the foundation under this doc
• I can name the five things the PM owns and the six things the PM does NOT own
• I understand the Punch PM is not an order-taker — I'm an expert orchestrator with opinions about how good work gets made

Phase 0 — Strategy, Brand & Two Homepages (~4 weeks)

The phase with the most moving parts. Strategist leads strategically; you lead operationally.

Week 1 — discovery + brief + source folder

• Schedule kickoff with the client (day 1 or 2). Strategist + CCO + you + key client stakeholders.
• Make sure the strategist has access to every discovery material they need — kickoff transcript, questionnaire responses, client brand docs, public press. Drop them in the project's discovery/ folder.
• Source folder ownership (new in v0.7.5+). Whenever the client sends technical material — data sheets, capability docs, integration matrices, compliance certs, customer lists — drop it into the project's source/ folder. Organize by subfolder however helps (per product, per page, per topic). No manifest required; the content skills auto-discover by scanning the tree. This is your job, not the strategist's. A populated source folder is what stops punch-content-brief and punch-web-copywriter from refusing to draft factual pages — and stops them from fabricating product copy (the Auria failure mode).
• Strategist runs punch-content-brief mid-week, locks the brief by end of week. You're not in the brief itself — you're protecting time for the strategist to do it. Watch the brief for MISSING SOURCE markers — those are auto-flagged sections that need source material. The skill also auto-appends a chase list to source/_missing.md — your tracker for what to chase from the client.
• Watch for: client not sending discovery materials on time. If the questionnaire isn't back by day 3, escalate to the CCO. Don't let the brief slip into week 2. Same urgency for source material on factual pages — if a product data sheet isn't in source/ when the strategist drafts that page brief, the page will hit a MISSING SOURCE marker and can't ship until you chase the file.

Week 2 — three themes in parallel

• Strategist runs punch-theme-taglines at start of week. Hands off design direction signals to three theme designers (see Module 4 for staffing detail).
• You schedule each of the three theme designers for week 2 work. Each gets their own assignment.
• Mid-week: 15-min check-in with each theme designer. Not a review — a "are you on track, do you need anything" gut-check.
• End of week 2: G2 — Client picks the theme/Big Idea visually. You handle scheduling, agenda send-out, pulse-check artifact distribution post-meeting (Module 5 has the gate script).
• Watch for: theme designers falling into similar visual territory. If two themes look like the same idea by mid-week, surface to the strategist and CCO — push for more differentiation before G2.

Weeks 2–3 — reconcile + flesh out + brief + sitemap locked as G1

• After G2, capture the client's pick precisely (often a hybrid). Hand to the strategist for the reconciliation working session.
• Schedule that working session within 24 hours of receiving the pulse-check artifact back. Strategist + the build-out designer for a 60-90 min session.
• Build-out designer fleshes out the chosen brand (full icon system, button states, photography direction). Also sets up the canonical client fork at this point.
• Strategist completes the abbreviated brief + sitemap in parallel, locking both by end of week 3. Together, the brief + sitemap lock constitute G1 — the first formal client gate. This is when the Three Big Ideas pass to design. Schedule a brief 30-min sign-off call with the client confirming the brief + sitemap are locked (Module 5 and Module 6 have the G1 scripts).
• Watch for: the build-out designer trying to absorb every cherry-picked element from the hybrid. Some combinations don't work — strategist + designer have to make fusion calls. Don't let it drag past week 3.

Weeks 3–4 — two homepage takes, then G3 & G4

• Lead client designer takes over (sometimes same person as build-out designer, sometimes different).
• Two homepage takes — one "safer," one "more creative/interactive" — both functioning code at desktop. Allow ~5–7 working days.
• End of week 4: G3 — Client picks the homepage direction. Strategist + lead designer co-present. Real functioning code, not slides. Schedule 30–45 min. Send the homepage pulse-check artifact within 30 min of meeting close. 48–72 hour return window (biggest decision in the project; let the client live with both).
• Once G3 closes: Immediately move to wireframe phase. Lead designer + writer + strategist produce the remaining-pages wireframe (all pages not designed in Phase 0). End of week 4 or early week 5: G4 — Client reads the wireframe end-to-end and signs off on copy + structure (locks composition). Schedule 45–60 min for a detailed walkthrough.
• Watch for: the two homepage takes converging into "basically the same." Push the designer to actually differentiate the hero interaction style — that's the whole point of the gate. Also watch for the wireframe phase stretching if the brief wasn't sharp enough — that's a Phase 0 problem that surfaces here.

Phase 1 — Foundation (~1 week)

• Client picked one of the two homepages. Lead designer finalizes the chosen take in Cowork with real copy from the Primary Writer. The finalized homepage + sandbox spec become the design reference for Production's amplifier run in Phase 2.
• Coordinate the Writer's homepage draft with the Strategist's QA — the Writer drafts, the Strategist reviews, copy goes back if not landing strategically, then locks at draft lock.
• Lead designer runs punch-token-export + punch-omma-export as part of the sandbox spec.
• Dev works in parallel through Phase 1 — runs /website-to-static:convert to scrape the old site and produce the site-llm/ directory (the content input Production will need), and sets up branch-based preview infrastructure. CMS integration deferred to Phase 3.
• TDM manages both workstreams (Lead Designer's Cowork work + Dev's scrape/infrastructure work) and owns the technical handoff to Production at start of Phase 2.
• Watch for: Phase 1 stretching past one week. If draft lock isn't closing by end of week 5, either the brief was thin (root cause is back in Phase 0) or the writer's drafting got stuck. Also watch for Dev's site-llm/ output or branch infra not being ready by end of week 5 — Production can't start their amplifier run without those two inputs.

Phase 2 — Interior pages, batched (~2 weeks)

• Production runs /website-design-amplifier:amplify early in Phase 2 — fuses Dev's site-llm/ with the Lead Designer's design reference (sandbox spec + finalized homepage code) to generate the full redesigned static site: standard pages, listing pages, articles, blog/thought-leadership content. This is a single skill invocation in Claude Code that replaces what used to be weeks of manual templating + brand application + blog migration.
• Two streams converge into the static preview: the amplifier's output (standard + blog + listing pages) and the Lead Designer's bespoke showcase pages from Cowork. Showcase pages override the amplifier's equivalent pages where they exist.
• Typically 2 batches of 4–6 showcase pages each. Per-batch rhythm: writer drafts → designer brings to life in Cowork → G5 (internal per-batch QA) → pulse-check to client → showcase lock. G5 is internal-only (TDM, strategist, writer, designer); the per-batch client feedback comes back via pulse-check, not a formal gate.
• You schedule each G5 — 15 min internal meeting, all roles (TDM + strategist + writer + lead designer + you). Focus on the showcase pages from designer polish.
• After each G5: send the pulse-check artifact for that batch's pages to the client, 24-hour return window. Then strategist closes showcase lock for the batch once pulse-check returns.
• CMS pilot mid-Phase 2 — Dev pushes one page through the chosen CMS to validate the integration before the final migration in Phase 3. Track as a milestone on Asana, not a formal client gate.
• Lead designer also maintains the Standard Page Assets frame in Figma. Production references it for any manual touch-ups on amplifier-generated pages.
• Watch for: internal per-batch reviews bloating into "let's also revisit X" sessions. G5 is 15 min. Also watch for the amplifier output requiring more manual touch-up than expected — if Production is making heavy edits page by page, the design reference probably wasn't complete enough. Surface to Lead Designer + TDM.

Phase 3 — Review + Launch (~1.5 weeks)

• Dev does the framework-level cleanup on the static preview — responsive math at 768 + 375, performance optimization.
• Production runs the a11y baseline pass and applies internal feedback edits to the static preview (Claude Code). Strategist does the final full-site read for strategic coherence and closes final copy lock.
• QA pass #1 (static): TDM runs the Pre-Launch QA orchestrator against the static Build before the client sees it — so the client reviews a clean build. Zero BLOCKERS before it goes out.
• The site lives as a STATIC preview through client review. The client reviews the static preview URL, not the CMS version. CMS migration comes only after the client signs off at G6.
• G6 — Client signs off on "The Build" (the full designed site as functioning HTML, on the static preview). This is the formal client gate that unblocks CMS migration. You + strategist co-send the sign-off comm with the static preview URL. The framing here changes — this is the only client touchpoint that isn't a pulse check (see Module 6).
• After G6: Dev migrates the approved Build into the chosen CMS; Production does the CMS-format polish pass (Claude Code) — catches anything migration didn't preserve cleanly.
• G7 — QA pass #2 (migrated): TDM re-runs the Pre-Launch QA orchestrator against the CMS-migrated site. Zero BLOCKERS or the launch is held. TDM coordinates with Dev + Production to fix anything migration introduced.
• G8 — Launch (DNS cutover, redirects, analytics activation). Dev + TDM own the technical cutover.
• G9 — Within 48 hours of G8, re-run pre-launch QA against production. Verify integrations, analytics, forms all live. Schedule the post-launch retro for ~2 weeks after launch. Blameless format (Module 8).
• Watch for: client coming back with "actually can we change X" during the G6 sign-off window. That's a change request, not pulse feedback — log it, scope it, and decide with the CCO whether to absorb (and impact launch date) or push to a follow-on engagement. Also watch for CMS migration surprises late in Phase 3 — the Phase 2 pilot should have caught most of them, but track residual risk (see Module 7).

Self-check before moving on

• I can name the four phases and the approximate week count for each
• I understand Phase 0 runs in order: brief+sitemap sign-off (G1), then theme pick (G2), then homepage pick (G3), then wireframe sign-off (G4)
• I know the per-batch rhythm in Phase 2 (copy → bring to life → G5 internal QA → client pulse-check → showcase lock)
• I know Phase 3 includes G6 (client build sign-off), G7 (pre-launch QA), G8 (launch), and G9 (48-hour verification)
• I can name at least three "watch for" failure modes across the four phases

The canonical task list, ~34 tasks for an 8-week project

Organize as Asana sections per phase. Each task has: name, owner (role placeholder), day offset from project start, dependencies, and a short note. The companion CSV (punch-website-asana-template.csv) is structured exactly this way for direct Asana import.

Phase 0 — Strategy, Brand & Two Homepages (days 1–35)

Phase 1 — Foundation (days 36–42)

Phase 2 — Interior pages, batched (days 43–56)

Two batches assumed. Adjust if a project has more/fewer.

Phase 3 — Review + Launch (days 57–63)

The companion CSV

The full task list ships alongside this doc as punch-website-asana-template.csv, with columns: Name, Section, Assignee, Day Offset, Dependencies, Notes. Asana's CSV import takes most of these directly.

How to use it

1. Create a new Asana project for the client (named Punch · [Client] · Website).
2. Add → Import → CSV. Asana opens a column mapping dialog.
3. Map columns: Name → Task name. Section → Section/column. Assignee → Assignee (you'll edit role placeholders to actual people post-import). Day Offset → not directly supported; you'll apply due dates after import.
4. Post-import, apply real dates: use the day offsets in the CSV as the relative schedule. If kickoff is Tuesday Jan 7, then day 1 = Jan 7, day 14 = Jan 20, etc. Asana has a "shift dates" feature on imported projects — set the project start date and the offsets shift to real dates.
5. Replace role placeholders with real people: [STRATEGIST] → actual strategist's name. [THEME DESIGNER 1/2/3] → the three assigned theme designers for Phase 0 week 2 (Module 4 covers staffing). [BUILD-OUT DESIGNER], [LEAD CLIENT DESIGNER], [PRIMARY WRITER], etc.
6. Adjust batch count in Phase 2 if the project has more or fewer than 2 batches. Tasks 22–29 are templated for 2; add or remove rows as needed.
7. Don't add tasks unless they're a deliverable, lock, gate, or pulse-check. Stay lean.

What you do NOT add to the board

• "Weekly status update" recurring tasks. The board's task-completion state IS the status.
• "Send agenda" / "Send invite" / "Send recap" as separate tasks. Each gate is ONE task — the meeting itself. The PM does the agenda + invite + recap as part of running that gate; tracking it separately is busywork.
• "Schedule [meeting]" tasks. Scheduling is part of owning the meeting task, not a separate task.
• Sub-tasks for things the owner can figure out themselves. If the writer needs to research the audience before drafting copy, they don't need a sub-task on the Asana board telling them so.
• Internal mid-week check-ins. These happen verbally (Slack, standup). Not tasks.

Self-check before moving on

• I can name the four task types that DO belong on the board (deliverable, lock, gate, pulse-check)
• I can name at least four task types that do NOT belong (weekly status, send agenda/invite/recap as separate tasks, schedule-the-meeting, micro-subtasks)
• I've imported the companion CSV into a test Asana project and replaced the role placeholders with real names
• I understand the day offsets are relative to project start and shift to real dates post-import

The three designer roles, in sequence

1. Theme designers — three of them, in parallel, week 2

Once the strategist locks the Creative Brief and runs punch-theme-taglines at start of week 2, Punch assigns three theme designers — one per theme direction (Theme A / B / C). They work in parallel for 4–5 working days. Each:

• Receives the design direction signals for their assigned Big Idea from the strategist
• Creates the visual half of one creative theme — logo direction, color palette, typography selection, brand collateral mockups (business card, mug, polo, etc.), hero mockup on a laptop frame, design rationale
• Works in an exploratory Figma file, not the canonical client fork. The token system isn't engaged yet.
• Hands off their theme to the strategist + designers for the G2 presentation

Who gets assigned: coordinate with the CCO + strategist on staffing. Common patterns:

• Three senior-or-mid designers, none of whom is also the lead client designer for the project — keeps each theme fresh and uninfluenced by "what we'll have to build later"
• OR: the lead client designer takes one of the three themes, plus two other designers — risks the lead's theme becoming a foregone conclusion, but works when one of the other two is a strong creative who'll push back
• OR (small projects): one designer does all three themes themselves — less ideal because the three themes tend to converge, but sometimes the only option on tight budgets

2. Revise / build-out designer — one of them, weeks 2–3 (post-G2)

After the client picks at G2 (often a hybrid of 2–3 themes), one designer owns the reconciliation + build-out. Frequently one of the three theme designers — usually whichever one's theme contributed most to the client's pick. Sometimes a different designer entirely (e.g., the CCO assigns the build-out to whoever has bandwidth + the right craft for this client). The build-out designer:

• Sits with the strategist in the reconciliation working session (60–90 min, you schedule it within 24 hours of receiving the pulse-check artifact)
• Locks the combined direction — what's pulled from each theme, what gets reconciled when elements conflict
• Creates the canonical client fork in Figma for the first time — subscribes to the master library, duplicates the Punch Tokens collection locally, sets values to the chosen direction, smoke-tests with punch-rebind
• Fleshes out the brand: full icon system, button states, photography direction, illustration direction
• Fills in copy-brief.md (the three visual paragraphs — Big Idea + voice block came from strategist at theme lock)

3. Lead client designer — weeks 3–4 onward

Sometimes the same person as the build-out designer; sometimes different. The lead client designer:

• Designs the two homepage takes in the canonical fork (weeks 3–4)
• Co-presents the homepages with the strategist at G3
• Produces the remaining-pages wireframe for G4 client sign-off (all pages not designed in Phase 0)
• Carries the project through Phase 1 (finalize chosen homepage + sandbox spec) and Phase 2 (interior pages in Cowork)
• Runs punch-token-export + punch-omma-export at Phase 1 start
• Owns the Standard Page Assets frame in Figma for dev's templating

This is the person the dev team and CCO will reach out to throughout Phases 1–3. Establish them clearly post-G2.

Your coordination job, week by week

Before kickoff — staffing the three theme designers

You don't make this call solo. CCO + strategist + you decide. Get it locked at least 3 days before week 2 starts so the theme designers have time to clear their schedule. Once locked, send a single Slack note to all three:

Hey [Designer 1, 2, 3] — you're each assigned a creative theme for
[client]'s Phase 0. Strategist will share the brief + direction signals
end of week 1. Theme exercise runs week 2; presentation is [Friday]
afternoon. I'll set up a 15-min mid-week check-in with each of you.
Let me know any conflicts now.

Week 2 — light check-ins, not reviews

• One 15-min mid-week check-in with each theme designer. NOT a review of their work-in-progress. Frame: "are you on track, do you need anything from me or the strategist".
• Don't pull them into a group review mid-week — it'll create cross-influence between the themes, which kills the point of independent exploration.
• Watch for two themes drifting into the same visual territory by Wednesday/Thursday. If you see it, flag to the strategist and CCO — they decide whether to push one designer to differentiate or accept the convergence.

End of week 2 — G2 prep

• Make sure each theme designer has their full deliverable assembled (logo, palette, type, collateral, hero mockup, rationale) in a presentation-ready format by Thursday end-of-day, latest.
• Strategist + designers do a 30-min internal walk-through Friday morning before the client meeting — gives them all a chance to see each other's work and prep the presentation flow.
• You handle the actual G2 logistics (Module 5).

Post-G2 — capturing the pick precisely

The client's pick is often a hybrid: "love Big Idea from Theme A, color palette from Theme B, type from Theme C." Don't lose the specificity. Within 24 hours of the pulse-check artifact returning, write down exactly what got pulled from each theme — in the client's words, not your translation. This becomes the brief for the reconciliation session.

Naming the build-out designer + scheduling the reconciliation

• Confirm with the CCO + strategist who's doing the build-out (often but not always one of the three theme designers).
• Schedule the reconciliation working session within 24 hours of the pulse-check artifact returning. 60–90 min. Strategist + build-out designer + you (optional — drop after first 10 min if not needed).
• Output of the session: a clear, written reconciled direction the build-out designer can flesh out solo.

Confirming the lead client designer

• This often becomes clear during or just after the reconciliation session — the build-out designer either continues as lead, or hands off to a different designer for the homepage takes.
• Get this locked by end of week 3 so the lead has the full ~1.5 weeks for the two homepage takes and the wireframe (G4).
• If the handoff is to a different designer: schedule a 30-min handoff session between build-out and lead. Walk through the brand assets, the copy-brief.md, any client texture from G2.

Common failure modes

1. Late staffing

The three theme designers should be staffed at least 3 days before week 2 starts. Last-minute assignments mean designers are clearing their schedule rather than thinking about the brief. The work suffers.

2. Pulling theme designers into a group review mid-week

Tempting because it feels like collaboration. Don't. Three themes done independently give the client a real choice. Three themes done after a group review converge into variations of the same idea.

3. Losing the hybrid specificity post-G2

"Client liked Theme B with some elements from A and C" is too vague. The reconciliation session can't work from that. Write down exactly what was picked from each theme in the client's words, within 24 hours of the pulse-check returning.

4. Ambiguity about who's the lead client designer

If by end of week 3 the team isn't clear on which designer is taking the two-homepage takes (and carrying the project through Phase 3), you have a problem. Confirm with CCO + strategist. Send a Slack note naming the lead so the team knows.

5. Build-out designer trying to absorb every cherry-picked element

Some hybrid combinations don't work mechanically (color from Theme A clashes with type from Theme C). The build-out designer + strategist have to make fusion calls — what stays, what gets reconciled, what gets dropped. If you sense the build-out designer is trying to keep everything to please the client, surface to the CCO. Drift here cascades.

Self-check before moving on

• I can name the three designer roles in Phase 0 and what each owns
• I know to staff the three theme designers at least 3 days before week 2 starts
• I understand mid-week check-ins are gut-checks not reviews — and why group reviews mid-week hurt the work
• I know to capture the client's pick precisely (in their words) within 24 hours of the pulse-check returning
• I understand the lead client designer needs to be confirmed by end of week 3

The nine gates: client gates, internal gates, launch gates

The canonical workflow has nine gates spread across four phases. Three are client-facing gates where the client decides or signs off. Five are internal gates where the team validates readiness. One is the launch itself. After each gate closes, you signal downstream work in Slack/Asana.

G1 — Client signs off on abbreviated brief + sitemap

When: End of Phase 0 week 3 (after strategist locks brief + sitemap).
Length: 30 min.
Attendees: Strategist + you + client decision-makers.
Type: Client gate — sign-off, not pulse-check.
Format: Strategist walks the abbreviated brief + the sitemap hierarchy. You confirm the client has seen both and can sign off. This is the point at which the Three Big Ideas officially pass to design.
Your prep: Confirm both docs are finalized. Send a brief 1-line meeting invite with the brief + sitemap PDF link.
Artifact: Email confirmation from client that brief + sitemap are locked. No pulse-check form.
Watch for: Client questions about pages or scope — answer strategically or log as change request (Module 7). Once G1 closes, the brief + sitemap are locked.

G2 — Client picks the theme/Big Idea visually

When: End of Phase 0 week 2 (typically Thursday or Friday afternoon).
Length: 45–60 min.
Attendees: Strategist + three theme designers + CCO (optional but recommended) + you + client decision-makers.
Type: Client gate — pulse-check.
Format: Live walkthrough. Each theme gets its own ~12–15 min — Big Idea, tagline, visual artifacts, hero mockup, design rationale. Strategist + the theme's designer co-present. Show the "safer" theme first, then progressively more experimental.
Your prep: Confirm each designer's theme is presentation-ready by Thursday EOD. Test AV (live demo, not screenshots). Send pre-meeting comm 1–2 days before. Prepare the pulse-check artifact for post-meeting distribution.
Artifact: Pulse-check: Per-element ratings on Big Idea clarity / Visual fit / Tagline resonance / Color palette / Typography / Imagery for each theme, plus gut-reaction words, plus the optional flag. Return window: 48 hours.
Watch for: Client wanting to combine elements from multiple themes — this is normal and expected. Capture the hybrid precisely; don't force a single-theme pick. Hand off the client's answer to strategist for the reconciliation working session (Module 4).

G3 — Client picks the homepage direction

When: End of Phase 0 week 4. The biggest decision in Phase 0.
Length: 45–60 min.
Attendees: Strategist + lead client designer + CCO (recommended) + you + client decision-makers.
Type: Client gate — pulse-check.
Format: Live walkthrough of both homepages as functioning code (not slides). Strategist + lead designer co-present. Walk the "safer" take first, then the "more creative/interactive" take. Don't lead with which one Punch prefers — let the client form their reaction.
Your prep: Confirm both homepage takes are functioning at desktop. Load them on the laptop you'll be demoing with. Test the demo before the call. Send pre-meeting comm 1–2 days before. Prepare the pulse-check artifact.
Artifact: Pulse-check: Per-element ratings on Hero / Layout / Copy / Voice / Overall feel for each take. Gut-reaction words on Hero / Interaction / Copy / Voice / Overall feel. Return window: 48–72 hours. Biggest decision in the project — let the client live with both before deciding.
Watch for: Client trying to combine the hero from take A with the layout from take B. The hero interaction IS the differentiator. Push back: "we'll pick one direction and refine it" rather than "we'll Frankenstein the two."

G4 — Client reads wireframe end-to-end; signs off on copy + structure

When: End of Phase 0 week 4 or early week 5 (after G3 closes and wireframe is drafted).
Length: 60 min.
Attendees: Strategist + lead designer + writer + you + client decision-makers.
Type: Client gate — sign-off, not pulse-check.
Format: Lead designer walks the remaining-pages wireframe (all pages not designed in Phase 0) page by page. Strategist + writer highlight the copy structure and voice. You guide the client through the presentation and confirm alignment.
Your prep: Confirm the wireframe is complete. Send pre-meeting comm 1–2 days before with the wireframe PDF or shared link.
Artifact: Email confirmation from client that the wireframe composition (copy + structure for all pages) is locked. Once G4 closes, no major page structure changes.
Watch for: Client questions that signal the brief wasn't sharp enough. Note these and surface to the CCO — they may become change requests (Module 7).

G5 — TDM runs per-batch QA (internal)

When: End of each Phase 2 batch (~2 per project).
Length: 15 min STRICT.
Attendees: TDM + strategist + writer + lead designer + you.
Type: Internal gate — no client.
Format: The team converges briefly. Each role does a 2–3 min check: visual consistency (lead designer), voice continuity (strategist + writer), readiness to ship to client (TDM + you). TDM signs off that the batch is ready for client feedback.
Your prep: Confirm batch pages are up on PunchProof. Bring recent client pulse-check signals if available.
Next step: After G5, you send the pulse-check artifact to the client (per-batch). 24-hour return window. Once pulse-check comes back, strategist closes the showcase lock for that batch.
Watch for: The meeting bloating past 15 min. G5 is 15 min. If the team wants to revisit something, that's a separate working session.

G6 — Client signs off on "The Build" (full designed site as functioning HTML)

When: Phase 3, mid-week.
Length: 30 min.
Attendees: Strategist + you + client decision-makers (can be async; email sign-off is OK).
Type: Client gate — sign-off, not pulse-check.
Format: Client reviews the static preview URL as a whole. This is the formal client gate that unblocks CMS migration. You + strategist co-send the sign-off message with the preview URL and framing: "Here's the full designed site, functioning as HTML. Review at your own pace. Once you confirm it's ready, we'll proceed to CMS migration + launch."
Your prep: Confirm the static preview is fully ready — QA pass #1 (pre-launch QA on the static build) is clean and all polish is done — then get the CCO's internal sign-off before sending it to the client.
Artifact: Email confirmation from client that the built site is approved. This is the ONLY gate framed with expert confidence, not as a pulse-check.
Watch for: Client coming back with "actually we want to change X." That's a change request — log it, scope it, and decide with the CCO whether to absorb (delay launch) or push to follow-on (Module 7).

G7 — TDM re-runs Pre-Launch QA on the migrated site (internal)

When: Phase 3, after G6 sign-off and CMS migration.
Length: 30–45 min or async.
Attendees: TDM + dev + production.
Type: Internal gate — no client.
Format: This is QA pass #2. (Pass #1 ran the orchestrator on the static Build before G6, so the client reviewed a clean build.) Now TDM re-runs the Pre-Launch QA orchestrator against the CMS-migrated site to catch anything migration introduced — rich-text drift, dropped spaces, broken links, misplaced assets, a11y regressions. Zero BLOCKERS or the launch is held until fixed.
Your prep: Confirm CMS migration + the CMS-format polish pass are done. Track G7 status on Asana.
Watch for: Regressions the migration introduced, plus anything that should've been caught in the static pass or per-batch QA. Log them as risks and surface in the post-launch retro (Module 8).

G8 — Launch (DNS cutover, redirects, analytics)

When: Phase 3, end of week (after G6 + G7 both pass).
Length: 30 min (technical execution).
Attendees: Dev + TDM (you are optional; stay available for comms).
Type: Launch gate.
Format: Dev + TDM execute the DNS cutover, activate redirects, turn on analytics, verify the site is live. You send a brief internal Slack message to the team: "Site is live. Post-launch verification runs tomorrow."
Your prep: Confirm the launch date is locked on Asana. Prepare the public launch announcement (if the client wants one).
Watch for: Last-minute issues or client requests. None should reach you at this point — everything was locked at G6. But stay alert.

G9 — Production QA verification (within 48 hours of G8)

When: Phase 3, next business day or two after G8.
Length: 60 min or async.
Attendees: TDM + production (you track completion on Asana).
Type: Internal verification gate.
Format: Re-run pre-launch QA against the production site (not the static preview). Verify integrations, analytics, forms, tracking pixels, email signups, anything that depends on the live infrastructure. If issues are found, they're either hotfixed immediately or logged for the post-launch retro.
Your prep: Schedule the post-launch retro for ~2 weeks after G8 (Module 8). Confirm G9 completion on Asana.
Watch for: CMS migration surprises that weren't caught in Phase 2 pilot. Log them for the retro.

The pattern: client gates use pulse-checks; sign-off gates use email

Client gates with pulse-checks (G2, G3): Pre-meeting comm → live walkthrough → post-meeting pulse-check artifact → 24–72h return window → capture + close. These feel exploratory and collaborative.

Sign-off gates (G1, G4, G6): Pre-meeting confirmation → brief review → email sign-off. These feel decisive and expert. G6 especially: you're not asking the client to rate things; you're confidently handing them the finished site.

Internal gates (G5, G7, G9): Team convergence → readiness check → signal downstream. No client, no pulse-check.

Common failure modes

1. Sending pulse-checks before the live walkthrough

G2 and G3 require the client to see the work live first, then fill out the pulse-check form. If you send the form ahead, you get cold ratings on incomplete context.

2. Gates bloating past their time budget

G5 is 15 min. G2 + G3 are 45–60 min. G1 + G4 + G6 are 30 min. If a gate consistently runs long, either the prep is weak, the agenda is loose, or you're mixing gate types. Adjust before the next gate.

3. Forgetting to close gates publicly

After every gate, drop a 1-line Slack/Asana note: "G2 closed, theme direction locked, build-out designer can proceed" or "G5 closed, Batch 1 ready for client feedback." This signal unblocks downstream work. Quiet closures stall the next phase.

4. Treating sign-off gates (G1, G4, G6) like pulse-checks

Don't ask the client to "rate" their satisfaction with the brief or the wireframe. These are sign-offs: "Here's the brief + sitemap. Are we locked?" Confident framing, not exploratory.

5. Blurring client vs internal gates

G5 is internal. Don't invite the client to a per-batch QA meeting. Similarly, G6 and G7 are distinct: G6 is client sign-off on the built site, G7 is internal technical validation. Both have to pass before launch, but they're separate gates with separate teams.

Self-check before moving on

• I can name all nine gates and their types (client gate, internal gate, or launch)
• I know which gates use pulse-checks (G2, G3) vs email sign-offs (G1, G4, G6)
• I understand G5 is internal per-batch QA and G6 is client final build sign-off — they're separate
• I know G8 is launch and G9 is production verification within 48 hours
• I can recite my closing signal pattern for each gate: "G[X] closed, [what's locked], [who can proceed]"

The five-step gate pattern (for client-facing gates)

1. Pre-meeting (1–2 days before): Send the client a short, framing comm explaining what they'll see, the time budget, the decision they're making at this gate. Link the pulse-check framing if it's a G2/G3 gate. Use the Strategist Onboarding's module 5 scripts as templates, adapted to your voice.
2. Internal prep (day of, 30 min before the gate): Quick walk-through with strategist + presenting team. Not a rehearsal — a sanity-check: everyone knows their part, materials are loaded, AV works, timing is solid.
3. The gate itself: You handle logistics (recording if needed, timekeeper, managing the flow). Strategist + relevant team present. For G2/G3, don't guide the client toward an answer; let them form their own reaction first.
4. Post-gate (within 30 min): If it's G2 or G3, send the pulse-check artifact immediately. Use the structured format (per-element ratings, gut-reaction words, flag). Set a clear return window (48h for themes, 48–72h for homepages).
5. Capture + close (when pulse-check returns, or immediately for sign-off gates): Read the artifact, capture the decision exactly as the client stated it, drop a 1-line Slack/Asana note: "G2 closed, Theme B + elements from A locked, build-out designer proceeding." This signal unblocks downstream work.

Client comms between gates

Outside of gates, keep comms lean:

• Progress updates: Don't. The Asana board is the status. If the team is on track and the client hasn't asked, there's no update to send.
• Blockers: If something slips a gate by more than a day (theme designers running late on G2 prep, for example), flag to the client immediately with the new date and no drama. One sentence: "Theme presentation moving to Friday to allow more design refinement."
• Change requests: Log them, scope them, and come back with a decision (Module 7). Don't absorb them quietly.
• Client questions between gates: Strategist answers strategic questions. You answer operational questions (schedule, logistics, which format to submit files in). Forward other questions to the strategist.

The pulse-check artifact

For G2 (theme pick): Per-element ratings (0–10 scale) on Big Idea clarity / Visual fit / Tagline resonance / Color palette / Typography / Imagery for EACH theme. Gut-reaction words for each theme. Optional flag for elements that need tweaking.

For G3 (homepage pick): Per-element ratings on Hero / Layout / Copy / Voice / Overall feel for EACH take. Gut-reaction words: Hero / Interaction / Copy / Voice / Overall feel. Return window 48–72h (biggest decision; let them live with both).

Format (same for both): Use the Strategist Onboarding's Module 5 pulse-check template. Distribute as a Google Form or simple table. Collect responses in a shared doc. You read the results and surface the decision to the strategist within 1 hour of the return window closing.

Handling the "we love X but also want Y" hybrid picks

Hybrids are normal. Client says "Theme B + color palette from Theme A + type from Theme C." Don't try to simplify or consolidate. Write down EXACTLY what they said, in their words, within 24 hours of the pulse-check closing. Hand it to the strategist + build-out designer as the brief for the reconciliation session. Some hybrids work mechanically, some don't — the build-out designer will figure it out with strategist guidance, but they need the specificity to start.

Gates as scheduled moments, not surprises

Every gate should hit the calendar on schedule. If a gate slips:

• Slip < 1 day: Notify the client the night before with the new time. No elaborate explanation needed.
• Slip > 1 day: Call the CCO + strategist immediately. This is a project problem, not just a scheduling hiccup. Assess impact to the overall 8-week timeline. Communicate to the client with a narrative ("we're refining the designs to make sure they're ready") rather than just a date slip.

Keeping gates at the right tempo

You're the timekeeper. G2 and G3 should run 45–60 min. If a gate consistently runs 90 min or 120 min, something's wrong — either the prep was weak, the agenda is loose, or scope is bleeding in. After the gate, debrief with the strategist: "We consistently overshoot by 30 min. What's missing from prep?" Then adjust before the next gate.

Self-check before moving on

• I understand the five-step gate pattern for client gates (pre-meeting → internal prep → gate → pulse-check distribution → capture + close)
• I know when to send pulse-checks (G2, G3) and when to just confirm (G1, G4, G6 are email sign-offs)
• I can capture a hybrid pick in the client's own words and hand it off for reconciliation
• I know that gates should NOT have regular progress-update comms between them
• I understand I'm the timekeeper and can push back if a gate chronically runs long

Change request vs pulse feedback

Pulse feedback: "The hero doesn't feel quite right" or "The tagline could be punchier." Client wants refinement within the locked scope. This comes back via pulse-check at a gate. Strategist + team incorporate it before the next phase.

Change request: "Let's add a new product page" or "Can we rebuild the nav in this new way?" or "We realized we need a careers section." New scope. Out of the gates. This requires a decision with the CCO.

The hard case: "Can we make the hero bigger?" might be pulse feedback (visual refinement) or change request (if it requires layout restructuring that ripples to 10 pages). When you're unsure, flag to the CCO. They decide the classification.

Logging and scoping a change request

1. Capture it precisely. Create a task on Asana with the title "CHANGE REQUEST: [description]" in the project's "Decisions" or "Risk Log" section. Write down exactly what the client asked for, in their words.
2. Assess the scope. Walk through with the lead designer + strategist: How many pages? How much content? Design changes, copy changes, or both? CMS implications (does this change how pages are structured in the system)? Estimate hours.
3. Present to the CCO. "Here's the change request, here's the scope estimate. Should we (a) absorb it and slip the timeline by 2 days, (b) pare it down and absorb a smaller version, or (c) push to a follow-on engagement?" CCO decides. You document the decision.
4. Communicate back to the client. Don't go dark. Either: "We've incorporated this into the plan, launching on [new date]" or "This is a follow-on opportunity; let's schedule it for next quarter." Frame it as a business decision, not a technical limitation.

The source/ folder and chase items

Early in Phase 0, the strategist runs punch-content-brief. If a page brief has MISSING SOURCE markers, the skill auto-appends that item to source/_missing.md — your chase list. These are data sheets, product specs, customer lists, compliance docs the client said they'd send but haven't arrived yet. This is your job, not the strategist's. Chase them.

• Week 1: Scan source/_missing.md the moment the brief is done. Email the client's project manager: "We need the ACME product data sheet + customer testimonials by EOD Wednesday so our writer can draft the product pages."
• Non-arrival = escalation. If it's Wednesday 4pm and the file hasn't landed, escalate to the CCO. Don't quietly re-run the brief and let it flag again. That's a project slowdown that the client won't see coming.
• Once it arrives: Drop it in source/[appropriate-subfolder]/ on Google Drive. Post a 1-line Slack note: "source landed: source/products/acme-datasheet.pdf" so the strategist knows to wait 30 seconds for Drive sync before re-running the brief.

Watching for Phase 3 CMS-migration surprises

The Phase 2 CMS pilot (Dev pushing one page through the chosen CMS) is a de-risking step. But late surprises can still appear. Watch for:

• The CMS can't handle the design patterns the site uses. Example: the site has a sticky sidebar that the CMS's template engine doesn't support. This comes out in Phase 3 when Dev starts the full migration. If it's a BLOCKER, you have to either (a) patch the CMS, (b) redesign the site to fit the CMS, or (c) delay launch. Flag this immediately to the CCO — this is a timeline decision.
• Custom field structures aren't mapped correctly. Example: product pages have a "related products" field that should auto-link to other product pages, but the CMS integration didn't set up the relationship properly. Log it, estimate the fix effort, decide with CCO whether to absorb (delay) or push to follow-on.
• Performance issues on the CMS version. The static preview runs fast, but the CMS version is slow because of database queries. Log as a risk, estimate the fix, decide with CCO.

Any CMS issue that emerges in Phase 3 is logged as a "Post-launch Follow-on" item — you do NOT hold the launch for it unless it's a BLOCKER (site is down, forms don't work, redirects are broken). Everything else gets documented and scheduled for post-launch remediation within a week.

Risk logging for the post-launch retro

Throughout the project, when something slips or causes friction, log it. Create a task "RISK: [what happened]" in the Risk Log section. Three categories:

• Scope slip: "Client added 2 pages mid-Phase-2, cost us 1.5 days." Log the impact and whether it was absorbed or moved the launch date.
• Process friction: "Theme designers needed more time for G2 because the brief was unclear." Log so we refine Phase 0 briefing in the next project.
• Technical surprise: "CMS integration revealed late that custom fields need per-instance configuration; added 6 hours in Phase 3." Log so we build it into the CMS pilot next time.

Don't just log; reflect on root cause. These go into the post-launch retro (Module 8) where you run a blameless debrief and capture the learning.

Self-check before moving on

• I can distinguish pulse feedback ("refinement within scope") from a change request ("new scope")
• I know the four steps for logging and scoping a change request
• I own chasing source/_missing.md items and understand this is my job, not the strategist's
• I watch for CMS-migration surprises in Phase 3 and log them as "Post-launch Follow-on" unless they're BLOCKERS
• I log risks throughout the project and use them to fuel the post-launch retro

G9 — Production verification (within 48 hours of G8 launch)

Who: TDM + Production. You track completion on Asana.
What to verify:

• All pages load without errors (500s, redirects broken, missing assets)
• Forms submit and trigger expected behaviors (email captures, Zapier integrations, webhook calls)
• Analytics tags fire (Google Analytics, heat mapping, event tracking)
• Third-party integrations work (Mailchimp signups, calendar syncs, API calls to external services)
• Search functionality works if applicable
• Redirects from old site to new site work (301s, not 404s)
• Mobile responsive on actual devices, not just the browser preview

If issues are found: Hotfix immediately if critical (forms broken, pages down). Otherwise, log as "Post-launch Follow-on" and schedule for same-week remediation. Document what was found so the retro can capture it.

The post-launch retrospective

Schedule: ~2 weeks after G8. By then, the dust has settled and you have perspective.
Attendees: PM (you) + strategist + lead designer + writer + dev lead + TDM. Client is NOT invited.
Format: Blameless. No one messed up. Instead: "What worked really well?" and "Where did we feel friction?"

Structure (90 min)

1. Wins (20 min): Go around the room. Each person names one thing that went smoothly. Capture 5–7 wins. This isn't fluff — it's recognizing what the system does well.
2. Friction (30 min): Go through the Risk Log you built throughout the project. Discuss each friction point. Root cause: Was it a process gap? A tool gap? Did the brief not land sharply? Did someone need more time to learn the system?
3. Learnings (25 min): For each friction point, what changes to make next project? Be specific. Example: "The brief took too long. Next time, we allocate an extra 2 days for the strategist to digest the discovery materials before drafting." Or: "Theme designer mid-week check-ins caught convergence issues early. Keep doing this."
4. Document (15 min): You write a 1-page summary: project name, date, 3–5 wins, 3–5 learnings, owners of the learnings. Archive it in the Punch Docs project folder for reference by future projects.

The retro is NOT a blame session or a performance review. It's an engineering meeting: "How do we refine the system so the next 8 weeks runs even smoother?"

PM quick-reference card

Gate checklist:

Task ownership at a glance:

Who to ask for what (common scenarios):

• Brief isn't sharp enough / strategist is stuck: Ask CCO + strategist for a working session. Don't absorb the delay; push Phase 0 timeline.
• A designer is running late on their deliverable: Ask them directly first: "What do you need?" (scope clarity, stakeholder feedback, more time?). Escalate to CCO only if it impacts a gate.
• Copy wasn't delivered on time for a batch: Ask the Primary Writer's manager or the strategist (strategist owns copy QA). Push the batch timeline if needed.
• Client can't make a gate meeting: Reschedule. Don't run a gate without the client present on a client-facing gate (G1, G2, G3, G4, G6).
• A change request came in: Log it. Walk it with the CCO. Don't absorb it without a decision.
• A CMS issue emerges in Phase 3: Ask Dev + TDM if it's a BLOCKER. If not, log as "Post-launch Follow-on." If yes, escalate to CCO for launch decision.

Self-check before moving on

• I know G9 is the production verification checklist (forms, analytics, integrations, redirects) within 48 hours of launch
• I can facilitate a blameless retro: wins, friction, learnings, document for next project
• I have the nine gates memorized (when, client yes/no, what decision, what's next)
• I know who owns what and can ask the right person for help (brief → strategist, design → lead designer, copy → primary writer, etc.)
• I understand a change request is logged + scoped + decided with CCO, never quietly absorbed