Battle-Tested Playbook To Announce Your B2B SaaS Feature
It is great to be in front of your customers. It is great to have customer interviews or product announcements. But have they always gone as per your plan? How to do them right?
What are the differences between a ‘meh’ and a ‘yay’ customer interaction?
We’ll start with Customer Communication Checklist and Understanding User Flows and get more prescriptive in the steps for customer outreach here.
Following the checklist approach from Checklist Manifesto, we’ll convert each of these scenarios to a checklist to reduce uncertainty.
How Would You Start A Customer Communication Checklist?
Here is a summary of the components of a checklist for communicating with your customers.
Identify customers. Uncover customers impacted based on product metrics, support queries, and sales insights.
Communicate in situ. Add information about a launch to different parts of the product.
Enable go-to-market (GTM) teams. Provide information to account managers (a.k.a. sales reps) to share with customers or answer questions.
Enable Support. Provide information, enable shortcuts, and deliberate on escalation policies for customer support to handle customer queries.
Announce launch. Announce the product launch in a regular launch updates email to customers, annual conferences, webinars, etc.
Do You Need A Customer Communication Checklist?
Maybe not.
Not everyone needs a customer communication checklist.
Are you in a company with UX Research, UX Research Ops, and Product Marketing Management teams? Do you get sufficient bandwidth from these teams?
If yes, then you can skip the rest of the article.
You don’t need to worry about the below; you can delegate these tasks to the experts.
This is for you if you are in a growth-stage or early-stage startup and need a guide.
Checklist: Research Interviews To Build A New Feature
Use this when you want to reach out to existing users. This is during the “deep-dive into needs” phase of the product lifecycle. You have uncovered an unmet need of users. Now you want to deep-dive into user behavior to validate the need and know the right problem, place, and time to solve.
Let’s use the 5 steps above.
1 - Identify customers.
Look at product usage history to understand which customers are likely to use this feature
Look at support tickets to identify customers who had a problem before that might be solved by this feature in the last 6 months
2 - Communicate in situ.
Where will our customers think of this feature? Where are they likely to read about a request for their time and be open to taking out the time? If you are unsure, you can reach customers through your sales or customer success teams.
You want to reach out to customers who don’t have an associates account manager or customer success manager? You can email the customers. But emails have a low response rate, below 10%. How to make the communication more targeted to the channel or time?
You can use tools like Qualaroo to give pop-up prompts to request customer time on web pages related to this feature. For example, are you building new admin features? Add your prompt to your admin dashboard web page. The users coming to that page are likely the relevant persona for your research deep-dive.
3 - Enable go-to-market (GTM) teams.
Although we are not enabling go-to-market, but we want to connect with them where relevant. The GTM teams will want to know when we are reaching out to customers they interact with.
Find out the account managers responsible for each customer on your list
Find out the GTM team members who created recent internal support tickets for the customer
Prepare a mailing list including above two
Send a broadcast email draft to this mailing list
Reach out to account managers individually and follow-up with them when you want to reach out to a large customer.
4 - Enable Support.
Find out if customer has any burning issue in which case don’t want to reach out to customer now.
5 - Announce [launch].
You’ve identified steps 1 to 4? You are now ready to reach out to customers. SincLet’s assume you are emailing customers.
Prepare a template email draft to customer with placeholders for “why” and “who” i.e. why reaching out to that specific customer, who recommended reaching out to them (GTM team contacts), and account name that the customer uses in your product.
Prepare calendly link
Reach out to customers one by one
Coordinate scheduling customer call
Checklist: Communicate About A Regulatory Or Policy Change With Customers
Use this when you want to reach out to users about a “launch” of regulatory or policy changes. This is during the “go-to-market plan” phase of the product lifecycle.
Some examples include:
GDPR,
starting to charge VAT/GST/Tax,
price increase or decrease to recurring items,
Schrems regional data compliance, or
Telecom KYC requirements
Let’s use the 5 steps above.
1 - Identify customers.
Build a list of customers. This includes customers who have used the relevant product in the last 6 months or whose location means they are impacted by the regulatory changes. You might need multiple data sources or tools to get the individual lists. Combine and de-duplicate the lists.
Some examples:
If you are looking to restrict customers from submitting payments using cheques, look for users who have submitted cheque payments in the last 6 or 12 months.
If you are looking to charge VAT to customers in the EU, look for customers who have addresses in the EU. Not all customers have addresses? Look for customers with significant communication traffic in the EU.
2 - Communicate in situ.
Create a draft support and/or blog article. This article should explain the impact to the customer of the regulatory or policy changes. How can they confirm they will be impacted? What do they need to do? Who needs to do it from their team? For example. KYC or change product usage.
Work with the legal, tax, finance, or another relevant team to review and publish the article.
Irrespective of where the customers will be, having this public-facing document will serve as an anchor for the information. Next think of where the customers will be receptive of this message. Is it in the product? In a transactional email?
Will an email, pop-up, video, or document serve best?
Update the product to mention the upcoming changes in the web portal, a recurring transactional email, or a document provided regularly to customers.
3 - Enable go-to-market (GTM) teams.
Modify the list of customers into grouping. grouped by tier 1 , 2 , 3 based on their revenue or sales ownership model i.e. customers prioritized by sales team or by their revenue are in group 1
Gather contact information for every relevant stakeholder for this policy change within the customers
Create a draft blurb about the change for sales organization in their weekly product update
Work with sales enablement to include the blurb in the weekly broadcast to sales org.
Create a draft email for sharing information to sales reps of the tier 1 customers.
Work with sales enablement to reach out to these sales reps.
4 - Enable Support.
Document an escalation path and support plan to enable the customer support team to answer new questions that would occur due to the changes.
Create support shortlists to reduce time for customer support to answer FAQs from customers based on the communication to customers. Show the communication around to colleagues to get a sense of potential FAQs.
Share the escalation policy, support shortcuts, and upcoming changes with customer support teams so that they are aware and have it on top of their mind.
5 - Announce [launch] change.
Create a draft email for broadcasting information to customers of all tiers.
Work with team responsible for customer communications e.g. marketing, to send out the email blast to impacted customers
A few day, weeks, or months after the change, remove the notices from any parts of the product.
Checklist: Communicate With Customers About A Feature Launch
Use this when you want to reach out to users of the product about the launch of a feature. The feature is added to an existing product with active users.
This is the “go-to-market plan” phase of the product lifecycle.
1 - Identify customers.
Build a list of customers. These are the potential early adopters of your feature.
This includes customers who have
used a related feature in your product in the last 6 months,
Usage patterns that suggest they would benefit from this feature,
Created customer support tickets or forums posts requesting this feature, or
Escalated to sales or customer success teams about this feature
You might need to use multiple data sources or tools to get the individual lists. Combine and de-duplicate the lists.
Although your TAM for your new feature is 100% of product users, you want to start with reaching out to a large enough but smallest-possible base of users.
Some examples:
When Gmail launched the feature to schedule email send, their TAM would be 100% of Gmail users. But their target audience would be users who have used Boomerang or those who sent saved email drafts at a later time without editing it.
When building a feature to mass send SMS to 100s of users at once, a Product Manager could look at users who self-declared their usage to be marketing. Also, look at usage patterns for messages with the same content sent to multiple users at once. Look at users with bursty traffic (high peak-to-average ratio). Look at users who use a similar product on non-SMS channels.
2 - Communicate in situ.
Create draft support documentation and a launch blog article. Irrespective of where the customers will be, having these public-facing documents will serve as an anchor for the information. If you have a technical writer in your company, work with them to review and publish the support documentation. I recommend having written, visual, and video content in the documentation to explain the working on the feature.
Once the doc is ready, write a blog post about the upcoming feature with context, problem statement, and the roadmap ahead. Think of a press release format. What was the problem you identified? Why did you decide to solve it? How does this feature solve that problem? What enhancements are coming up for this feature?
Next, think of where the customers will be receptive to this message. Is it in the product? In a transactional email? Will an email, pop-up, video, or document serve best? Update the product to mention the upcoming changes in the web portal, a recurring transactional email, or a document provided regularly to customers.
Some examples:
An enhancement in the usage reporting functionality could be announced inside monthly invoices, payment receipts, or the webpage/emails that contain the same.
A feature to schedule-send in Gmail can be announced next to the “Send” button, in the “saved drafts” page, and emailed to users shortlisted earlier.
3 - Enable go-to-market (GTM) teams.
Modify the list of customers into groups. Group them into tier 1, 2, or 3 based on their revenue or sales ownership model. Customers that are prioritized by the sales team or are the biggest contributors to revenue are in the tier 1 group.
Create a draft blurb about the feature launch for the sales organization in their weekly product update.
Work with sales enablement to include the blurb in the weekly broadcast to sales org.
Create a draft email for sharing information to account managers of tier 1 customers.
Work with sales enablement to reach out to these sales reps.
4 - Enable Support.
Document an escalation path for support to reach the product team when facing questions they don’t know. Get buy-in from stakeholders in the path.
Align on the process to submit bugs or feature requests. This might be taken care at a broader level and may not be needed per feature.
Document a support plan to enable the customer support team. The team should feel comfortable answering questions from users about the new feature. What is the path from the Beta to General Availablity (GA) phase?
Anticipate FAQs from customers.
Create support shortlists to reduce the time for customer support to answer FAQs from customers.
Share the escalation policy, support shortcuts, and feature launch with customer support teams so they are aware and have it on top of their mind.
5 - Announce launch.
What is the purpose of announcing the launch of your feature?
We want users with the relevant pain points to use the new feature and find a resolution to their problems.
We want prospects to know a) we invest in improving our product b) if they didn’t use this product earlier due to a relevant pain point, now they can try it out.
We want to reduce the burden on support or customer success due to the lack of this feature.
We want to enable sales given the availability of this new feature.
These above are also aligned to metrics. A counter-metric is number of users irritated by the launch announcement or marketing email. We want to announce in the right channel to the right users while enabling customer-facing teams.
Create a draft email for broadcasting information to customers of all tiers. Use the blog link you’ve prepared earlier.
Time your announcement so that Tier-1 customers got to hear from their account managers before hearing from your broadcast.
Work with the team responsible for customer communications, for example, marketing, to send out the email blast to impacted customers.
Announce the feature in the product web portal. Use the support documentation or blog link, as applicable.
Write a changelog entry.
Slot in your product announcement to any recurring customer or prospect webinars run by the company’s marketing team.
Post to social media platforms such as Twitter.
A few day, weeks, or months after the change, remove the feature announcement from any parts of the product.
Using The Communication Checklists
Does the above list help you communicate better with your customers? What are the biggest pain points you see to make your feature launch a success?