Communicating Change Effectively For Product Launches

The smartest launch campaigns don’t rely on one story. They build an ecosystem of stories. Samsung’s Galaxy S26 influencer launch is a great example of this approach. Instead of asking one creator to explain everything about the phone, Samsung worked with multiple creators across different verticals — each highlighting the feature that matters most to their audience. Film creators showcased Nightography, capturing cinematic low-light scenes that prove the camera’s power without saying a word. Gaming creators focused on the phone’s AI gaming capabilities, showing smoother gameplay, faster responses, and immersive performance. Lifestyle creators highlighted the privacy display, framing it as a practical everyday feature for people constantly on their phones in public spaces. Why this strategy works → Feature–creator alignment. Each creator demonstrates what they naturally understand best. → Audience relevance. Film fans, gamers, and lifestyle audiences each see the feature that matters to them. → Campaign depth. Instead of one big message, Samsung builds a network of narratives around the same product. Great product launches today aren’t one-off influencer posts. They’re creator ecosystems. Different creators. Different angles. One product story told through multiple perspectives. That’s how you turn a launch into something people actually pay attention to.

Most product teams have one launch checklist. They use it for everything. And that's why customers tune out.                                                                                           A good launch starts well before distribution. First, you align on the basics: → What does this feature actually do? What are its limitations? → What's the value proposition? → Who is the primary target persona? → What's the key visual or demo moment? That part most teams get right these days. Where they stumble is varying their "launch volume". Not every feature deserves the same external push. Treating a minor workflow improvement the same as a category-defining release is a waste. It trains your audience to stop paying attention. That's where launch tiering comes in: 🔴 Tier 1: Grand Launch Category-defining. Repositions the product or unlocks new revenue. → 1-2 times a year, maximum → Tactics like founder video, paid ads, PR, webinars, dedicated email blast, landing page 🟠 Tier 2: Spotlight Launch Valuable and broad. Most active users will care. → 1-2 times a quarter → Multiple LinkedIn posts, newsletter feature, demo video, changelog 🟡 Tier 3: Minor Drop Useful for a specific segment. Not everyone needs to know. → 1-2 times a month max → In-app notification, newsletter mention, knowledge base article ⚪ Tier 4: Soft Update A config change, bug fix, or subtle design tweak. → Internal note to support + changelog. Nothing more. One more thing that's underrated: before any external push, Product Marketers need to align with PMs to make sure the self-discovery layer is solid. In my experience, existing customers don't always read launch emails. They need to stumble onto the feature inside the product itself. Think contextual tooltips, visual callouts, in-flow prompts. Slack does this well. Drop a Google Drive link and it immediately surfaces the integration. No campaign needed.    If the product doesn't surface the feature, the launch email carries all the weight. That's too much to ask of one round of announcements.  Now, some mistakes I've made in the past: 1. One checklist for every tier. Even within a tier, hand-pick the tactics that fit. Not every Tier 1 needs a webinar. A Tier 2 might land better through a partner's post than your own channels . 2. Labelling everything "exciting." When every release is "game-changing", your audience learns to ignore all of them. Save the big words for when they earn it. 3. Treating Tier 1 like a bigger Tier 2. A Grand Launch doesn't just need more tactics. It needs genuinely different content. Something that stops people mid-scroll. Ex: Clay got influencers to shoot video skits for their Signals feature. 4. Never re-launching. Customers forget, and features improve. A relaunch 6 to 12 months later introduces the feature to everyone who has joined since. The tier system doesn't make launches easier.  It makes the decision clearer. What's the biggest launch mistake you've seen?

Here’s an easy way to keep your team honest about delivery: Release notes Hear me out… It’s incredible how many teams are “cranking out tickets” and “hitting sprint objectives,” yet when you turn around after a week or two and ask, “OK, what did we actually deliver that touched a single customer?” the list is uncomfortably small. But when you force yourself to actually communicate this to customers, you’re forced to face that reality firsthand. 1. What is possible now that was not possible before? -Start with a concrete change in capability. -Describe the new behavior, outcome, or option available to the customer. -Avoid vague phrasing like “improvements” or “enhancements.” 2. What’s better about it? What is the benefit? -Explain why this matters in practice. -Focus on customer impact: time saved, clarity gained, risk reduced, flexibility increased. -One or two benefits is enough. Don’t list everything. 3. What are the limitations or known issues? -Be explicit and transparent. -Call out constraints, edge cases, or things that are intentionally not supported yet. 4. How do customers try it? Answer all applicable questions clearly: -Where in the product do they go? -Is it on by default or opt-in? -Do they need specific permissions, roles, or plans? -Is any setup, configuration, or migration required? -If it’s not immediately discoverable, say so. 5. What feedback are we looking for? Be specific about what we want to learn. Examples: -“Does this cover your main use case?” -“Where does this break down?” -“What workflows does this not yet support?” If no feedback is needed, say that explicitly. 6. What state is it in? Clearly label the maturity of the feature, using consistent language. Pick your poison. This sets expectations about stability, support, and future change. 7. Where can they find help? Include links or references to: -Documentation -Help center articles -Support channels -Onboarding guides

