Go-to-Market Plan skill for Codex

A GTM plan is done well when the launch size matches the change’s importance, one segment and one core message are chosen deliberately, every function (product, marketing, sales, support, legal) has named tasks with dates, the launch can be paused or rolled back, and success is measured against targets set before launch.

Tier the launch first

Tier	What qualifies	Typical motion	Lead time
1 - Major	New product, new pricing, enters a new segment, big competitive move	Press/analysts, event or livestream, campaign, sales training, website update	8-12 weeks
2 - Significant	Major feature that changes why people buy or upgrade	Blog, email to segment, in-app announcement, sales one-pager, demo	3-6 weeks
3 - Minor	Improvements existing users notice	Changelog, in-app tooltip, help doc	1-2 weeks
4 - Silent	Fixes, internal changes, gradual rollouts	Release notes only	None

Over-tiering exhausts the team and trains customers to ignore announcements. If the feature does not change a buying or upgrade decision, it is not Tier 1.

Strategy section

1. Target segment / ICP. Who is this launch for first? Firmographics, role, trigger events, current alternative. One primary segment; secondary segments get a lighter motion.
2. Problem and proof. The pain in the customer’s words, backed by research ($customer-interviews, $jobs-to-be-done).
3. Positioning statement (internal, not copy):

For <segment> who <need/trigger>, <product> is a <category> that <key benefit>.
Unlike <primary alternative>, it <key differentiator>, proven by <evidence>.

4. Messaging hierarchy: one headline message, three supporting pillars, each with a proof point (customer quote, metric, demo moment). Copy for landing pages and ads is written from this ($landing-page-copy, $ad-copy).
5. Pricing and packaging: which plans get it, any add-on price, trial or beta access. Decisions come from $pricing-strategy; record them here.
6. Competitive response: how sales should answer “how is this different from X”; facts only, no disparagement.

Channel plan

Channel	Audience	Asset	Owner	Date
In-app announcement	Active users in target plans	Modal or banner + docs link	Product	Launch day
Email	Segment list, opted-in only	Launch email	Lifecycle	Launch day +0
Blog / changelog	All	Post with demo GIF	Content	Launch day
Sales	Open opportunities in segment	One-pager, demo script, talk track	PMM	Launch -1 week
Community launch (Product Hunt, HN)	Developers / early adopters	See $product-launch	Marketing	Chosen day
Partners	Integration partners	Co-marketing note	Partnerships	Launch +1 week

Only channels with an owner and an asset are in the plan; aspirational channels go to a “later” list.

Enablement

• Sales: one-pager, demo script, objection handling, pricing FAQ, which deals to target first. Train before launch day, not after.
• Support: help articles, known limitations, escalation path, macros ($customer-support-macros), internal FAQ. Support sees the feature in staging first.
• Customer success: list of accounts to proactively contact and talking points.

Readiness checklist

- [ ] Feature complete and behind a flag; rollback tested
- [ ] Pricing, plan entitlements and billing configured and verified in staging
- [ ] Docs, help center, changelog and release notes drafted (see $release-notes)
- [ ] Website/pricing page updates staged
- [ ] Sales and support trained; FAQ published internally
- [ ] Analytics events live; launch dashboard built
- [ ] Legal/compliance review of claims, terms, data processing changes
- [ ] Email lists and in-app targeting verified (consent, segments)
- [ ] Launch-day runbook with owners and a go/no-go meeting
- [ ] Status page and incident contact ready for Tier 1-2

Launch-day runbook

T-24h  go/no-go: readiness checklist reviewed; any red item = slip, not skip
T-0    flag ramp to target cohorts (e.g. 10% -> 50% -> 100% over the day)
T+0    publish blog/changelog; send email; enable in-app announcement
T+2h   check error rates, support queue, conversion events; owner on call
T+24h  review metrics and feedback; decide on continuing ramp or pausing

Publishing posts, sending emails, posting to communities and turning on flags for customers are outward-facing actions. Codex prepares drafts, checklists and commands; the user confirms each publish, send or production change explicitly.

Success metrics

Set before launch, in three layers:

Layer	Example	Review
Awareness / reach	Announcement views, email open and click rate	Day 7
Adoption	% of target accounts using the feature 3+ times in 30 days	Day 30
Business	Upgrades attributed, pipeline influenced, retention change in adopters	Day 60-90

Pair with guardrails: support ticket volume, error rate, refund or downgrade rate. Retrospective at day 30: what worked, what did not, what to change for the next launch.

Output template

# GTM plan: <launch name> (Tier <n>)
Launch date: <date or window> | DRI: <name> | Status: draft
## Summary (what, who, why now)
## Target segment and ICP
## Positioning statement and messaging hierarchy
## Pricing and packaging
## Channel plan (table)
## Enablement (sales, support, CS)
## Readiness checklist (owners and dates)
## Launch-day runbook
## Success metrics and guardrails
## Risks and mitigations
## Open decisions

Gotchas

• Messaging written by listing features (“now with X, Y, Z”) instead of the customer’s problem and outcome lands with no one.
• Launching to all customers at once removes the chance to catch problems; ramp flags.
• Sales trained after launch day sells the old product for weeks.
• Never claim metrics, customer names or quotes in launch materials without permission and verification.
• Emailing contacts who did not opt in creates legal and deliverability problems; check consent before building the list.

Verification

Check the tier matches the qualifying criteria, every channel and checklist row has an owner and a date, success metrics have targets and data sources set before launch, the runbook includes a rollback or pause step, and every outward-facing action is marked for explicit approval.