Masters of Product Change: Taylor Singletary - Slack

Slack’s empathy-driven approach to release notes, change management, and feature deprecations

Communicating product change isn’t easy. It takes the right combination of people, processes, and tools. It also requires an enormous amount of thoughtful and strategic planning, and an empathy-first approach that balances users’ needs with ever-changing business priorities.

In this series, “Masters of Product Change”, we interview individuals who have dedicated their careers to mastering the art of great product change communication. From content designers to technical writers to customer success managers, this series dives deep into the world of release communication to understand how the best companies tackle product change comms and deliver delightful customer experiences.

{{resources-component-1}}

Intro

Today, as software is released at an ever-increasing clip, and teams become more and more distributed, communicating effectively about every product change can easily slip through the cracks. However, it doesn’t seem that these factors have impacted the team at Slack in the slightest.

Despite experiencing hypergrowth across its user base and developer platform over the past decade, Slack has continued to pave the way by producing some of the most timely, creative, and thoughtful change communication in the SaaS industry. In fact, Slack prioritizes the change comms process as a mission-critical part of maintaining a stellar customer experience.

We recently spoke with Taylor Singletary, Director of Developer Relations Education at Slack, about his team’s finely tuned approach to product communication as new features, changes, and deprecations continually come down the pike. Singletary began writing documentation for Slack over five years ago, and now oversees the team entrusted with teaching developers about the Slack platform.

“We’re responsible for all of the docs on api.slack.com, writing tutorials, code samples, presenting in webinars… anything outward-facing for developers that require some form of content,” he says.

Additionally, Singletary works on Slack’s cross-functional deprecation team—the team responsible for the planning and execution of sunsetting any feature or functionality being deprecated—and sits on Slack’s API advisory board—a group that creates and maintains a set of strict guidelines and principles for all public-facing API changes.

In other words, there isn’t much change communication at Slack that Singletary isn’t either driving or directly involved with. And, this is in addition to being directly responsible for the documentation and content that supports the hundreds of thousands of developers who have chosen to build on Slack’s platform.

Not long ago we had a chance to sit down with Taylor to discuss Slack’s unique approach to voice and tone, how the best deprecations should be run, the one thing he thinks most change comms get wrong, and more.

Without further adieu, here are ten questions we asked Taylor Singletary:
‍

Questions

1. What's the history behind the unique, fun voice Slack uses in its release notes?
2. How has this voice and tone changed over the course of Slack's hypergrowth?
3. How do you approach managing change comms at such a massive scale?
4. What channels do you use to communicate about product changes?
5. What's the secret to a great changelog?
6. How do you plan and manage feature deprecations?
7. How do you think about the timing and frequency of your communication with Slack customers?
8. Who does your Developer Relations team collaborate with on change comms?
9. Over the course of your career, what launch (or release) are you most proud of?
10. What's the #1 thing you've learned after managing change comms at Twitter, LinkedIn, and now Slack?

‍
‍

"Early on at Slack there was one person, Anna Pickard, who was probably most responsible for our original voice and tone. Or at least the voice and tone of every outward communication. Things like word choice, what kind of sound poetry a sentence might have, how archaic the cultural references should be, if something was tacky or not... even things like not using the word 'Slack's' with an apostrophe s. Anna started all of that, and for a long time everything went through her, which made it super consistent. I would say that was the original foundation."

But beyond having a single person to own voice and tone, Taylor stresses that maintaining consistency is a matter of focus and intentionality: “It's so important to be intentional with your tone,” says Singletary, "and that would be my advice for others." He explains: “For example, a focus of ours in every communication is to make people feel joyous when they're reading. We want them to associate our communications with joy. And we can do this not through telling a joke necessarily, but simply through word choice and using things like alliteration. Yes, this makes things a little more complicated when you're talking about technical documentation, but to us it's worth it, and so it's a point of focus. When we write things we imagine readers on the other side reading those things and thinking: 'Yeah, I feel good reading this!' That's what we're always aiming to do every time we publish something," he says.

“Most technical writers try to boil things down to the most basic reading level, and there's nothing wrong with that. But we’ve always favored injecting a bit of fun, appropriately and respectfully, wherever we can. And so we try to go the extra mile with things like varying sentence structure, using poetic devices and hidden references, and so on. You have to be intentional, and if you are, it pays off.”

