Efficient communication is a core skill for success in product management. Product managers must tell other employees enough information that they feel included rather than blindsided and have a chance to provide timely, relevant feedback, but not so much information that recipients feel overwhelmed. By writing emails with a summary at the top, followed by the statement “— Stop Reading Here (unless you’re curious)—,” followed by a detailed explanation, product managers can please both those who want less and more information.
Email is a good tool for quickly, cheaply broadcasting factual information to large groups of people. However, different people want different amounts of detail:
- Some people just want a brief, one paragraph statement of the update or decision itself. They don’t want to be bothered with details. If you write a long email, they’ll feel their time is being wasted. (Busy account managers who trust your decisions are a classic example.)
- Others want to understand the details, background research, alternatives that were considered, and the justification for the final decision. If you write a short email, they’ll be unhappy they didn’t get the complete understanding they wanted. (Opinionated sales engineers may fall into this category.)
- Some people will object if you only inform them of the final decision. If they don’t understand that their preferred alternative was considered and the reason it was rejected, they will assume their alternative was overlooked or ignored and will often “reply all” with an objection. That may force you to “reply all” yourself with more detailed follow-up email to prevent confusion, calls for the decision to be reopened, or a sense that the product manager is ignoring feedback or a seemingly-better alternative.
How can you please all these groups and prevent lengthy back-and-forth threads of objections from people who don’t know all the details? Use the “— Stop Reading Here (unless you’re curious) —” technique.
When you have to send an update email to a large group of people:
- Summarize the update as briefly as possible at the start of the email. Tell people the minimum amount of information they have to know. What was the decision? Who is affected? When does it take effect? Who do they contact for more information? Ideally, try to do this in a single paragraph that is no more than three to five sentences long.
- Then, put in a line reading “— Stop Reading Here (unless you’re curious) —.”
- After that, explain the details behind the decision, the alternatives that were considered and why they were rejected, and so on. Provide a link to any internal wiki page that contains more information.
This approach pleases everyone:
- The busy people will stop reading and be grateful that they didn’t have to finish reading the entire email with all the details just to make sure they weren’t missing something important.
- The people who want the details will continue reading and be happy they got the full understanding they were seeking.
- The people who would have objected to the update or decision out of well-intentioned ignorance will continue reading, learn the reasons the decision was made, and usually accept it. If they still object, they will at least realize that their preferred alternative was considered and may contact you privately if they want to discuss it further. Either way, this almost always prevents an angry “reply all” that would waste the time of everyone on the email thread.
Of course, it’s always better to communicate information in person or by video or audio conference calls when time and resources allow. But product managers and their stakeholders are usually very busy and don’t have the luxury of communicating all updates by realtime interactive meetings. When you have to communicate a decision or update by email, this approach can save time and prevent controversy based on ignorance. This way, you can keep your stakeholders informed and also respect their time.
UPDATE: Bulletized the paragraph starting with “When you have to send an update email …” per the suggestion of my friend Erica.
voximate
RSS
Great advice. An additional note:
Develop a format for emails with standard sections and section headings. For example, emails about time-sensitive crises could have the following sections: Issue, Current Status, Potential Project Risks, Issue Escalation Background. People will learn to look for the section of interest to them first. And of course, always end with “Stop Reading Here.”
Also, I was surprised not to see more use of bullets in the paragraph staring with…”When you have to send an update email…” There’s a really nice format for update email content in that paragraph that’s hard to glean on a first-reading pass.
Hope all is well. And yes, I am paying attention.
eRG
Ack! Just my luck to have a Humanities major reading my posts!
Thank you Erica; updated per your suggestion!
You’ve also reminded me that putting a “type indicator” at the start of your email’s subject line (e.g. “FYI,” “REVIEW BY 3/1,” “FEATURE DROP PROPOSAL,” etc. is another favorite time-saving tip for the reader and worth a post in its own right).
I have seen the use of wiki pages that contain the current status on an issue or the agenda and minutes for a meeting to be a useful alternative to E-mail. Obviously there is always advantage to short e-mails to small audiences but as the e-mail gets longer or your audience gets larger consider using a wiki page to complement a short status update.
Oh, absolutely. I’m a huge advocate of the use of wikis for increasing the efficiency of information sharing within an organization and encouraging others to contribute and update pages with what they know. I plan a future post on the usefulness of wikis for product management. One of my other best practices is always archiving update emails into the wiki so they form a history. Such wiki-based histories have several uses. (1) Covering Your Backside: proving that you in fact notified the (sales force | management team | CEO | etc.) about XYZ on a particular date when they come back and demand to know why they weren’t informed (because they’re human and forgot, or they were busy and overlooked the email). (2) Helping new employees quickly get up to speed by reviewing the entries in the history. Typically, I post the update in the wiki itself, and then the email message is really just the path to the URL in the wiki at the top (so everyone knows in the back of their mind that the information is archived in the wiki) and then the contents of the wiki page pasted inline (so people don’t have to click the wiki page URL and wait for it to load in order to read the information).
[...] the “Stop Reading Here” technique to let busy users extract only the most critical information from the top of an email while [...]