How to create release announcements

50% Draft

Goals

• Get the System Admin for Mattermost excited to upgrade or to buy E20 to empower end users

• Everything should be ready to share

  • Every paragraph feels like it's ready to copy and paste into a tweet

  • Every person we thank who is on Twitter, we tweet to them

Process

A. (T-minus 20 working days) Blog Post Outline

• Release Manager prepares bullet points for release announcement and shares with PMs

  • Do not include plugins that haven't been added to the Plugin Marketplace by code complete deadline to avoid cutting those plugins from the blog post draft in the last minute if any development issues arise

• PMs start to draft the blog post and decide which sections of the release announcement will have an accompanying screenshot

B. (T-minus 11 working days) First Draft

• PMs finish the blog post draft by writing a section for each feature

C. (T-minus 10 working days) Head of PM, CPO, and MLT Reviews

• Head of PM, CPO, and MLT review the title, intro, and content

F. (T-minus 2 working days) Set Up Blog Post in Wordpress

• Release manager checks that the guidelines in the Checklist for Review of Draft are met

• Marketing (Justin) sets up the blog post in Wordpress and asks Release Manager to review

• Marketing (Justin) ensures that the blog post is mobile-friendly by testing it on smartphone and tablet platforms

G. (T-minus 0 working days) Blog Post and Tweets Published

• Release Manager publishes the blog post

• Marketing (Justin) schedules tweets from blog post (Tuesdays 10am PT, and Thursdays 10am if there's extra)

Checklist for review of draft

The Release Manager (Amy Blais) owns the release announcement, including the following checklist items unless otherwise indicated:

1. Exciting headline and subtitle

   1. Begin with a clear headline stating the purpose, e.g., "launching X", "ending support for Y", "announcing Z"

   2. Subtitle should focus on the System Admin for Mattermost deciding whether to upgrade or buy E20 to empower end users (customer focus)

   3. Subtitle summarizes the whole release, not just one or two main features. Lead with the most exciting/impactful new feature

2. Compelling, specific one-liners

   1. Introduce features with compelling, concise, specific descriptions

   2. If the feature is a filler for a release, be vague and add it at the end of the blog post, e.g. "Performance improvements to mobile" (please avoid when possible)

   3. Experimental and Beta features should be at the bottom of the list

   4. Lead with verbs (e.g. "Find most recent messages faster")

   5. Categorize features under Enterprise Edition and Enterprise and Team Edition headings

   6. Clarify type of release (feature or quality) in the intro paragraph

3. Body

   1. Promote E10 and E20 features by adding E10 Edition and E20 Edition labels throughout the blog post for relevant features

   2. All features PM team wants to highlight are included

      1. (PM team owns) Check for technical accuracy and statement of benefits

   3. The audience is primarily focused on admins, then end users

   4. No spelling errors or broken links

   5. One or more people on the team put themselves in the shoes of a System Admin responsible for upgrading Mattermost and have read through the announcement out loud, clicked on the links, and feel we've met our High Standards leadership principle

4. Thank you's and call-to-actions

   1. Simple paragraph to call System Admins to upgrade

   2. MVP winner and security note (if applicable) are included

      1. Ask Hanna for an image of the MVP winner's coaster to include in a tweet

   3. (Marketing owns) All contributors are recognized with a screenshot

      1. Names should not be red-underlined (if they are, add them to the dictionary prior to taking a screenshot)

      2. Screenshot not surrounded by a border

      3. Below the screenshot, include a text version of their names in small font with a link to their GitHub handle

   4. (PMs own) Draft Tweet text for all screenshots and MVP winner included in a separate page

      1. Contains version hashtag, e.g. #mm520

5. Screenshots

   1. Follows screenshot guidelines

   2. Do not use screenshots rated at low quality

      1. (PMs own) Rate each image High, Medium, Low quality

         1. High - Beautiful, highly compelling, grabs attention in a social stream

         2. Medium - Tells a story clearly, readable text, right size

         3. Low - Bare minimum to call an image

   3. A screenshot should always be included for the feature that is highlighted

Style guidelines

1. Highlight past successes: Cross link to promote traffic.

2. Links tell a story: Links should indicate the content they lead to without clicking, avoid "read this blog post" and instead "learn more about the incident response alpha program".

3. Actionable (e.g. downloading the latest mobile app release, including links).

4. Clear, concise, and consistent throughout.

Screenshot guidelines

Learn how to create screenshots and GIFs

Language guidelines

1. Use simple language with no buzzwords.

2. Specify Desktop App or Mobile App if a feature is not dependent on the server release.

3. Use common wording, e.g. say "Servers" instead of "Sites"; say plugins not plug-ins; say "Browser" instead of "Web App".

4. Avoid phrases that are too vague, such as "Better messaging experience".

5. Do not use internal names of features, such as "Unread toasts", "Deep linking".

6. Say "You" instead of "Users" to talk directly to the reader.

7. Say "AD/LDAP" instead of just "AD" or just "LDAP".

8. "System Console" and "System Admin" should be capitalized.