Product teams focus on adding, building, making, and releasing new things. Depending on the company, teams release new products and updates from annually to daily and even hour-by-hour. Good product teams have fine-tuned hearing, attentive to even the slightest customer pain or hint at something they want. Like a fox whose ears move like radar dishes to find several signals at once, product managers listen for ways to add value to their products.

Equally exciting to me is the idea of killing a feature to increase value. This is rarely comes up, but when it does it's a treat for us Product Marketers. Believe me.

Now, this article isn't for product managers. It's for product marketers looking for the right way to communicate change to customers who are losing something in order to get more value. Taking something away felt counterintuitive to me the first time I put a communications strategy in place for unshipping a feature. Since then I learned that while there isn't a right and wrong way to do it, there are things you can do to steer customer sentiment in the right direction.

Processing the decision to remove a feature or a product

As a product marketer, you've probably been surprised by the product team a few times:

• A feature has been pulled that you thought is included in a release
• A release date is pulled forward (to your shock because these dates more reliably slip the other way)
• The design has changed just enough that your screenshots and video content are all suddenly out of date

The first time I helped remove a feature from a product was different. I hadn't been around long. I was unsure of how to handle the decision and nervous about communicating the change to our customers.

When I was approached about making this change, I reacted emotionally. I didn't want to do it. What about the people using this feature who are now being forced to change? And change is hard, so why would we do this to them?

I understand now that good product management, like any strategy, is a choice between what to keep and what to get rid of. Yes, taking things away from customers may feel bad right now, but in the long run will it be better for everyone?

Why it's important to remove features (or entire products)

Once I understood that strategic decisions involve removing options too, I was able to move on and build a communications plan. But before we get into that, let's cover down why it's important to remove features.

Reforge lists 8 reasons to unship features. It's a good idea to remove a feature if:

1. It no longer aligns with your strategy
2. There are too many bugs or the feature is no longer intuitive
3. The novelty has worn off
4. Only a small set of customers use the feature
5. It solves a problem that isn't a problem anymore
6. You have two or more competing features*
7. It works better with other products, but not the one in question
8. The costs to keep it running are too high

*It's easy to end up with two or more competing features. Acquisition is a common cause of this, as is the lack of a clear product strategy and alignment among internal teams.

If a feature doesn't improve a product experience or the outcomes of users, it should be put on the chopping block and at least considered for removal.

How to communicate a Saas product change

Once you know a feature is being removed, it's helpful to work through a series of steps to figure out:

• What exactly is changing?
• Who is impacted?
• What is the timeline and what are the milestone dates?
• What questions do you expect from internal and external stakeholders?
• How will you reach impacted users and stakeholders?
• What is the message you're sharing?

What product features will you unship?

Get clear on what's changing. As a product marketer it's important to be familiar with the products you're working with, of course. But once you're on the "inside" at a company, you're no longer a customer and you cannot possibly think like one - you know too much about the product, the roadmap, the way everything is supposed to work. Seek to understand what the change means for your users. How do you do that?

Speak with customers directly. Maybe you have channel partners who can help you understand how their clients use a feature. Speak with customer advocates, sales teams, support crews, product managers, engineers, and other product marketers to get as broad and clear a picture as possible. It's critical to understand not only what is changing but how it effects people using the product.

Who is impacted when you remove a feature?

The list of people impacted depends on the size of your customer base and the size of your company. Whether you serve dozens of customers or millions, it's important to understand all of your stakeholders.

Here's a (non-exhaustive) list of people who might be impacted when you unship a feature:

• Customer technical admins
• End users
• Customer billing contacts
• Third-party connections using APIs
• Channel partners
• Resellers
• Apps and integrations commonly used with your product (think Salesforce's AppExchange and Trello's Power-ups)
• Consultants who build solutions with your products
• Bloggers who write about using your tools
• Community members (e.g.: user communities and forums)

Those are some of the external people who need to know about the change. Internal teams matter too:

• Internal product teams
• Product champions
• Account managers
• Solution architects
• Sales teams
• Revenue and accounting teams

The list could go on, but you get the point. It's important to learn who will be impacted so you can develop a great communications plan and help as many people as possible.

When are product changes happening?

Understanding when you will unship a feature is huge. The more time you can give people before the change the better off you'll be. Map out when each change will happen and align that with the list of impacted people above.

