Most launch checklists are written for one kind of launch and then stretched to cover everything, which is why half the rows never apply and the other half get skipped. This one distinguishes three launch types up front, and tags every item by which ones it applies to.

Those three colours carry through every table that follows. A row tagged ALL applies whatever you are shipping; the others apply only to their own type.

This is the operational back half of a launch. The strategic front half — why you’re launching and what you’re saying — lives in The Positioning Loop’s Stage Six: Motion and Part Three of The Ultimate Positioning Playbook, The Launch Process. Do that work first. This checklist assumes the story is already built and is now getting shipped.

How Big a Deal Is This? Launch Tiers

Type tells you which rows apply. Tier tells you how many sections to run at all. Not every launch earns the full sequence, and running the whole checklist on a minor patch is how launch process becomes something people route around.

Three tiers, sized to impact rather than effort. Tier 1 is a major launch, net-new capability that opens a market or shifts GTM strategy, and it earns the full checklist. Tier 2 is a strategic update, meaningful to the existing base but not a new market motion. Tier 3 is incremental — a maintenance release or small enhancement that mainly needs a clean announcement, not a full gate.

Tiering matters because attention is finite. A launch team that treats every release as equally important spends the same energy on a font change as a new product line, and the team learns to tune out the process rather than calibrate to it.

When in doubt, tier down rather than up. A Tier 3 release that quietly turns into a Tier 1 fire drill is a smaller problem than a team that stops trusting the checklist because it demanded a Go / No-Go meeting for a bug fix.

TIER DIAGNOSTIC

How to Tell Which Tier You’re In

Ask these before assigning a tier. The more that land as yes, the higher the tier:

A release that changes your website copy, pitch deck, or category narrative has a different footprint than one that doesn’t. If a new prospect walked in the door the day after this launch, would their experience of the company be meaningfully different? If yes, you’re in Tier 1 or Tier 2 territory.

A proxy for how much this launch actually moves the needle on the metrics the business is accountable to — ARR, market position, competitive differentiation. Executives who are uncomfortable saying yes or no to this question usually have their answer. Genuine hesitation is a Tier 2 signal at most.

Any change to how the product is priced, bundled, or sold is a Tier 1 trigger regardless of how the product itself has changed. Pricing changes require infrastructure changes — updated CPQ, sales compensation adjustments, revised contract language, partner briefings — with long lead times and downstream dependencies.

A release that only affects the product team is a different animal from one that requires Support to update their knowledge base, Sales to learn new objection handling, CS to update success plans, and Legal to revise the MSA. Each additional department is a failure point if the launch process doesn’t account for it. Count them honestly.

If yes, the launch is a Tier 1. Senior leadership attention is a reliable proxy for strategic importance. The inverse: if a two-week slip would generate zero conversation at the VP level, that’s strong evidence this is a Tier 3.

A feature launch that changes the core workflow for 80% of active users is categorically different from one that only affects users who’ve opted into a beta. Estimate the percentage of your current customer base who will interact with this change within 90 days. Above 30%, the launch earns at least Tier 2. Above 60%, it earns Tier 1.

A launch that opens new revenue requires outbound investment: new messaging, demand-gen campaigns, sales enablement. A launch that primarily defends existing revenue requires customer communication, success plan updates, and renewal narrative adjustments. Getting this wrong means spending on demand-gen for a launch that needed customer comms.

The most frequently skipped question. If this release would require you to update how you describe the company in the first three sentences of your pitch, that’s a Tier 1 signal. Positioning changes are expensive to undo — a launch that inadvertently repositions the company can do lasting damage that no subsequent messaging work fully repairs.

Zero or one yes answers: Tier 3. Two or three: Tier 2. Four or more: Tier 1, and it earns the full sequence that follows.

Tier 1 launches run every group below. Tier 2 launches can typically skip Beta & Demo Readiness (Section 02) unless the release genuinely needs it. Tag every row honestly — a row marked All that quietly only applies to Product launches is how Feature and Account launches skip steps they actually needed.

