BootcampCapstone · Deliverable 3

Go-to-Market Launch Plan

Builds on Topic 5.

What you'll produce

A go-to-market (GTM) launch brief for Tempo's new AI-assisted capacity-forecasting feature — the single document that turns positioning into a coordinated launch. It names the target audience and the one-line value prop, picks a channel mix matched to where your ICP actually is (not where it's easy to post), sets pricing and timing, lays out a before/during/after timeline with a named owner on every row, spells out the cross-functional coordination plan across product, sales, and support, and defines success metrics in advance plus a launch-day announcement plan. This is the artifact that separates a PMM from a "marketer who makes assets": owning the GTM plan and getting product, sales, and support to execute one story on one timeline is the signature skill the role is hired for (Topic 5). It also de-risks the founders' bet — a great feature with a sloppy launch is a tragedy, and this brief is how you prevent that. It builds directly on your ICP (Deliverable 1) and your positioning and message pillars (Deliverable 2): every line of copy here should trace back to that source of truth.

Instructions

  1. Anchor the audience and the one-line value prop. Reuse your ICP from Deliverable 1 — don't re-derive it. State who this launch is for in one sentence (segment + the job-to-be-done it serves), then write the launch's single value proposition as a benefit, not a feature. Test it: if you swapped "AI" for "magic" and the sentence still sounds the same as every competitor, rewrite it until it says something only Tempo can say.
  2. Decide the launch tier and packaging — on top of Tempo's real price. First pick the launch size honestly: GA splash vs. phased beta. Then decide how the AI forecast is sold. Start from the canonical pricing fact in the capstone brief — Tempo is one flat plan at $12/seat/month, and the AI feature ships bundled into it at launch — and don't quietly invent new tiers or numbers; the one-pager (Deliverable 4) and the channel economics (Deliverable 6) inherit these exact figures, so anything you change here you must change there too. Bundling-into-the-flat-plan is the default and usually the right call for a few-hundred-team base with no marketing engine (the launch's job is activation and switching, not ARPU). If you instead argue for a paid add-on or a future premium tier, that is your invention, not a brief fact: say so explicitly, give it an exact name and price, justify it against the launch goal, and carry that same name and price unchanged into Deliverables 4 and 6 — a tier that appears here and vanishes later is exactly the broken-thread mistake the capstone warns against. Packaging is a GTM decision, not just a pricing one: it shapes the message and the metric.
  3. Build the channel mix from the ICP, then cut it. List every channel where your ICP actually spends attention (Topic 5: SEO, content, email, in-product, social, sales-led, partnerships, communities). For each, write one line: why this channel reaches this ICP. Then cut to 3–4 — a focused launch beats a thin one spread across eight channels. Name the hero channel.
  4. Write the message into each channel. Don't reuse one sentence everywhere. Take your three message pillars from Deliverable 2 and tailor the angle per channel and audience (existing customers hear "you just got an upgrade"; prospects hear "here's why to switch"). One consistent story, channel-appropriate words.
  5. Lay out a before/during/after timeline with owners. Use real dates relative to a launch day (T-minus weeks → launch day → T-plus weeks). Every row gets a single accountable owner (PMM, Product, Sales, Support, Founder/CEO) and a concrete deliverable. "Before" = build assets and brief teams; "During" = the coordinated announcement; "After" = measure, gather feedback, sustain.
  6. Write the cross-functional coordination plan. State explicitly what Product owns (the feature is on, docs ready), what Sales needs (battlecard, talk track, demo — note this is built in Deliverable 4), and what Support needs (known-issues doc, escalation path, who to ping). Name the go/no-go gate and who calls it.
  7. Define success metrics up front — before launch, not after. Pick a primary launch metric tied to the business goal (e.g., feature activation among the ICP, or trial-to-paid lift), plus 2–3 secondary metrics, plus one counter-metric (a guardrail that tells you the launch is hurting something — churn, support load, refunds). Put a number on each where you can.
  8. Write the launch-day announcement plan. Spell out exactly what goes live on launch day, in what order, on which channel, by what time, owned by whom — the in-app message, the email, the blog post, the social posts, the sales outreach. This is the "everything lands at once" coordination Topic 5 calls for.
  9. State your top risk and the rollback. One sentence: the most likely way this launch goes wrong, and what you'd do about it (pause rollout, hold the email, hotfix). Honesty here is a senior signal.

Worked example

(Feature: Tempo AI Capacity Forecast — predicts which team members will be over- or under-booked in the next 2–6 weeks, based on logged time and pipeline. Builds on the ICP and positioning from Deliverables 1–2.)

1. Target audience & one-line value prop

  • Who this launch is for: Owners and operations/resourcing leads at creative agencies of 10–50 people who already use Tempo to track time — the people whose actual job-to-be-done is "tell me on Monday who's about to be slammed or idle, before it becomes a fire." (Primary: existing paying admins. Secondary: prospects currently on Toggl/Harvest or a spreadsheet.)
  • Value prop (one line): "Tempo now sees the crunch coming — AI capacity forecasting tells you who'll be over- or under-booked two to six weeks out, so you can rebalance before deadlines slip."
  • Why this passes the swap test: Toggl and Harvest report on hours already logged (the past). Tempo's differentiator from Deliverable 1's SWOT is forward-looking, agency-shaped capacity — "sees the crunch coming" is a claim incumbents structurally can't make, because they're built for invoicing, not resourcing.

2. Launch tier & packaging

  • Launch tier: Phased GA. Beta to ~40 friendly accounts in T-4 to T-1 (de-risk the forecast accuracy and gather quotes), then a coordinated public GA on launch day. Not a silent ship — this is the marquee feature the founders hired the function for, and existing customers should feel it as an upgrade.
  • Packaging (using the brief's canonical price): Tempo is one flat plan at $12/seat/month, and per the capstone brief the AI forecast ships bundled into that plan at launch — included for every current customer at no extra charge. Why bundle, not charge: with 300 teams and no marketing engine, the launch's job is activation, advocacy, and competitive switching, not squeezing ARPU — and a paywall on the marquee feature would suppress exactly the activation we're measuring. For prospects, the forecast becomes the headline reason to pick Tempo over the cheaper Toggl/Harvest entry tiers ($9–11/seat): we're deliberately not the cheapest, and "sees the crunch coming" is what justifies the gap.
  • The one number that flows downstream: ARPA = $12 × ~18 seats ≈ $216/team/mo ≈ $2,592/yr. Deliverable 4's one-pager and Deliverable 6's channel economics both use these exact figures — keep them identical across all three.
  • A future paid tier is a proposal, not a brief fact — and I'm flagging it as mine. I'd revisit monetization in Q+1 once usage data exists: a "Tempo Forecast+" add-on at $4/seat/month for advanced scenario modeling (what-if staffing, multi-month horizons), keeping the base forecast free. This name and price are my invention, not given by the scenario — so if I commit to it, it must appear with this exact name ("Forecast+") and price ($4/seat) in Deliverable 4's roadmap line and Deliverable 6's NRR/expansion assumptions, or it doesn't belong here at all. (The launch itself ships no new tier; this is a flagged future bet, decided after the data lands — see the T+4 timeline row.)

3. Channel mix (cut to 4; hero = in-product + lifecycle email)

ChannelWhy it reaches this ICPRole in launch
In-product announcement (banner + tooltip on the dashboard)Admins are already logging in weekly; this is the cheapest, highest-intent surface we ownHero — drives existing-customer activation
Lifecycle email to all adminsDirect line to the exact buyer; segmented (active vs. dormant)Hero — the launch-day "you just got an upgrade" moment
SEO blog/guide targeting "how to manage agency capacity / avoid overbooking designers"Prospects Google this exact pain; compounding, fits a no-paid-budget startup (Topic 5)Acquisition + sales enablement asset
Founder-led LinkedIn + 2 agency-ops communities (e.g., Bureau of Digital, r/agency)Agency owners cluster there and trust peer/founder voices over adsAwareness + advocacy, prospect reach

Cut on purpose: paid ads (no budget, ICP too niche for efficient targeting), Twitter/X (audience isn't there), and a press push (premature for a feature launch at this size). Better to win four channels than dilute across eight.

4. Message tailored per channel (from Deliverable 2's three pillars)

  • Pillar "See the crunch coming"In-product: "New: your team's next 6 weeks, forecast. See who's about to be overbooked." → Email subject: "Tempo now predicts who'll be slammed next month."
  • Pillar "Built for agencies, not accountants"Blog/SEO: a genuinely useful guide, "The agency owner's guide to spotting overbooked designers before deadlines slip" (help, don't sell). → Prospect email/LinkedIn: "Toggl tells you where the hours went. Tempo tells you where they're going."
  • Pillar "No new spreadsheet, no setup"In-product tooltip: "Already on — it forecasts from the time you're already tracking." → Community post: "We shipped AI forecasting that needs zero setup if you already log time in Tempo."

5. Before / During / After timeline (with owners)

WhenActivityOwnerDeliverable / definition of done
T-4 wksOpen private beta to 40 accounts; instrument forecast-view + accuracy loggingProduct40 accounts live, telemetry firing
T-3 wksCollect 3–4 customer quotes + 1 mini case study from betaPMMQuotes approved for public use
T-3 wksLock positioning, value prop, all launch copy (from Deliverable 2)PMMCopy doc signed off by CEO
T-2 wksBuild assets: in-product banner, 2 emails, blog/guide, LinkedIn postsPMMAll assets drafted + reviewed
T-2 wksBuild sales battlecard, demo script, one-pager (this is Deliverable 4)PMM + SalesSales kit ready, dry-run booked
T-1 wkBrief & train the 2-person sales team; brief Support on known issuesPMMSales can demo unaided; Support has FAQ + escalation path
T-1 wkSchedule all sends/posts; final QA of feature flag + analyticsProduct + PMMEverything queued; go/no-go checklist green
T-0 Launch dayCoordinated announcement (see §8)PMM (coordinator)All channels live by noon
T+2 daysFirst metrics read; triage support tickets; hotfix copy if neededPMM + SupportDay-2 dashboard reviewed
T+1 wkSales outreach to warm prospects citing the feature; publish case studySales + PMMOutreach sequence sent
T+2 wksLaunch retro: metrics vs. targets, what to double down onPMMHonest recap shared with founders + team
T+4 wksDecide on the proposed "Forecast+" add-on ($4/seat, my invention — see §2) based on usage dataPMM + FoundersGo/no-go on monetization; if yes, the same name + price flow into D4 and D6

6. Cross-functional coordination plan

  • Product owns: feature behind a flag, ramped to 100% of the (single, flat-$12) plan on T-0 — it's bundled for everyone, no tier gate; forecast accuracy acceptable in beta; in-app help docs published; analytics events firing (forecast viewed, action taken).
  • Sales (2 people) needs: the battlecard vs. Toggl/Harvest with objection handling, a 5-minute demo script, the one-pager, and a list of warm prospects to re-engage — all delivered and rehearsed by T-1 wk (built in Deliverable 4).
  • Support needs: a known-issues + FAQ doc ("Why is my forecast different from my plan?"), an escalation path to Product, and a heads-up that ticket volume may rise in week 1.
  • Go/no-go gate: T-1 wk checklist meeting; the CEO calls go/no-go. Blockers = forecast accuracy below the beta bar, analytics not firing, or sales not demo-ready.

7. Success metrics (defined now, before launch)

  • Primary: 40% of active agency admins view a forecast within 14 days of launch, and 20% take a rebalancing action (the activation event that proves the feature is used, not just seen). Ties to the retention/advocacy goal.
  • Secondary: (a) Trial-to-paid conversion lift of +3 pts for new signups who see the feature in onboarding; (b) 500 organic visits to the SEO guide in month 1; (c) 4+ usable customer quotes/testimonials generated.
  • Counter-metric (guardrail): support tickets per 100 accounts must not rise more than 15%, and paid churn must not increase — if forecasts confuse or mislead, the launch is net-negative even if activation looks good. Watched daily for the first two weeks.

8. Launch-day announcement plan (everything lands at once)

Time (launch day)What goes liveChannelOwner
9:00Feature flag → 100% for paid plans; in-product banner + tooltip onProductProduct
10:00Launch email #1 to active admins: "Your team's next 6 weeks, forecast."EmailPMM
10:00Blog/guide published + linked in email and bannerWeb/SEOPMM
11:00Founder LinkedIn post + 2 community postsSocialFounder + PMM
12:00Sales begins warm-prospect outreach citing the featureSalesSales
16:00Day-1 metrics + support sentiment check; hold or proceed with day-2 email to dormant adminsSlack war-roomPMM

9. Top risk & rollback

  • Biggest risk: the forecast is visibly wrong for some agencies (lumpy data, project-based work), eroding trust on day one. Rollback: the feature is flagged, so we can dial it back to beta-only instantly; we hold the day-2 dormant-admin email until day-1 accuracy sentiment is green; Support escalates accuracy complaints straight to Product with the account attached.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

  • Audience & benefit-led value prop — 1: vague "everyone" or a feature dump · 2: clear ICP + a one-line benefit · 3: sharp ICP tied to the job-to-be-done and a value prop only Tempo could honestly claim (passes the swap test, traces to Deliverable 1–2).
  • Pricing & packaging decision (built on the brief's price, not invented) — 1: not addressed, or invents a price/tier that contradicts the brief's flat $12 plan and the figures D4/D6 use · 2: states bundle/add-on/tier using the canonical $12 plan · 3: picks packaging on top of the real $12 price, justifies it against the launch goal (activation/advocacy vs. revenue), and if it proposes any future tier, labels that as the learner's own invention with an exact name + price committed to carry into Deliverables 4 and 6.
  • Channel mix matched to the ICP — 1: random or "all channels" · 2: 3–4 reasonable channels · 3: focused mix, each justified by where the ICP actually is, with a named hero channel and deliberate cuts.
  • Message tailored per channel — 1: one generic line everywhere · 2: channel-appropriate copy · 3: consistent story drawn from the message pillars, re-angled for existing customers vs. prospects per channel.
  • Before/during/after timeline with owners — 1: no timeline or no owners · 2: phased plan with some owners · 3: dated rows, a single accountable owner each, concrete done-criteria across all three phases.
  • Cross-functional coordination plan — 1: marketing-only · 2: names what product/sales/support do · 3: explicit hand-offs, a sales-enablement dependency, a go/no-go gate, and who calls it.
  • Success metrics defined up front — 1: missing or measured after the fact · 2: names a primary metric · 3: primary + secondary + a counter-metric guardrail, with numbers, set before launch.
  • Launch-day announcement plan — 1: a single post · 2: lists the channels · 3: a sequenced, timed, owned plan so the message lands everywhere at once, plus a stated top risk and rollback.