If your product has large user base, odds are you'll need to roll out the changes, meaning not all users will see the change at the same time. Learn when the roll-out starts and when it ends. Plot major milestones so you know roughly when you have to communicate with customers.

A roll-out strategy could flow like this:

1. Remove the feature for new users so they never see it
2. Stop allowing existing users to make changes using the feature
3. Remove the feature altogether

Once you have a product timeline and milestones mapped out, you can work backwards from there to develop your communications plan.

Build a questions and answers list

As the person (or team) responsible for communicating this change, it's important to ask questions. I like to build a list of questions as early as possible, so it's one of the first things I do when unshipping a feature comes up.

Here's why a Q&A doc is helpful:

• Writing questions down helps me remember them and I often uncover answers in conversation with the product team (lots of Aha! moments)
• The Q&A list cuts down on back and forth by putting everything in one place instead of the wilderness that is Slack or email
• You won't put anyone on the spot by demanding an answer in a meeting and instead you give people time to read each question and respond in their own time

Ask others to add their questions. Getting input from as many stakeholders as possible means you can address most (definitely not all) questions early and up front. As you work through the process of getting your comms ready, add questions, update answers, and share them around to make sure the right people on your team confirm the answers are correct.

Super-users' and high-touch customers' questions

Do you have a list of customers you can trust to give honest feedback and keep a secret? If you don't know who these customers are, sales or customer success might. Asking actual customers gives you an outside view of the changes and builds trust with important contacts.

Of course, this change may be super-secret and you might not want to break the news to anyone outside your company before having a very clear communications plan in place. Work with the product team to determine if it's ok to let customers in early on the secret.

Which channels are available?

You know who you're communicating with and now you can pick and choose how you'll get your message to them. Which channels do they use and which channels do you have access to? My goal with unshipping comms is to reach as many impacted people as possible.

Communication channels is another part of the plan where it helps to get your team members' thoughts. I like to pretend I know all the ways to reach our customers, but there's often someone in sales or account management that knows more than me. As Kendrick Lamar might tell you: Sit down. Be humble.

A messaging framework for feature changes

I'm a huge (yuge even) fan of playbooks and templates. Recreating the wheel sucks. Developing these communications plans takes a long time and I almost always leave something important out that I have to adjust for later. Here's a messaging framework I like. I use it to work out what we're going to say and how. Steal it and make it your own.

1. Communications objectives. Clearly define your goals and objectives for this messaging. When communicating a feature change, I like to measure things like reach and email open rates. If possible, tracking feature usage rates and other in-app signals are helpful, too.
2. What's changing? If replacing a feature with a new one, what's new? What are you taking away? Sometimes a simple changelog will do, but if you're unshipping a feature with a lot of users it's good to communicate as clearly as possible what changes a user will experience.
3. Why is this happening? Explain your decision in clear terms. Users may not agree with the decision, but give them a chance to understand why you made it and why these changes are happening. Your company might have acquired an app that duplicates a current feature or maybe you're unshipping a feature that costs too much to maintain. Whatever the reason, write down why and try to include this in your messaging.
4. Clear timelines. When will the changes happen and what are the milestones users should be aware of? Not all changes impact all users, so identify who is affected by each milestone.
5. Continuity. What will your users' experience look like at each milestone. How can they continue using your product, and getting value from it, after each milestone?
6. Guide your users. Help customers adapt to and embrace the change. What can you teach, share, or show users to help them make the change as smoothly as possible?
7. Compassion counts. Change is hard and harder on some. Be compassionate. This doesn't mean you have to be "sorry" to the point of being a pushover. Show customers that you understand what this means to them and be clear what your tone will be throughout each piece of comms you send out and publish.
8. User stories. Depending on the features you're unshipping, you might have customers who already embody the change. Are there customer success stories that support the decision to make this change?

Key points to remember when communicating a feature change

• There are many reasons why a feature may be unshipped and it's important that you understand why a feature is being removed.
• Once you know why the decision was made, work with the product team to understand what is changing, when the change will happen, and which internal and external stakeholders are impacted.
• Lean on your own experience and talk to other teams within your org to anticipate questions from customers so you can build a helpful Q&A list ahead of time.
• With the help of your teammates, identify the most important channels to communicate with impacted customers so you can maximize reach and build awareness.
• Remember that change can be hard. Give customers a sense of continuity with your product, share clear timelines, and be compassionate.

Steal this unshipping communications template

Click here to get your own copy of this communications framework to use when you unship a feature.