PRE-LAUNCH · STRATEGY

Strategy, Planning & Pricing

This is where a launch either gets a real owner and real goals, or drifts into “everyone’s responsibility,” which means no one’s. Pricing and packaging decisions made here are the most expensive to unwind later: once a number is quoted to a prospect or written into a contract, changing it costs credibility, not just paperwork.

Launch manager assigned, kickoff meeting held  ALL

A launch without a single named owner will be delayed. The launch manager is not the person who does everything — they are the person who knows what everything is, who owns each piece, and who is accountable for the sequence running correctly. In practice this is usually the product marketing manager for Product launches, the product manager for Feature launches, and the customer success manager for Account launches. The kickoff meeting has one job: make sure every function that needs to do something before GA knows what they own, when it’s due, and who to escalate to if something slips.

Goals and success metrics agreed: pipeline, adoption, CSAT  ALL

“Increase adoption” is not a goal. “Achieve 40% feature activation among active users within 60 days of GA” is a goal. For Product launches: pipeline generated, trials started, conversion rate from trial to paid. For Feature launches: activation rate, usage frequency, support ticket reduction. For Account launches: adoption milestone achievement, renewal probability score, executive sponsor satisfaction. Agree on these before the launch — post-launch metric selection is how teams retroactively declare victory on the one thing that happened to go up.

GA timing locked and communicated to the team  ALL

GA — General Availability — creates the coordination point around which every other launch timeline is organized. Marketing campaigns run backward from GA. Sales training has to complete before GA. Documentation has to publish on or before GA. When GA keeps moving, every downstream timeline moves with it, and the compounding effect is a launch that arrives in pieces rather than as a coordinated moment.

Biweekly launch standups scheduled through GA  ALL

Launch preparation fails between meetings. The biweekly standup exists not to review status but to surface things that are stuck or at risk before they become emergencies. Each standup answers three questions per workstream: what was completed since the last meeting, what is at risk before the next one, and what decision or resource is needed to stay on track.

Product or feature naming finalized  PRODUCT

Name changes after go-to-market infrastructure is built are expensive. Once a name appears in a sales deck, website page, press release draft, partner briefing, or contract template, changing it requires finding and updating every instance. Beyond the mechanical cost, name changes create persistent confusion. Finalize the name before anything else gets built around it.

Pricing and packaging confirmed, Van Westendorp check run if new SKU  PRODUCT

The Van Westendorp Price Sensitivity Meter is a four-question research instrument that identifies the price range a market will accept without rejecting it as too expensive or discounting it as suspiciously cheap. It produces four threshold points defining the acceptable price range. Fast enough to run before a GA commitment; provides a useful sanity check against purely internal pricing intuitions.

Ordering, handoff, and discounting processes defined  PRODUCT

A product that is live but cannot be cleanly ordered, transitioned from trial to paid, or handled by Sales ops when a discount is requested is not functionally live. What does the order form look like and who processes it? What is the handoff sequence from trial to paid contract? What is the discount approval matrix? Each of these is a place where a launch can stall at the last mile.

PRE-LAUNCH · LEGAL & FINANCE

Legal, Finance & Systems

These tasks have the longest lead times and the least visibility, which is exactly why they get missed. An MSA that wasn’t updated or a CRM still showing the old SKU doesn’t fail loudly; it fails quietly, in a contract redline or a confused Slack message weeks after launch. This group usually sits outside the core launch team, so it needs a name attached and a date chased, not just a row on a list.

MSA and privacy / security policy updated  PRODUCT

A new product with capabilities not contemplated in the existing MSA — data processing, integrations, AI features, enterprise-tier service levels — creates legal exposure if sold under the old agreement. The legal review needs to complete before the first customer conversation about the new product. If the new product processes data differently (new categories, new retention periods, new third-party sharing), the privacy policy needs to reflect that before GA.

Trademark or patent filed if applicable  PRODUCT