When we ask for a specific example of something Taylor has written using this tone, he quickly responds: "In one update I used 'Hey Slash Commandos!' to address a group of developers using slash commands. Making these people feel like they're part of a group of slash commandos was a simple, fun way to make them feel joyful," he says.

Of course, for some product changes Taylor flags that it's not always appropriate to inject these fun elements: "Obviously there's a difference for things like feature deprecations," he says. "With change management you have to be more careful and more respectful, especially when it’s negative news.” In these scenarios, Taylor emphasizes it’s necessary to keep things in as simple English as possible.

In closing, Singletary adds: "Like everything, there will always be a balance. When it's bad news, we like to keep it direct and simple. If it's not, we will always try to go the extra mile. We just always want readers to feel like there's something extra for them. A story that's consistent and that they're looking forward to reading."
‍
‍

"If you're growing your audience will change," Singletary tell us. "But what doesn't change is your need to understand who that audience is at all times."

He describes how things have shifted over the years: “Early on at Slack, the conversation we had was with developers. They were [a persona] we knew [we] could visualize and talk to on a regular basis. And most of these were developers that were super excited and interested in Slack. They loved the product and they loved the company's voice and tone. So it was easy and really natural for us to continue using this same tone in our docs and in our conversations with them."

"But as time has gone on, and Slack has blown up, the audience reading Slack developer content has grown significantly. We're conscious of the fact we're no longer just speaking to power users and entrepreneurs building businesses on Slack. Today our primary audience is a developer who is working for a startup or a large enterprise, and who cares deeply about making the day-to-day of everyone on their team smoother. And so we're there to support them as much as possible."

"What does this mean more specifically? Today we hold back on jokes that we might have put in five years ago. We also know that today's audience is much more visual, so my team and I do a lot more with images and screenshots. And as we've grown localization of content has also become much more important, so my team and I do far more localization today than we ever have had to before."

Singletary users the word "empathy" three times in this part of the interview, and stresses that over the past five years his team's focus has been communicating in a way that is always in touch and empathic with the developer experience. "Every piece of content we write is by and for a particular persona," he says. "Are we a little more buttoned up today? Sure! But that's because we want anyone who reads our work to feel that it was written specifically for them. That's always been the focus."
‍
‍

“Envision a single user, then put yourself in their shoes,” says Singletary.

While many may find change comms at this size and scale to be intimidatingly large, you can tell Singletary has been around the block a few times. Prior to Slack, he held similar roles at both LinkedIn and Twitter and, in both cases, managed product change communication at an impressive scale.

While Slack’s audience might be imposing, Singletary encourages his team not to focus on the size of the audience when drafting product comms. Instead, he recommends they write as if they were communicating with a single developer: “focus solely on the one individual who’s reading Slack’s documentation [and] trying to solve a specific issue or answer a particular question.”

“When we write, we try to think about a single developer who’s sitting there, reading what you’ve written. What are they trying to accomplish? What is their goal while they’re reading, developing, or trying to get something integrated? Also, what’s their psychological state when they’re going through that process?”
‍

Singletary stresses that an empathy-driven approach to release and change communication is critical, and means the difference between messages that resonate and align with your user’s state of mind—and messages that fall flat and are ignored.
‍
‍

Singletary doesn’t mince words about where Slack’s release notes and change comms are published: “Changelog, changelog, changelog,” he is quick to tell us. The Slack platform changelog is the team’s single source of truth, and where news about all upcoming change is shared.

Singletary admits that there's room for improvement when it comes to sharing news about upcoming product updates. He would love to explore new, creative ways to get the word out about upcoming changes. Especially ways that leverage Slack.

Right now, Singletary and his team use these channels to get the word out:

• Email newsletters (both to admins and end users)
• Twitter
• In-product pop-ups
• Bespoke header and footer notifications across the site
• Calls with specific customers (through AEs and CSMs)
  
  ‍
  

“The secret is being gloriously repetitive,” says Singletary.

“To ensure you’re repeating yourself, use a template and answer the same questions in every update. Repetition not only trains your users what to expect, but hitting home the same points multiple times is the only way to ensure they actually get across.”

Here are the questions Singletary answers in every update:

• What’s happening?
• When is it happening
• What do I need to do to prepare?
• What if I do nothing?
• How do I get help?
• When is it happening? (again!)
  
  ‍
  

“The first thing to realize is that you can’t predict the reaction you’re going to get from sunsetting any part of your product. Every scenario is different. “You have to prepare as best you can, then get comfortable with flipping the switch and seeing what happens,” says Singletary.

