A while ago, many tech outlets reported that Dropbox might shut down Mailbox. On December 8, I got Mailbox's "Saying goodbye" email.

Hello wang,
It’s with heavy hearts that we let you know Mailbox will shut down on February 26, 2016.
Mailbox ignited a shift in mobile email and many of its innovations are now ubiquitous across the industry. It’s been a great journey, and we’re proud of this impact and grateful to the community that helped make it possible.
When the Mailbox team joined Dropbox in 2013, we shared a passion for simplifying the way people work together. And solving the email problem seemed like a strong complement to the challenges Dropbox was already tackling.
But as we’ve increased our focus on collaboration, we realized there’s only so much an email app can do to fundamentally improve email. We’ve come to believe that the best way for us to improve people’s productivity going forward is to streamline the workflows that generate so much email in the first place.
We know saying goodbye to Mailbox will be hard for many. To help make the transition to a new email client easier, we’ve created guides and export tools. For more information about how we’ll be winding down Mailbox, please visit the Mailbox website.
Thank you to everyone who helped bring Mailbox to life, whether by spreading the word, letting us know what you liked (and didn’t like), or simply using the product. You taught us so much, and we’re deeply grateful.
—The Mailbox Team

I read it many times, and the more I read it, the more I thought it was beautifully written. It's clearly structured, concise, and sincere. It could serve as a model obituary for a product, and as a former Mailbox user, I found it touching.

Let's break down the email. The first paragraph tells users directly that Mailbox is shutting down and gives a specific date, answering the question on their minds. The second paragraph briefly describes Mailbox's innovations and influence on the industry, and thanks the community for its contributions. The third paragraph recalls why Mailbox joined Dropbox and its original vision. The fourth explains why Mailbox is shutting down and says the company will focus on collaboration and productivity. The fifth explains how to move away from Mailbox. The sixth thanks users again, humbly and sincerely.

The Mailbox email really makes one point: "Treat users as real people. We got here with their help, and we're grateful."

One principle I've always stuck to in Support is: "Never insult users. Users aren't idiots. You are." Countless product maxims tell us to change our mindset and treat users as novices or even idiots. But users aren't novices; they're just waiting to be served. If they really were idiots, they wouldn't be using your product.

I remember one outage when a customer was very upset and quite hostile. Someone without experience could easily have argued back and ended up in a lose-lose situation. The way to handle this is actually simple: "Treat users as real people. Truly put yourself in their shoes and think about what they need." In online support, users can't see your face or feel your emotions, and the same goes for you. You can only convey your feelings through words. First, apologize to help calm them down. Of course, attitude alone isn't enough. Next, explain in detail what caused the outage, what happened, how it was handled, the follow-up fixes, and the compensation policy. At this point, most users are satisfied, since their problem has been addressed. If they're still unhappy, offer another solution: "If you're still not satisfied, let us know what else we can do." The benefit of asking this is that users reveal their bottom line, so we learn what they really want and what it would take to satisfy them. Finally, based on their request, discuss next steps.

Besides learning from Mailbox to "treat users as real people" and how to write a product obituary, there was one more thing that inspired me.

There's a famous feel-good saying: "When others care about how high you fly, I care about whether you're happy." In a way, it gets to the heart of the matter. Applied to Mailbox, it would be: "While everyone focuses on whether an email client is easy to use, we focus on why so much email is created in the first place." Applied to Support: "While everyone is busy solving users' problems, I care about why so many problems happen in the first place." From a product perspective, users run into problems for a few reasons:

• The product has bugs
• The user experience is poor. It isn't "obvious and self-explanatory," so users struggle to figure out how to use it
• There isn't enough documentation or Q&A
• Customers are too lazy to look for answers and would rather have someone solve the problem for them

In day-to-day support, the last two reasons probably account for most issues. At our company, for example, the product and API docs are fairly thorough and cover at least 90% of questions. So why do different users keep asking the same questions, and why does Support have to answer them again and again? Are all users really lazy? If there were an easier way for users to solve problems themselves, would that improve things?

There's a famous product marketing book called Crossing the Chasm, about how products cross the chasm between early adopters and the mainstream market. In Support, our job is to bridge the gap between what users already know and what we want them to know. Honestly, I don't have a great solution either; I can only share my own thinking.

Build communities and groups. SF currently has a Q&A community, but it's too open and loose. Users have little motivation to answer each other's questions, even if they ran into the same issue before and the solution is identical. Most answers still come from staff. We once had a Discuz-style forum, but it was shut down for unknown reasons. My guess is that the company was too conservative. I've heard more than once that we shouldn't encourage users to talk to each other or customers to form groups, because during an outage they'd all know right away, discuss it, and might even band together to make collective demands. But it would be better to be more open: boldly bring users together, handle outages transparently, and solve problems. That shows customers an open and sincere attitude. Countless PR disasters have shown that being open and facing problems head-on is the shortest path to solving them, and far more graceful than trying to cover things up only to be exposed later. Besides, a good attitude can sometimes earn good feedback, which benefits the company in the long run. If a company can act with a bit of dignity, it should.

Publish changelogs for products, systems, and services. The benefits are obvious: users learn what we've done, which new products we've launched, which features we've built, and how we've improved our service so we can help them better. I remember a question on Zhihu asking why XX hadn't changed in years. The founder and CEO stepped in to list everything they had done. The real issue is: if you've done all that, why not let users know? It could provide real value to them, so why not be more open?

Provide smart automated answers. They can reduce lots of basic inquiries, and by tracking what users click, we can understand their problems, anticipate them, and resolve issues faster.

Start a dedicated company blog. The best-known example is Basecamp (formerly 37signals)

Finding the real solution will take ongoing learning and exploration. For now, I'm just writing this down.