Filing timing matters because trademark protection is priority-based: the first party to file has priority. In the US, common law rights begin at first commercial use. For software, utility patents have a twelve-month disclosure deadline — a patent application must be filed within twelve months of any public disclosure. This deadline runs automatically and silently; missing it is permanent.

CRM and financial systems updated with new product and pricing  ALL

Sales CRM systems that don’t include the new product or feature make it impossible to track pipeline, forecast revenue, or run accurate reporting. Financial systems that haven’t been updated can’t process orders, recognize revenue correctly, or produce accurate commission calculations. Flag this at T-minus four to eight weeks — these updates frequently require IT or RevOps resources with their own backlogs.

Waivers drafted for any functionality turned on or off  FEATURE

Some feature releases change what existing customers can do — adding capabilities some won’t want, removing capabilities some depend on, or requiring opt-in to unlock the full experience. The legal and product teams need to agree in advance on what documentation governs the change and what remedies are available to customers who object. The drafting has to happen before any customer communication about the change goes out.

PRE-LAUNCH · ENABLEMENT

Documentation & Internal Enablement

If Support, Customer Success, and the rest of the company don’t understand the product before customers do, every early question becomes an escalation instead of a quick answer. Pay the internal trust tax now with documentation and training, or pay it later in support tickets that make the launch look worse than the product actually is.

Product release brief and internal release notes written  ALL

The product release brief is the internal document that explains what is shipping, what problem it solves, who it’s for, how it’s positioned against competitors, and what the key messages are. It is the single source of truth for every other piece of launch content — sales decks, website copy, press releases, and customer communications all draw from it. A release brief that is vague, incomplete, or internally contested produces a launch where each function says something slightly different, which is how buyers encounter conflicting information and lose confidence.

Roadmap and internal FAQ updated  ALL

The internal roadmap needs to reflect what has shipped, what is in flight, and what is next. The internal FAQ answers the questions that will predictably come up inside the company as the launch is announced: Why did we build this? Why now? How does it relate to X we already have? What happens to customers on the old version? Who can approve exceptions? A well-maintained internal FAQ lets every person in the company answer the ten most common questions correctly without escalating.

Support, implementation, and integration documentation complete  ALL

Customer-facing support documentation has to be live on or before GA. When a customer encounters a problem in the first week and searches the help center and finds nothing, it creates an unnecessary support ticket the team handles manually. Implementation documentation covers how to set up, configure, and deploy the product. Integration documentation covers how it connects to other tools the customer uses. Both require input from product and engineering and have to start early enough to clear review cycles.

Cross-functional product training held for Support, CS, and Services  ALL

Support needs to understand common failure modes and how to diagnose them. CS needs to understand the value proposition and how to connect the new capability to customer outcomes. Services needs to understand implementation complexity and common configuration mistakes. All three groups need to know what they can resolve themselves versus what needs escalation. Training that happens after GA serves customers who have already been left without support; training that happens before GA is the launch.

PRE-LAUNCH · MARKETING

Marketing & Demand Gen

This group runs on two different clocks. Some of it has to land exactly on the announcement — press, analyst briefings, the website going live. The rest can trail behind without costing anything — SEO, blog posts, review-site updates. Confusing the two is how a marketing team burns launch week on tasks that would have worked fine a month later.

Website, SEO, and review-site listings updated  PRODUCT

The website has to be ready at GA — not the day after. Website readiness includes not just a product page but every adjacent page: pricing, comparison pages, any “how it works” or solution-area pages now incomplete without mentioning the new product. SEO preparation means structured pages with title tags, meta descriptions, proper heading hierarchy, internal links, and submission for indexing before the announcement. Review-site listings (G2, Capterra) require separate updates and often have a moderation queue — submit at least a week before GA.

Case studies, customer quotes, or references secured  FEATURE

Feature launches are validated by proof from customers who’ve experienced the value, not by product claims alone. A case study typically takes four to six weeks from first conversation to published story, which means it needs to be in flight at T-minus eight weeks at the latest. A strong attributed quote with a specific claim is significantly more credible than a generic testimonial, and achievable in a shorter timeframe.