If you’re always answering questions you didn’t see coming, your communication is not strategic — you are doing damage control. Most organisations don’t realise they’re stuck in reactive mode. Last week I talked about bringing comms in early, and many of you asked: “What does that actually look like in practice?” Here’s the difference — with practical examples. ❌ Reactive Communication: - We need talking points. The CEO was asked a question we weren’t prepared for. - A partner is asking why they weren’t informed. What do we tell them? - Employees have questions about the change. Can we explain it now? - Media is calling. We need a statement by 5pm. - Our post got negative comments. What do we say? See the pattern? Firefighting. Explaining. Responding. Always one step behind the narrative. Strategic Communication looks like this: ✅ Before the launch: - Map who needs to know what — and when. - Anticipate questions and build clear, consistent answers. - Craft messaging that shapes the narrative before others interpret it for you. - Plan stakeholder touchpoints in advance. - Build two-way dialogue channels early — not after confusion begins. ✅ During the rollout: - You lead the conversation — you don’t chase it. - Stakeholders already have context. - Questions are informed, not panicked. - Media interest doesn’t surprise you — you’ve already prepared for it (and often invited it). ✅After implementation: - You measure impact instead of managing damage. - Feedback loops are already running. - Your next initiative builds on trust you’ve already established. Result: No surprises. No scrambling. No “urgent comms request” every afternoon. How to Shift from Reactive to Strategic Ask three questions: 1. What's coming in the next 6 months that people will need to understand? (Product launches, org changes, policy updates, partnerships) 2. Who will be affected, and what will they want to know? (Employees, customers, investors, regulators, community) 3. What conversations do we want to lead, not react to? (Thought leadership topics, industry positioning, brand narrative) Then work backwards. Something happening in 6 months? → Start communicating in 3. Stakeholders will have questions? → Answer them before they ask. Perception matters? → Shape it before others do. I Know the Pushback: “But things change. We can’t plan everything.” True. Strategic communication isn’t about predicting the future — it’s about not caught off-guard by the present. It gives you: ✅ A narrative that adapts as details change ✅ Trust built before you need it ✅ Capacity to respond because you’re not drowning in last-minute requests ✅ Credibility because people know you keep them informed The Question: Are you creating the narrative — or catching up to it? Reactive communication protects you when things go wrong. Strategic communication positions you before things happen. One keeps you safe. The other moves you forward. Which one are you building?

I was halfway into a demo with a couple of Directors. Their eyes shifted and posture slouched. I'd lost them. But kept going—walking them through one feature after another. Realized they weren't engaged because I hadn’t earned their attention. I was dumping features without connecting them to the problem they were trying to solve. That’s one example, but it's how my demos used to go 👆 Deals stalled. Win rates dropped. ................................................................. That's until I switched to a simple 5-step framework for presenting features on demos, which changed everything. The key difference, leading with the problem: 1. Frame the problem “Linda, you said it’s a pretty tedious process for your team to keep track of all your marketing campaigns for the month. The data is spread across a dozen spreadsheets, google docs, and emails.” • call out the problem • no product jargon • no buzzwords 2. Talk through the use case “So, when the business comes to you for a new product launch, you need to quickly start planning the campaigns. Which can be difficult given everything is scattered. You have to call sporadic team meetings to get updates, leading to product delays and potential lost revenue.” • you've uncover the use case via discovery • talk through how they’re getting the job done today 3. Show the feature “Let me show you how you can see all of this in one place and how you can cut your current process from 10 steps down to 3.” • walk through the feature • be crystal clear about what they’re seeing • it's your prospect’s 1st time seeing it, but your 100th 4. Articulate the outcome “This will help you launch your marketing campaigns 2.5x faster, meeting the business’ product launch dates.” • execs care about business outcomes • clearly state what it could look like with this capability 5. Ask a question “How do you see your team using this capability to solve for [X problem]?” • keep your prospect engaged throughout • lock in those micro-closes ……………………………………....... Have intention and purpose in your demos. Don’t be a feature dumper.