But he’s quick to add: “You also need to have a plan in place, and it should be as structured as possible. Structure is key when announcing any negative change (a deprecation, any breaking change, etc)."

In addition to strict adherence to the aforementioned release notes structure, Singletary describes a number of best practices that he and his team follow when preparing for a deprecation or breaking change:

Be clear and direct

Users need to know when things change. When the change is something being removed, or a breaking change, Singletary stresses that clear, direct communication is critical.

“In the case of sunsetting or deprecations, you always want to lead with what’s dying. Don’t say ‘Here’s this new thing that replaces this old thing’. No, that’s two announcements. First, the old thing is dead… and then you can have another announcement if you want. But make sure there’s no muddied detail in a negative change,” says Singletary. “Be clear and direct.”

Give early notice

Singletary suggests optimizing for a “big blast radius” upfront when announcing deprecations. “Once you know you’re going to deprecate something, and you decide to share the news, there’s no reason not to go big. You should use as many channels as you can to get the word out.”

According to Singletary, maximizing eyeballs on your initial announcement helps ensure as many impacted users as possible learn about the change early on. This not only gives users time to prepare and get the change on their calendar, but also sets the expectation of timely and transparent communications with customers.

Update documentation right away

“If you’re shutting down a feature or an API endpoint, or maybe even an entire API, immediately update those docs with a notice about the deprecation. Include a link to the deprecation announcement so that any users leveraging the functionality are aware they’ll need to take action.”

Singletary says one of the biggest mistakes he sees teams make is releasing documentation updates with the deprecation itself, instead of with the initial deprecation announcement.

“Have the future present that you want reflected in the docs whenever you announce anything in the changelog.”

Immediately discourage new usage of the thing

“Put a plan in place to discourage, or even restrict, new users from using whatever functionality you’re planning to remove,” he says. “The last thing you want to see is usage and adoption numbers sky-rocketing as you get closer and closer to the deprecation date.”

Leverage customer-facing teams

A significant part of the “big blast radius” strategy involves Slack’s customer success team and its account managers. By partnering with both of these customer-facing teams, important messages about features and functionality sunsetting is communicated more casually and socially in the conversations already happening.

“It’s critical to enable these teams to ensure any deprecation is successful. I would say customer-facing teams should always be in the loop on product changes, but including someone from these teams when you’re sunsetting something is a must. If you do anything in a silo you’re going to pay for it,” he says.

Create and adhere to agreed upon principles

For a company like Slack, which has tens of millions of users and hundreds of thousands of developers leveraging their platform, timelines for API-related change are crucially important. If not managed correctly, millions could suffer the consequences.

For this reason, Singletary shares that he and his team have developed a principle that allows users and developers alike to confidently engage with the platform: “Any active API or API endpoint will be active at least one year from that day. It should be truly exceptional to get less than 365 days worth of notice that we are sunsetting something.”

While he’s quick to add that this isn’t a hard and fast rule, he says removing anything with less than a year’s notice can result in a bad experience and erode trust throughout the developer community that’s so critical to the Slack ecosystem. “If you sit down and work with something today, we should be able to guarantee you that it will still be live and working in exactly a year.”
‍
‍

Singletary says frequency comes down to the type of change, and knowing your audience. For their team, as they primarily deal with a developer audience, Singletary likes to think of it more as maintaining an ongoing conversation than delivering announcements at specific times.

“When it comes to change management, especially if it’s a deprecation, the most important thing is knowing your audience. Knowing where they are and knowing how they like to be reached is key. For example, if there’s a group of 20 developers that I know are really passionate about something we’re changing, we’ll reach out to them directly. For others it’s an email. Others we know are in a shared Slack channel and like to be reached there. But in every case I like to think about it as an ongoing conversation we’re having with them. We know how to reach them and they know how to reach us. Thinking about these kinds of things as an open dialogue, and not just a moment in time, usually makes any communication more well received.”

Singletary again stresses the importance of repetition, and says that Slack has a template they use to announce any breaking changes. He emphasizes that a big part of this strategy is announcing the change many times in different places.

“In every communication we make, we always include the “What if I do nothing?” section, and the truth is that I know most people, especially engineers, don’t want to be bothered. We hope they'll read this section and just choose to do nothing, understanding the consequences, but choosing to do nothing is indistinguishable from not having been reached. So we anticipate this and ideally try to reach them many times before any change actually goes into effect.”