Analyst, press, and influencer briefings scheduled  PRODUCT

Schedule major analyst briefings at T-minus three to four weeks. Press briefings at T-minus one to two weeks with an embargo date of GA. The briefing itself is not a sales call; it is an information transfer with Q&A. Analysts will ask questions not on the press release — the briefing team needs to be prepared to discuss strategic rationale, competitive positioning, and pricing logic.

Demand-gen campaign built for upsell or cross-sell audience  FEATURE

Feature launches require a different demand-gen approach than product launches. The most effective channels for existing-customer demand-gen are usually direct email, in-app notifications, and CS-led outreach. Paid acquisition is typically not the right channel for feature launch demand-gen; spend that budget on customer education instead.

PRE-LAUNCH · SALES

Sales, Partner & BDR Enablement

A launch is only as good as the team’s ability to sell it the same day it ships. The single most common reason a well-built product underperforms its pipeline goal isn’t the product — it’s a sales team that got the announcement at the same time as the customer did. Enablement has to land before the launch, not alongside it.

Sales playbook and competitive battlecards updated  ALL

The sales playbook is the operational guide for how to sell the new product or feature: what questions to ask, what the value proposition is for each buyer persona, what objections come up and how to handle them, what the proof points are, and how the deal should be structured and priced. It is not a feature sheet. Competitive battlecards tell a rep how this product compares to leading alternatives — what to say when a prospect mentions a competitor, what questions expose where the competitor falls short, and what the differentiating proof points are.

Sales training delivered and competency validated  ALL

Training without validation is performance theater. A one-hour product overview webinar that ends with a quiz is coverage, not training. Effective sales training includes: a live walkthrough, a demonstration of how the sales conversation flows from discovery through proposal, a chance for reps to practice the pitch in a role-play scenario with feedback, and a competency check that confirms each rep can articulate the key value propositions and handle the top three objections before they talk to a customer.

BDR and outreach scripts or cadences updated  PRODUCT

If BDR outreach sequences don’t incorporate the new product, they continue to generate pipeline on the old story while the new one is live. BDR cadences need updated email copy, call scripts, and LinkedIn messaging. A typical BDR cadence has six to ten touchpoints across multiple channels, each of which needs to be written, approved, and loaded into the sales engagement tool. Allocate at least two weeks for this work.

Key partners briefed ahead of external announcement  PRODUCT

Partners who are surprised by a product announcement at the same moment as the public have nothing to say when their customers ask about it. Partners need to be briefed under embargo before the announcement with enough information to understand the product and answer basic customer questions. Build a partner FAQ alongside the briefing.

PRE-LAUNCH · CUSTOMER READINESS

Customer Readiness

For Feature and Account launches especially, this is where adoption and retention get won or lost — not in the announcement itself. A good product with a confusing rollout reads to the customer as a bad product. The account team’s job here is to make sure nobody important hears about the change from anyone other than you.

Customer-facing webinar or “what’s new” comms scheduled  FEATURE

Existing customers learn about new features through proactive communication, not through release notes that require them to go looking. A live webinar demonstrates the new capability in context and gives customers a chance to ask questions in real time, surfacing adoption blockers and confusion points that would otherwise show up as support tickets. Schedule it within the first two weeks of GA.

Named accounts notified ahead of general announcement  ACCOUNT

Enterprise customers and strategic accounts should hear about a significant launch from their account team before they read about it in a press release or see it announced on social media. The notification call should give the customer a brief overview of what’s changing, directly address any impact on their current contract or usage, and give them a chance to ask questions before the information becomes public.

Customer training assets and documentation published  ALL

Training materials need to be available the moment a customer decides they want to use the new feature. This includes: a getting-started guide, a short walkthrough video (two to five minutes), a detailed documentation page in the help center, and an FAQ addressing the most common questions your beta users raised. All of these need to be live at GA, not in development. Kick this work off at T-minus six weeks minimum.

