Stage briefs — LAND (Prospecting → Discovery call → Discovery Audit)¶

Before designing any asset here, read ../00-business-primer.md and ../01-brand-system.md. Every brief below assumes that context (the compliance-claim rule, the palette, the semantic pass/warn/fail trio, the tone).

Assets in this file: PA01–PA09. This is the highest-leverage cluster — the wedge that converts cold prospects into paying clients. Weight design investment here.

Each brief follows the same shape: Stage · Audience · Job-to-be-done · Format & spec · Source content · Content outline · Design direction · Priority · Depends on · State.

PA01 — Website / landing page¶

Stage: 1 Prospecting (also the destination of every other asset's CTA).
Audience: cold prospect (founder / CTO / first security or platform engineer) who clicked a link from an email, LinkedIn, or one-pager.
Job-to-be-done: in 30 seconds, make a technical, skeptical buyer understand what SnowOps does, believe it's credible, and click "Start with a free Discovery Audit."
Format & spec: responsive marketing site. Start with a single long landing page + a Discovery Audit CTA/booking page. Must be fast, clean, and mobile-friendly. Self-contained (no heavy frameworks needed for v1).
Source content: Y1-positioning-messaging.md (all copy), the Y8 one-pagers (section content), Y2-pricing-packaging.md (packages).
Content outline (sections, top to bottom):
Hero — one-liner ("Audit-ready cloud platforms, engineered — not bolted on"), sub-line (problem→outcome), primary CTA "Start with a free Discovery Audit."
The wedge — the category line as a bold statement ("Vanta tells you what's broken…").
The problem — click-ops → audit fire drill (primer §3).
Why the usual fixes fall short — vCISO / first hire / Vanta-alone (3 cards).
What "compliant by construction" means — the 5 mechanisms (identity-over-secrets, least privilege, policy-as-code, encryption+logging, evidence-as-code).
How we deliver — module-driven + GitOps; "everything is code you own."
The packages — the expansion ladder (Audit → QW → Baseline → Advanced).
Proof — "everything is code, tested, no black box"; sample audit / case study when available.
Final CTA — free Discovery Audit, with the "how it's safe / read-only" reassurance.
Design direction: developer-infra aesthetic (Vercel/Linear/Stripe-docs polish). Dark hero option is on-brand. Use the crystalline/lattice motif subtly. Real code snippets and a diagram are credibility, not clutter. Keep it fast and restrained — a technical buyer distrusts a bloated marketing site.
Priority: P0 · Depends on: PA00. · State: ⬜

PA02 — LinkedIn presence kit¶

Stage: 1 Prospecting (founder-led social selling is a primary channel).
Audience: prospects and referrers browsing the SnowOps company page or the founders' profiles.
Job-to-be-done: make the founders' and company's LinkedIn presence look credible and on-message at a glance, and give them reusable post templates so they can publish consistently.
Format & spec:
Company page banner 1128×191 px.
Founder profile banners (Sagar, Nidhi) 1584×396 px.
A set of post/carousel templates (1080×1080 and 1080×1350) for: the category line, a proof point, a "compliant by construction" explainer, a mini case study.
Source content: Y1 (one-liner, category line, proof pillars), Y4-cold-outreach-kit.md (hooks).
Content outline: banners carry the one-liner + mark; post templates are a themed family (consistent header, footer with mark, one idea per post).
Design direction: consistent with PA00; templates should be editable (leave text zones obvious). Keep them clean and quote-forward — the idea is the hero, not decoration.
Priority: P1 · Depends on: PA00. · State: ⬜

PA03 — Email signature + cold-email formatting¶

Stage: 1 Prospecting (cold outbound is the core motion).
Audience: cold prospects receiving founder-sent email.
Job-to-be-done: make outbound email look like it's from a credible specialist firm (not a spam blast), and give a clean, clickable path to the audit.
Format & spec: an HTML email signature (mark + name/role + one-liner + audit CTA link) and a light formatting convention for the cold-email body (the words come from Y4; this is about restraint — plain, personal, well-spaced, one clear CTA, not a heavy HTML template that trips spam filters).
Source content: Y4-cold-outreach-kit.md (email copy, sequences).
Design direction: signatures render reliably across clients (table-based HTML, no external CSS, small logo). Cold emails should look written by a person, not designed — the "design" is deliberately minimal. Provide dark-mode-safe colors.
Priority: P1 · Depends on: PA00. · State: ⬜

PA04 — Solution one-pagers (Discovery Audit / Baseline / Advanced) ⭐¶

Stage: 1 Prospecting & 2 Discovery call (leave-behind / attachment).
Audience: a prospect evaluating whether to take the next step; often forwarded internally to a colleague or a boss.
Job-to-be-done: on a single page, explain one offer clearly enough that a busy technical buyer "gets it" and that it survives being forwarded without a human to narrate it.
Format & spec: three one-page PDFs (A4 + Letter), also usable as web sections. One per offer: Discovery Audit, Baseline "Cloud Secure," Advanced "Certification-Ready."
Source content: one-pager-discovery-audit.md, one-pager-baseline.md, one-pager-advanced.md — copy is already written; do not rewrite claims.
Content outline (Discovery Audit one-pager, as the model): headline · sub-head · "What you get" (branded PDF across network/identity/encryption/logging/cost; findings ranked & mapped to fixes; roadmap; 30-min walkthrough) · "What it costs you" ($0 / ~20 min / read-only) · "How it's safe" (Reader+Security-Reader only, time-boxed, immutable log, human review) · "How it works" (3 steps) · CTA.
Design direction: dense but scannable — this is a technical buyer's favorite format. Use the finding-chip component and semantic trio in the audit one-pager. Consistent header/footer family across all three so the ladder reads visually (Audit → Baseline → Advanced should feel like a progression). Confidential? No — these are marketing collateral, freely shareable.
Priority: P0 · Depends on: PA00. · State: 🟨 (content ready)

PA05 — Vertical one-pagers (SaaS / FinTech / HealthTech)¶

Stage: 1 Prospecting (matched to the account's industry).
Audience: prospects in a specific vertical; the value prop is reframed for their trigger (enterprise questionnaire / bank diligence / BAA).
Job-to-be-done: show a vertical prospect "we understand your specific compliance pressure."
Format & spec: three one-page PDFs mirroring PA04's system.
Source content: one-pager-vertical-saas.md, one-pager-vertical-fintech.md, one-pager-vertical-healthtech.md, plus per-ICP value props in Y1 §5.
⚠️ Compliance-claim caution (from Nidhi's review note in Y1): FinTech & HealthTech one-pagers reference advanced controls that are largely roadmap. Any control not yet shipped must carry the visible (roadmap) tag. Do not imply the full FinTech/Healthcare posture is deployable today. Nidhi gates these two.
Design direction: same template family as PA04; a subtle per-vertical accent is fine, but keep the brand dominant. Make the (roadmap) tag unmissable where used.
Priority: P1 · Depends on: PA00, PA04. · State: 🟨 (content ready)

PA06 — Capabilities deck (12 slides) ⭐¶

Stage: 2 Discovery call (presented live and/or sent as follow-up).
Audience: the prospect and anyone they loop in; used to walk through the SnowOps story on a call.
Job-to-be-done: carry the full narrative (problem → wedge → mechanism → proof → packages → CTA) in a tight, credible deck that ends on "book the free audit."
Format & spec: ≤12-slide deck, 16:9, delivered as PDF + editable source (Google Slides / PPTX / Gamma). Must also read well as a leave-behind (no narrator).
Source content: deck-outline.md — the slide-by-slide copy already exists; design it, don't rewrite it.
Content outline (the 12 slides): 1 Title · 2 The problem · 3 Why usual fixes fall short · 4 The wedge (category line) · 5 What "compliant by construction" means · 6 How we deliver · 7 Proof · 8 The packages (expansion ladder) · 9 Compliance coverage (insert Y7 summary table) · 10 Reference architecture (insert Z1 diagram + BOM) · 11 Pricing · 12 Call to action.
Design direction: one idea per slide, generous whitespace, the category line (slide 4) as a full-bleed statement. Slides 9–10 are data/diagram slides — reuse the PA12 coverage-matrix and PA13 reference-architecture visuals so the brand is consistent across assets. Speaker-notes layer for live delivery. Dark or light master both acceptable; pick one and commit.
Priority: P0 · Depends on: PA00 (and ideally PA12, PA13 for slides 9–10). · State: 🟨 (content ready)

PA07 — Discovery-call agenda / leave-behind¶

Stage: 2 Discovery call.
Audience: the prospect, before/after the call.
Job-to-be-done: set a crisp agenda (respect the buyer's time), and leave behind a one-page summary + the audit offer.
Format & spec: one-page PDF — agenda (what we'll cover, ~30 min), what SnowOps will need to run the free audit, and the CTA.
Source content: Y5-discovery-script.md (call structure, qualification), audit "how it works" steps from PA04.
Design direction: simple, professional, uses the document master. Low design effort — this is a courtesy artifact.
Priority: P2 · Depends on: PA00. · State: 🟨 (content ready)

PA08 — Discovery Audit report (branded) ⭐⭐ THE WEDGE¶

Stage: 3 Discovery Audit — the single most important presentable asset in the business. It is the free deliverable that proves value and converts prospects.
Audience: the prospect's technical decision-maker (and whoever they escalate to). Often the first tangible thing SnowOps hands over — it is the proof.
Job-to-be-done: show a prospect exactly where their Azure platform stands against SOC 2 / ISO 27001, with every gap ranked and mapped to a fix — so credibly and clearly that the obvious next step is to hire SnowOps to fix it.
Format & spec: multi-page branded report, delivered as PDF (and/or self-contained HTML). Generated by apps/discovery-auditor/: the tool collects read-only Azure data, evaluates it against a rule pack, and renders Markdown → branded PDF via Pandoc (asset G3, src/render/). Your design job is the template/theme that renders behind that pipeline (Pandoc HTML/CSS or LaTeX template, or an HTML report theme), not a hand-made one-off — it must work on generated content of variable length.
Source content / data model: the auditor scans Resource Graph, Defender, Azure Policy, AAD audit, Cost Management (G1 collectors) and produces findings evaluated by a YAML rule pack mapped to SOC 2 / ISO 27001 / CIS Azure (G2). Each finding has a severity and a mapped remediation (remediation_asset_id). Look at apps/discovery-auditor/rules/ and src/render/ for the exact fields before theming.
Content outline (report sections):
Cover — "Cloud Posture Discovery Audit," Confidential — prepared for ⟨Client⟩, date, audit window/expiry, SnowOps mark.
Executive summary — an overall posture read + headline counts (critical/high/medium), in plain language a founder can forward to a board.
Scope & method — what was scanned, read-only assurance, the safety contract (Reader + Security Reader only, time-boxed, immutable log, human-reviewed).
Findings by domain — network, identity, encryption, logging, cost. Each finding: title, severity chip, what/why, the mapped remediation + effort estimate, and the framework control it maps to (SOC 2 / ISO / CIS).
Prioritized remediation roadmap — the path from "where you are" to "audit-ready," grouped by effort/impact.
What SnowOps would do next — soft bridge to the Baseline engagement.
Design direction: this must look like a senior security firm's audit report — clean, dense, trustworthy, print-perfect. The semantic trio (green/amber/red) and finding-chip component are load-bearing here. Severity must be legible in grayscale (icon + label, not color alone). Confidentiality treatment on every page footer. A summary "posture" visual (e.g., a domain-by-domain status grid) up front. Consistency with the sample audit (PA09) — they are the same template.
Compliance-claim note: the report maps findings to framework controls but must not state the client "is" or "will be" certified. Language is "aligned to / gaps against SOC 2 CC…". Human review before delivery is a hard contract (G4) — bake a reviewer-friendly layout.
Priority: P0 (highest) · Depends on: PA00; coordinate with the apps/discovery-auditor G3 render pipeline. · State: 🟨 (pipeline exists; needs a designed theme)

PA09 — Sanitized sample audit¶

Stage: 3 Discovery Audit (used before the prospect's own audit — as pre-sales proof).
Audience: prospects deciding whether to grant access for their own audit; skeptics who want to see the deliverable first.
Job-to-be-done: show "here's exactly what you'll get" using a realistic, fully-anonymized example — removing the risk of granting access to an unknown vendor.
Format & spec: the same template as PA08, populated with the sanitized sample data. Multi-page PDF, freely shareable (no real client data).
Source content: sanitized-sample-audit.md.
Design direction: identical system to PA08 — this is PA08's template with safe demo content, so producing PA08's theme produces this for free. Mark it clearly as a sample / illustrative so it's never mistaken for a real client's posture.
Priority: P0 · Depends on: PA08. · State: 🟨 (content ready)

Stage-1 sequencing note¶

Produce in this order: PA00 → PA08 (+PA09 free with it) → PA06 → PA04 → PA01, then PA05/PA02/PA03/PA07 as capacity allows. The audit report and the deck are what actually win the deal.