“If we’re talking about any sort of breaking change, or anything that’s going to impact your user experience, I guarantee you your audience is going to be way more annoyed if the day comes for you to switch something off and they feel like they weren’t properly notified. I’d be way more worried about that than reaching people too many times in advance.”
‍
‍

To collaborate on the best release notes, Singletary and his team rely heavily on Slack. According to him, the asynchronous nature of Slack is perfect for people to leave feedback on others’ ideas whenever a moment of creativity strikes.

“We have a Slack channel called #platform-editorial and whenever anyone’s writing an update or any change comms they usually drop an early draft, or even some bullet points, in there. In most cases you have a few days to work on whatever you’re writing, which is perfect because it gives you just enough time to workshop the messaging and let people come in and out of the channel and riff on it. A lot of times someone will hop in and say: 'Oh, I’ve got the perfect idea for this!' and then, if you like it, you can run with it.”

“The entire process is super collaborative, and that’s partly why I think our release notes have the lighthearted tone they do. We have fun with them. We’re almost always laughing as we’re throwing ideas back and forth. And honestly, a lot of times we’ll actually finish a set of release notes before they’re due just because we get going on a great idea and it’s fun.”

When deprecating a feature, Singletary partners with multiple internal teams which serves as another reminder of 1) the impressive size and scale of Slack’s developer platform and 2) what a team sport great change comms truly is.

According to Singletary, Slack’s deprecation board is made up of the following people and roles:

• Two Project Managers: “Our project managers make everything go and are amazing at putting structure around our work. They’re honestly the secret to making deprecation projects successful.”
• An Engineering Manager: “The Eng Manager represents all of engineering’s considerations in the deprecation. They’re there to ensure all the necessary engineering teams are aligned and adequately preparing for the change.”
• A Product Manager: “We always have a PM there, and sometimes multiple, depending on the size of the deprecation. It’s important for the PMs to bring a more strategic perspective to the group and ensure Slack’s product roadmap and product strategy are front and center. Because PMs sit at so many different tables every day, they have a super unique perspective.”
• A member of Support: “Support is there to represent the customer experience and ensure they’re appropriately staffed to support our customers. Our Support team is super technical and they’re the ones who will be handling all the tickets coming in related to the change.”
• A member of Partner Engineering: “Someone from Partner Engineering is there to represent the interests of Slack’s strategic partners. Slack works with a bunch of partners on a very deep, technical level, and we have to ensure these partners are prepared for any big change.”
• The Head of Technical Customer Success: “We have a special technical CSM team who builds integrations on spec for any organization who needs customized Slack functionality on our platform. It’s really important this team is in the loop.”
• A Product Marketer: “And we can’t forget marketing. Someone from marketing is there to help us plan the announcement, ensure it’s not going to conflict with anything else the company is planning to do, and any other activities we’re planning to do. Deprecations are often in context of something new, so there's always the aspect of highlighting that new thing too.”
  

He adds: “And with so many people in the room, these days we often need a tie breaker on big decisionsIf there’s a conflict it’s really important that it’s not just the most senior person in the room who gets the final say. The customer experience should always come first, and that’s where the principles I mentioned are so important. When in doubt, I always go back to the principles and let those be the guide.”

“Are those principles inflexible? No. Is there horse trading that goes on? Of course! With this many stakeholders, you have to be flexible. But at the end of the day my job is to ensure there’s a great developer experience, and as long as that’s always top of mind, I know we’ll make the right decisions.”
‍
‍

When we ask Singletary about some of the most memorable moments in his career in Developer Relations, he said there are two highlights that stand out. The first, from his early days at Twitter. And the second, from his time helping to scale the Slack developer platform. In his own words:

“Well I would say the best was also the worst, and that was the release of Twitter’s v1.1 API. But that release was, of course, also timed with the deprecation and retirement of Twitter API v1, and that v1 had the longest tail of integrations… you wouldn’t believe it. But the way we handled that launch and deprecation became the blueprint for how I’ve done things ever since.”

“During that launch I wrote this doc called ‘planning for anticipated and unanticipated breaking changes,’ and it laid out the protocol for how we would handle the versioning of things, how we would roll forward, roll back, how to handle things we couldn’t undo once we’d done... all kinds of stuff. At the time I was writing it it was super on the fly, but that document ended up being the playbook for the entire deprecation.”

“For that launch we spent weeks doing a series of concussion tests, or brownouts, in every time zone around the world, to ensure we knew the exact impact it was going to have in different regions.