External release notes published  ALL

External release notes are written for customers — translated from technical change log language into language about what they can now do that they couldn’t do before. Good release notes answer three questions: what changed, who it affects, and what they should do about it. They should be findable — linked from the product dashboard, emailed to affected users, and updated in the public changelog.

Success plan and adoption milestones agreed with the account team  ACCOUNT

For a named account launch, success is defined in the success plan agreed before go-live, not at go-live. The success plan should specify: the specific user groups or workflows that will be transitioned, the timeline for each transition, the adoption milestones indicating success (activation rate, usage frequency, workflow completion), the executive stakeholder responsible for championing adoption, and the escalation path if adoption is falling behind.

Executive sponsor and champion confirmed and briefed  ACCOUNT

The executive sponsor is the senior person at the customer who wants this launch to succeed and has the authority to unlock adoption when it stalls. The champion is typically a more operational stakeholder who will actually use the product and become its advocate internally. Both need to be confirmed — not assumed — before GA. An account launch without a named champion at the customer requires constant pushing from the vendor side.

Define what “ready” means before the beta starts, not while reviewing results with emotions already attached. A beta only earns its keep if it clears three checkpoints, in order — skipping one doesn’t save time, it just moves the failure to a worse, more public moment.

BETA CHECKPOINTS

The Three Checkpoints

Recruit from your Best-Fit Segment in the Positioning Stack, not just whoever is available. An eager tester outside the segment can clear all three checkpoints for reasons that won’t repeat with your actual buyer — enthusiasm instead of signal.

Checkpoint 1 — Technical: the product holds up under a real workflow  PRODUCT

A beta that clears the Technical checkpoint has demonstrated that the product works reliably under the conditions actual customers will use it — not just in a controlled demo environment with perfect data and no edge cases. The product should handle the full range of inputs real users will actually send it. Bug severity thresholds typically mean no Severity 1 (data loss, security vulnerability, complete outage) or Severity 2 (major feature inoperable, no workaround) bugs open at the time of the checkpoint review. Data integrity failures are the most damaging to customer trust.

Checkpoint 2 — Value: it actually solves the problem it claims to  PRODUCT

Usage and value are not the same thing. A beta participant who logs in three times a week but never completes the core action the product was built to enable has not validated the value checkpoint. The core action is the specific behavior that corresponds to value delivery — in a content planning tool, it might be publishing a first piece of content; in a CRM feature, it might be logging a first deal stage update. Track completion of that core action, not just login rates. Set the task completion threshold before the beta starts.

Checkpoint 3 — Reference: someone will put their name on it  PRODUCT

The reference checkpoint is a market signal, not a marketing exercise. A beta participant who agrees to be quoted, to participate in a case study, or to take a reference call from a prospect is making a professional judgment: they believe in this product enough to attach their reputation to it. If no beta participant will agree to any of these things, that is information. The absence of willingness to reference should be explored before the Checkpoint 3 box is checked. “We just haven’t asked them yet” is not a reference secured.

Demo Readiness

Every workstream in a launch needs exactly one person who can be pointed to when someone asks who decided this, and a short, deliberate list of who weighs in before that decision gets made versus who just needs to hear about it after. Most launch delays trace back to a workstream where two people each assumed the other owned the call.

OWNERSHIP

The Launch Ownership Model

Four roles, one per workstream. The Driver does the work. The Owner is accountable for the outcome — one name only, and the only person who can actually say go. Advisors weigh in before the decision is made. The Audience is told once it’s final, not before.

The meeting itself should answer one question per workstream: is the Owner prepared to say go? If any answer is no, that is the agenda. Everything else is status theater.

How to Run the Meeting Itself

When it works: each workstream owner has two minutes to give the RAG status and the specific blocking issue if any workstream is Amber or Red. No detailed status updates for Green workstreams — Green means go, and the meeting moves on. Every Amber or Red gets one question: what does it take to turn this Green, and when? The meeting ends with a clear decision: Go, No-Go, or Conditional Go with specific named conditions that must be cleared by a named date.