Most product launches fail before they even start. Not because the product isn't good. But because the launch is treated like an event instead of a system. At Circle, we've run dozens of launches. Big ones, small ones, feature drops, and major releases. And here's what actually drives results: 6 weeks before: Build the foundation - Invite your most engaged customers to beta test and gather testimonials early - Write the one-sentence value prop that your sales team will repeat 100 times - Start seeding the story with key customers and partners - Create assets your team will actually use, not just pretty decks 2 weeks before: Create momentum - Collect transformation stories - not just what changed for them, but what changed for THEIR customers - Start the drumbeat with content that educates, not just announces - Find a few customers who'll present their wins at your launch event Launch week: Orchestrate the moment - Lead with the customer transformation, not the feature list - Host a launch event where customers share their actual results (nothing beats hearing it from them) - Have your executives (and employees) share personal takes, not just corporate posts - Make it easy for people to try it immediately 2+ weeks after: Keep the energy going - Share real usage data and early wins internally - Highlight the ripple effect - how your customers and their customers are benefiting - Build a tight feedback loop with Sales and CS to hear what customers and prospects are actually saying - Double down on what's working, cut what isn't But here's what makes this system actually work: We ship something meaningful every month at Circle. That means we're constantly launching, measuring, and adjusting. Every launch has activation, adoption, and expansion targets that we track weekly. Not monthly. Weekly. When you're measuring in real-time, you can pivot fast when something needs adjusting. If activation is low on day 3, we know. If adoption isn't hitting targets by week 2, we adjust. You're not waiting weeks to course-correct, you're doing it right away. The best part? When you bring customers along for the journey, they become your best advocates. They've seen the before and after. They can speak to the transformation better than you ever could. Because a great launch doesn't end on launch day. That's when the real work begins.

Change is chaotic. And we don't talk about that enough in our communication plans. 𝐁𝐞𝐟𝐨𝐫𝐞 a major change, people feel anxious. Not just about the new system—about competence, value, whether they still fit. The communication that lands acknowledges this. It doesn't say "this will be great!" It says "this is hard, we know, and here's how we'll support you." 𝐃𝐮𝐫𝐢𝐧𝐠: People oscillate between excitement and overwhelm, sometimes in the same hour. They need communication that's steady and human. A manager checking in with "How are you actually doing?" lands differently than a memo about metrics. 𝐀𝐟𝐭𝐞𝐫: People need to know they didn't break anything, they're not falling behind, and their concerns mattered. They need to feel heard, not just informed. The best change communicators I've worked with (the ones whose teams actually moved instead of resisted) had one thing in common: they communicated like they believed their employees were smart, anxious, and doing their best. Not like they needed to be sold. That respect shows up in everything: tone, frequency, willingness to say "we don't know yet," letting people ask messy questions. The change didn't feel smooth because the plan was perfect. It felt smooth because people felt seen.

A lot of product marketers are told to “own the launch.” But what that really ends up looking like is a glorified checklist. This is a problem. A good product launch is a strategic GTM motion that builds internal alignment, drives external clarity, and supports real business goals. And recently, Natalie Marcotullio from Navattic shared a great launch, when they rolled out Launchpad, so I want to use it to walk you through what this looks like in practice. Here’s the 5-part launch framework I coach clients on, and how it played out for this example: 1️⃣ Strategic readiness This is the part most teams skip. Everyone’s eager to “go live,” but you’d be shocked at how many can’t answer basic questions like: --> Who is this product for? --> Why are we launching it now? --> What’s the pain point we’re solving, and how do we know? This can happen a lot when PMs are under pressure to launch sooner before the product is ready (and are sucked into the build trap). What Navattic did: In Q4 and Q1, a small group of co-founders and sales reps quietly built and validated Launchpad. While marketing was not involved here, the product side ensured that this step was done. 2️⃣ Positioning & messaging Great messaging starts from the synthesis of real insights… and then ties a human story to it. What Navattic did: Natali pulled real call recordings, identified patterns, and built messaging around them. She also interviewed Navattic’s CEO about his time as an SE, grounding the narrative in the emotional reality of the demo treadmill Launchpad is designed to solve. 3️⃣ External promotion strategy Promotion should be treated as a marketing campaign, not a to-do list. Start with a clear theme or big idea. Then choose your channels and sequence intentionally based on how your audience actually buys. What Navattic did: In Q2, they quietly added Launchpad to the pricing page and iterated the copy 3–4 times. They ran lead gen through high-intent channels like SE conferences, LinkedIn, Google, and even AEO (ChatGPT and Perplexity). When launch day came, they focused on channels that mattered, like their trusted advisors and loyal customers who love them. 4️⃣ Internal enablement This is the final (and often most overlooked) step: making sure everyone inside the company understands the story and can retell it, through both documentation and training. What Navattic did: Natalie enabled everyone early: field teams, partners, even advisors. I got a detailed launch brief two weeks in advance, so I had the full context to speak confidently to my network. 5️⃣ Communications  Of course, a good launch also requires great communication and coordination throughout the entire process. Check out the post on this in the comments. ---- Ultimately, the key takeaway is that a great launch is STRATEGY-focused, not just tactical. ❓ What's the most important thing for you when launching major products? #productmarketing #launch #gtm #advising #coaching