“We would turn things off, and then on again, and communicate to everyone, during their waking hours, about what was going on and why. Each time we did a brownout, we would watch the numbers go down further and further.”

“During that launch we used Twitter’s API handle to communicate extensively about what was happening and when. The tweets were very developer empathetic, very clear about what was going on, and were communicated around the world in every different time zone. You can still go back and see them.”

“For that launch we also devised an extensive list of exceptions and a great exceptions process that we followed. And of course the toughest thing to manage is always dates. Moving dates is the worst thing to do. It’s super important to hold dates—both for developers as well as customers. But one of the reasons we were doing the brownouts was to ensure that everyone was ready when the time came for us to turn things off. And sometimes you realize how unprepared a group really is, and you have to make exceptions. So we developed this great system to determine if and how we would make exceptions. In fact, it's very similar to the exceptions system we've implemented and use at Slack today."

‍
While Singletary laments that one of the unfortunate things about releases in the platform and API world is that there isn’t much of a record of past work (as every new launch means new and improved documentation that replaces the old), he points us to a particular section of Twitter’s v1.1 documentation that’s been archived on API Evangelist that he says was his favorite: A field guide to Twitter Platform objects.

“I would also say I’m really, really proud of all the new platform launches I’ve been a part of. It’s so magical to launch new platforms and see entirely new aspects of platforms come alive. And to me the most exciting part is to put something out there and then watch to see what people do with it. I’ve been amazed with all of the things that people are doing on the Slack platform, and to be a part of those releases—to play a role in packaging and launching those whole new systems—is incredible. You don’t get to do that with too many teams in your life, and being involved in some of those here at Slack has been amazing.”
‍
‍

"Don't tell people how to feel."

Singletary’s closing words for product change communicators are to always empathize and anticipate how readers might react to change. But never try to tell consumers of your updates how they should be feeling or reacting to the news.

In his words: “Write down everything you would want to tell someone who’s feeling all the ways you think they might be feeling and then ensure you’re finding some way to address those feelings. Either in your update or elsewhere. But never make the mistake of telling readers how to feel.”

When we dig in on what he means by this, he gives a few specifics: “For example, don’t use the phrases, ‘Don’t worry,’ ‘it’s easy’, ‘just simply do this,’ ‘this is all you’ll need.’ If people are reading your update and they’re upset, the last thing they want is you telling them it’s all going to be okay. Stick to the facts.”

For closing inspiration of what not to do, Taylor shares this with us a “eulogy” that he wrote when Slack chose to deprecate its username functionality: A lingering farewell to the username. “When most people received this update they were upset. We were removing something they liked and used. Things they’d built were going to have to be completely re-done. They didn’t care that I’d written something clever,” he tells us. “This wasn’t the right time for us to lean into a more playful tone.” 

Singletary shares that as he and his team strive for an ongoing dialogue with their readers, they greatly value feedback. Especially when they haven’t quite hit the mark. “It's okay! You live and you learn and you improve as you go,” he says. “We see feedback as a natural part of the process.”

Closing thoughts

Over the course of our conversation with Taylor, we were consistently struck by two things:

1. The incredible care Taylor and his team took to balance the kind of structure and process required as a business scales, with the personalized touch that has been the foundation of Taylor’s approach to change communication from day one.
2. The empathy-driven mindset that guides Taylor and his team day in and day out, regardless of the job at hand, or what they’ve been trusted to communicate.
   

While the concept of “putting yourself in someone else’s shoes” is one of the oldest lessons in any customer-facing role, it’s rare to see a company that has embraced, and continues to embrace it, with such dedication. Over the years, Slack’s release notes and change comms have become widely recognized as some of the best, and most memorable, in the SaaS industry. After our conversation with Taylor we can easily see why.

If we take away one thing from this interview, it’s that great product change truly is a team sport. From Singletary's discussion of the hyper-collaborative nature of drafting new comms, to the vast array of stakeholders at the table during deprecation planning, to the way he described having an ongoing and open conversation with the developers on the Slack channel, it’s clear this work is far from a one-person show. Or even a job that’s handled by one team or one part of the org. Slack’s finely tuned product comms process is a well-oiled machine that leverages the knowledge, humor, and teamwork of dozens across the company.

As Singletary says to us: “The one thing that everyone I work with shares is a love of storytelling. Because we all know that if we tell the right story, and we can use those stories to maintain a great conversation with our customers, it’s a big win for everyone.”