A Conditional Go is a legitimate outcome. It acknowledges that most workstreams are ready but one or two remain in flight. It is better than a No-Go that demoralizes a team that has done the work, and better than a Go that ignores real risk because everyone is tired of waiting.

What Makes a Go / No-Go Meeting Fail

The most common failure mode is treating the meeting as a status update rather than a decision gate. The second most common failure is ambiguous Amber: a status with no named owner and no specific date means the team has normalized risk rather than managed it. Push every Amber to a specific answer — “who owns turning this Green, and by what date?” — before moving on.

SCORECARD

The Launch Readiness Scorecard

Eight workstreams is already too many to eyeball in a status meeting, and a real launch has more than eight rows behind it. A one-page RAG roll-up gives the room a single glance before anyone opens the detailed checklist.

Amber is an honest status. A workstream marked green that turns out to have been amber all along is the single most common reason Go / No-Go meetings produce a go decision the team didn’t actually believe.

How to Run the Pre-Mortem

Assemble the same group that will be in the Go / No-Go meeting. Give each person five minutes to write, individually and silently, their answer to this prompt: “It is six months from now. This launch failed badly. What went wrong?” The individual writing period matters — without it, anchoring bias and social pressure toward optimism will suppress the risks that most need to surface. After the individual writing period, go around the room and have each person share one risk at a time, round-robin, until all risks are on the table.

Then prioritize: which risks are highest likelihood? Which are highest impact? For any risk in the high-likelihood or high-impact zone, the group should agree on a specific mitigation owner and a specific mitigation action before leaving the meeting.

Additional Prompts by Risk Category

Messaging risks: What if our messaging doesn’t land differently from what competitors are already saying? What if sales teams interpret the value proposition differently from each other? What if the announcement generates attention from a segment we’re not set up to serve?

Operational risks: What if the CRM update isn’t complete at GA and Sales can’t process orders? What if Support is overwhelmed by day-one ticket volume? What if a key partner surfaces a conflict the week before the announcement?

Customer risks: What if a major customer objects publicly to the pricing change? What if adoption is lower than expected in the first 30 days and the board asks why? What if a beta customer’s reference becomes unavailable?

Competitive risks: What if a competitor announces something similar in the same week? What if a competitor responds to the launch by dropping their price? What if analyst coverage focuses on limitations rather than strengths?

Technical risks: What if the GA release has a critical bug in the first 24 hours? What if performance degrades under real load in a way the beta didn’t surface? What if an integration breaks on go-live day?

Run this with the same group that will be in the Go / No-Go meeting, before that meeting. A risk named in a pre-mortem is a mitigation plan. A risk discovered in week one of launch is a fire drill.

Launch week should be low on decisions and high on execution. Everything that required judgment should already be resolved in the Go / No-Go meeting. This is a script to run, not a place to improvise.

T-2: Final go/no-go confirmation from every workstream owner  ALL

The last checkpoint before the announcement is irreversible. Every workstream owner confirms, explicitly, that their piece is ready. This is a binary check-in: ready or not ready. If someone says “we’re almost ready,” that is not ready. Get a specific answer to “what is not done and when will it be?”

T-1: Internal announcement: sales, support, success, exec team  ALL

The internal announcement creates alignment so everyone in the company knows the launch is happening before it goes public. It should include: what is launching, the key messages to use when talking to customers, a link to the updated sales playbook and customer FAQ, and a reminder of what should and should not be said until the announcement is public. For significant launches, a live all-hands is more effective than a Slack message or email.

T-0: External announcement live: website, email, product changelog  ALL

Three things should happen simultaneously at the launch moment: the website product pages go live, the announcement email goes to the relevant list, and the product changelog updates. Coordinate the timing across teams in advance. Buyers who see an announcement email and navigate to the website to learn more and find nothing have had their experience broken.

