This was originally a 20-Tweet long Tweetstorm by Steven in 2019, but it’s no longer live. I reached out to Steven and he shared the text of those with me, which I’m preserving below. (Note: You can follow Steven on Twitter at @stevensi)

It’s great advice that should not be lost and complements a post on sending product updates I wrote around the same time that incorporated his advice into it. It’s a habit any good product manager should practice.

Steven Sinofsky’s Advice for Product Updates

For this post, anything in italics is Steven’s words, and regular text is my words. Any edits to Steven’s words across these 20 tweets is only for grammar, spelling, or formatting (bold, subheadings, and line breaks were my choices).

Here’s Steven’s advice:

---

Say your product has a new feature or change and you want to tell everyone about it with a blog post or some tweets. Here are a few things to think about when communicating change to a tech customer base

tl;dr Saying what you did and that customers asked for it isn’t enough.

With SaaS and agile we see many product releases that are primarily incremental feature releases. It might feel like a big release to product team, but to customers it might not be so big. To customers it might just be change. Doesn’t matter how much code it was for you.

For customers, something that is 10% better can often be 100% different. In order to be better, change no matter how big or how small, needs context and motivation for the change.

Who is the change for and why?

Dissatisfaction with change happens when there is a mismatch between expectations and reality. That gap can be closed if expectations have a chance to get set or leveled with context and communication.

The most important thing is never to communicate some change or new aspects to a product in isolation.

Is this it? Is there more? Why?

Product strategy matters.

Customers will invent your strategy if you don’t tell them.

If they are wrong the satisfaction gap widens.

“Why”?

Most common tactic (I say mistake) is to make a change to a product and put out there “people have been asking for this” or “feedback.” If you have more than like 100 users that is just axiomatic. It is also a bit presumptuous—did everyone reading this ask?

It is trivial to make a big deal out of fixing bugs, but that has a thirst to it—like you’re asking for credit for doing the basics of offering a product. People generally don’t ask for bugs to get fixed, they just think less of the product.

“Most requested” is very dangerous. What else was requested? Was there a vote? Why did you do this request and not all the other requests? Where are requests tracked?

In general, requests is not a sustainable approach to prioritization. (Ed note: Steven and I agree on this, which is why I explain in detail, “Why Feature Voting Creates Poor Products “)

What is more interesting than saying something is requested is articulating the reason for doing something that was not requested. That’s why products exist—to solve unarticulated needs not build faster horses. Teams exist to have a vision, not just fix their own mistakes.

When communicating change, it is easy to go into all the details of the change.

What is far more interesting is to explain the problem and then go through the process of how you arrived at this specific solution versus others. Was the change really necessary?

The internet will just do so for you even if you don’t.

You might try explaining that a problem is “ease of use” but unless you have specific flows and scenarios, then others will just come up with different designs and problems.

This is especially true for UI changes.

If you make a UI change you should expect people to ask for the option to turn it off. So in communicating it you should explain why it is the new “one and only” way and what is the strategy behind it.

Offering options is actually really hard in practice, the more options are offered the more people will expect them. So if you do have an option for one change and make a big deal out of it, then expect to be asked for options every time. That’s serious combinatorics.

Most changes have some data behind them—not all but most.

Your case will be much stronger if you present the data you used to make a choice: How many people use X? Is this optimized for mobile or web? What platforms? How slow then, fast now?

If you don’t present data but imply there is data then you will be debating the internet to make your case. The internet is made up of anecdotes and it will get very messy.

A corollary is not to use anecdotes yourself. “Many people requested this change” is in fact an anecdote so is “people prefer” and “feedback we received.”

If you don’t have data then supporting changes with a strategy, point of view, or related business case can be useful. Making changes that might be unpopular is part of the job but if you don’t offer anything the internet will make up a reason and you won’t like it.

The most difficult part of communicating change is the people listening and engaging are almost never fully representative of your entire user base or even target for change.

Using data to show that can help. Intellectually this is understood, but emotionally not usually.

Personal view. Write the long blog post. Maybe you choose not to publish it, but if you write it then you will know all you will face.

You might show the post to detractors, reporters, or some outsider to make sure all views are covered.

Sometimes when you make a change you don’t have to make a big deal about it. More often than we like people just don’t notice. That’s ok. // END

---

Writing a quality product update is an important part of communicating as a product manager.

Much like writing a great product spec helps you communicate internally, your product update helps you communicate externally with customers, the press, stakeholders, and your market.

If you’re looking for more insights on writing a good product update, you can read my post that builds on this here: How to Write Product Updates that delight Customers and Reduce Churn

…and you can subscribe to Steven’s substack on product development here https://hardcoresoftware.learningbyshipping.com/