Strong communication saved me $500K in ARR. Sounds dramatic? Maybe. But it’s true. A few roles ago, I had to oversee the deprecation of a product used by our smaller customers. We had a new and improved solution ready to go—but with a higher price tag and added complexity that many customers didn’t want (or need). Cue potential churn panic. My job? Prevent a mass exodus. Here’s how strong, proactive communication helped us keep 70% of our customers and over $500K in ARR 👇 The Playbook: ✅ Personalized Emails – No generic “we’re sunsetting this product” nonsense. We crafted targeted, transparent messages explaining the why, the what, and the when—plus clear options. ✅ Webinar with FAQs – We didn’t just announce change; we walked them through it. A live session let customers hear the plan firsthand and get their biggest questions answered. ✅ 1:1 Calls – High-touch for those who needed it. No one felt abandoned in the process. ✅ Migration & Exit Options – We gave customers choices, not ultimatums. Some migrated, some left (on good terms), and we even helped a few transition to alternative solutions. ✅ Consistent Updates – No surprises. Regular check-ins gave customers control over the transition. ✅ Post-Migration Support – Because the customer experience doesn’t stop after the switch. We made sure they were set up for success. The Outcome? 💰 500K ARR saved 🙌 ~70% retention 🤝 Stronger customer trust Here’s the lesson: Communication can be more powerful than the product changes themselves. Customers don’t just need a new tool—they need clarity, support, and a sense of control. SaaS is always changing. Sometimes all you have is communication. Use it wisely. _________________ 📣 If you liked my post, you’ll love my newsletter. Every week I share learnings, advice and strategies from my experience going from CSM to CCO. Join 12k+ subscribers of The Journey and turn insights into action. Sign up on my profile.

Clinicians: if you're struggling to influence your product team, you need a better script. I walked a clinician exec through this earlier this week. He had the right instinct about what needed to change, but his product team kept shutting him down. The issue wasn't his idea, it was how he was talking about it. Here's the script I gave him — five steps that work because they speak the language product people are trained to understand: 1. Lead with data, not opinions. ❌ Don’t say: "I think this approach is failing." ✅ Say: "I've been reviewing patient complaints, and here's the pattern I'm seeing. Patients are saying things like [exact quotes]. We're losing X% of patients by day 30, and when I trace it back, this theme keeps coming up." Product teams are trained to seek and respond to data. Give them user feedback verbatim and show them the business impact in concrete terms. 2. Align on the problem before proposing solutions. ❌ Don’t say: "Here's what we should build." ✅ Say: "Based on what I'm seeing, the problem we need to solve is [specific articulation]. Does that match your view?" This step feels like a speed bump but it's where you earn buy-in. Let people weigh in. Let them disagree and refine. Once you're aligned on the problem, aligning on solutions gets infinitely easier. 3. Connect every idea directly back to that problem. ❌ Don’t say: "We should try this new approach." ✅ Say: "If we agree the problem is [X], then doing [Y] directly addresses it. Can we think of any other ideas that might actually solve the problem we just aligned on?" Keep the conversation anchored and prevent circular debates about preferences. You're testing hypotheses against an agreed-upon problem. 4. Acknowledge scale constraints before your product team raises them. ❌ Don't say: "Let's do this thing that requires tons of manual work." ✅ Say: "I know this won't scale in its current form — and that's okay. We're not trying to build the final solution yet. We're running an experiment to understand what actually works." This reframe is critical. You're not asking your product folks to abandon best practices, you're asking them to learn before they build. 5. Make it safe by time-boxing it. ❌ Don't say: "We need to change our entire approach." ✅ Say: "Let's run this for 30 days and measure [specific metrics]. Then we'll look at the data together and decide: scale it, kill it, or iterate." Explicitly make the decision reversible. Product people are allergic to irreversible decisions made without data. The key insight from our conversation is this: Your product team isn’t being difficult. They’ve been trained to make data-driven decisions, build things that scale, and mitigate risk. When you acknowledge that — when you speak their language instead of fighting their mental models — you stop getting shut down and start having impact. Your clinical insights are probably right. You just need to learn how to talk so your product people can hear you.