T-0: In-app notification and existing-user comms sent  ALL

Existing users should learn about a new feature or product from inside the product, at the moment they log in, not from an email they may not see for days. In-app notifications should be brief and action-oriented: what is new, why it matters, and a clear call to action that takes them directly to the new capability. The dismissal behavior matters — if it’s easily dismissed and never shown again, some users will miss the feature for weeks.

T-0: Named executive sponsor call or go-live session held  ACCOUNT

For Account launches, the go-live moment should be marked with a call between the account team and the customer’s executive sponsor. This call is not a training session — it is a relationship moment. It confirms the go-live has happened, gives the executive a chance to ask any final questions, and establishes the cadence for the adoption check-ins that will follow.

T+1: Support queue and early adoption metrics reviewed  ALL

The first 24 hours produce the clearest signal about whether customers understand what has launched. Tickets about how to find the feature point to a discoverability problem; tickets about how to use it point to a documentation problem; tickets about errors or failures may indicate a technical problem. Low activation rate paired with high support volume means customers are trying and failing. Low activation rate with low support volume means customers aren’t trying at all.

T+3: First read on activation, errors, and sentiment shared with team  ALL

By day three, you have enough data to know whether the launch is on track. If any signal is materially off-target, day three is the right moment to decide whether an intervention is needed — a customer communication acknowledging a problem, a rapid patch for a high-frequency error, or an emergency enablement session for a sales team struggling with objections. Waiting until day seven means losing a week of compounding adoption.

This is the least-followed section of any launch plan, and the most valuable. It is also the operational home of Stage Seven: Loop, The Positioning Loop’s stage for feeding what actually happened back into Truth. A launch that never gets measured can’t make the next one better.

Adoption and usage metrics reviewed against pre-launch targets  ALL

This review should happen at 30, 60, and 90 days post-launch, against the specific targets set before launch in the Strategy, Planning & Pricing section. Review both the headline metric and the leading indicators that predict it (time to first action, depth of usage, return visit frequency). If adoption is below target, the review should produce a hypothesis about why — discoverability problem, value clarity problem, onboarding friction, or fit problem. Deciding adoption is “low” without deciding why produces no action.

Win/loss and objection themes collected from sales  PRODUCT

Within the first 30 days of a product launch, sales conversations produce the clearest external signal about whether the positioning is working. Win/loss data tells you which segments are buying and which aren’t, and which competitors are appearing most often in the deal. Both should be systematically collected as an ongoing feed from the sales team during the launch window, not from memory at the 90-day retrospective.

Support ticket themes reviewed for messaging gaps  ALL

Support tickets are unfiltered customer language. When customers consistently describe a problem using language that doesn’t match the language in your help documentation, that gap is a messaging failure. Review them at 30 days: which tickets could have been prevented with better documentation, and which tickets reveal a customer expectation gap that the pre-launch messaging created?

Account health and adoption milestones reviewed with success team  ACCOUNT

For named account launches, the success plan agreed before go-live should have specific milestones at 30, 60, and 90 days. An account that has activated the product but isn’t using it in their core workflow at day 30 needs a different intervention than one that hasn’t activated at all. The success manager’s role is to distinguish between adoption that is progressing normally and adoption that is stalling.

Findings fed back into positioning, messaging, or roadmap  ALL

The findings from win/loss, support tickets, adoption data, and customer conversations need to make it back into the positioning documents, the messaging framework, the competitive battlecards, and the product roadmap. A launch that doesn’t produce updates to any of these documents has not produced learning — it has produced activity.

Retrospective held: what would we change about this checklist  ALL

The retrospective is for the process, not the product. Which sections of the checklist were too heavy for this launch? Which were too light? Which tasks happened in the wrong order? Which owners were wrong? The answers should produce a specific set of edits to the checklist for next time — not a vague commitment to “do better,” but actual changes to the document you’ll run next time.

A launch date is a milestone, not a finish line. The checklist that stops at go-live only ever gets half the value.