Six Reasons Your App Needs Release Notes

Including release notes for your app is good for business – and, more importantly, not including release notes is bad for business. Here’s why:

Release notes improve reviews

People often read reviews to decide whether they will use your app or service.  Several prominent, respected, quality services (including Uber and Dropbox) started to include their release process (“we release updates regularly”) as their release notes.  Their app review scores plummeted to 2 stars (Dropbox) and 1.5 Stars (Uber) on the App Store. Their apps are fine, their service is fine. The ratings plummeted right after they stopped including release notes. Why?

Think about it: Release notes are in the same place in the App Store as reviews, and reviews reset with each update. So, the people who write reviews are largely the same ones that read release notes. You may say, “apps auto-update and nobody reads release notes”. Think again – power users read release notes. No release notes, no reviews (or negative reviews) from your power users. That means your primary source of reviews is people who want to complain about your app or who are less likely to know how to use it.

Dropbox started including release notes again in January – the app’s now up to 2.5 stars; it’s hard to recover lost users.

Release notes build trust

Release notes tell users what you’re doing, and what you’re installing on their device with each update.  “Bug fixes and improvements” is vague but acceptable.  “We release updates regularly” is evasive and insulting.  Of course you release updates regularly, but what are the updates? 

Good release notes communicate to users that you respect them and want to communicate what you’re installing on their devices.

Non-release notes communicate the opposite: you don’t respect them and don’t care if they know what you’re installing on their devices or not.

Interrupting users is a bad user experience

Apps that don’t include release notes tend to announce new features by opening a screen that requires the user to read and/or dismiss it before using the updated app.  When a user runs your app, they’re trying to do something; That is not the right time to share your new features. What is the right time is when they’re reading through their app updates to see what’s new.

Releasing frequently wastes time

A suite of well-known apps states in their release notes, “we release updates weekly”. Why? You’re not releasing anything important enough for release notes, yet it takes the App Store’s reviewer’s time to check your update, it takes user’s bandwidth and time to download the update, and it takes your power users’ time to read “we release updates weekly” every week.

Release notes improve sales

I’m a power user. People ask me for help and recommendations. Apps that have release notes, especially clever ones, I remember and like more than apps that don’t tell me what they’re updating.  (If they don’t tell me what they’re updating, I assume they’re updating something they don’t want me to know about, or that their development process is so sloppy that they just don’t know what’s in each update).  As a result, I’m far more likely to recommend an app with release notes and to inversely recommend against an app that doesn’t have release notes.

Release notes increase user engagement

Power users, if not all users, read release notes periodically.  These all appear in a convenient list in the Updates section of the App Store (on iOS, not sure about Android).  If users read something interesting in the release notes from an app they haven’t used or have forgotten about, they may open the app to see what’s new.

Conversely, as I’ve written about before, users are likely to delete an app if they’re not using it extensively and see vague statements like “we update our app regularly” as the release notes.

Multi-Version Media format

Make living music albums. Make movies that don’t always end the same way.

The multi-version media format is a simple, cross-platform package file format that allows developers to write audio/video applications in which the media being played (eg a song or movie) can be a different version with each play. See the Amber G. App (iOS only) for the first such player (for which I developed the format 🙂 ).

Each media file (e.g. an MP3, M4A, MP4 or MOV file) is replaced by a specially-formatted directory containing multiple versions of the same piece of media (eg multiple live versions of a song, versions of a movie with alternate endings or extended scenes).

Format

  • <media name>.mvm
    • media_list.json
    • <file version>.<extension>
    • <file version>.<extension>
    • <file version>.<extension>
    • ...

Example for the song “Alive” by Amber Griis:

  • Alive.mvm
    • media_list.json
    • Alive.mp3
    • Alive live drums.m4a
    • Alive crazy rock drummer.mp3

media_list.json

This file contains a specially-formatted JSON object that describes the contents of the directory.

[ 
    { "Name" : "Alive", "File Type": "mp3" },
    { "Name" : "Alive live drums", "File Type" : "m4a" },
    { "Name" : "Alive crazy rock drummer", "File Type" : "mp3" } 
]

Playlist.json

This file sits at the root level of the directory in which your .mvm folders sit and simply contains a list (an array), in the order in which they should appear in a playlist, of the names of the folders in your player.

Example:

[ "Alive", "Fly", "Be In Love" ]

Note that this means your folder names must match what you want displayed. This is intentional to provide simplicity by convention.

“We update our app regularly” = delete

I read app release notes because I like to see what an app’s capable of doing. I’ve noticed that some apps have gotten lazy recently and just put something like “we update our app regularly”. When I see that, if I’m not actively using the app, I delete it. If I am actively using the app (I’m looking at you, Dropbox and Facebook), I try to think of other apps I could use instead (e.g. OneDrive, Google Drive, and heck, “nothing” sounds like a good Facebook replacement). See, I feel insulted that they want to just shove new code over my Internet connection onto my device when their changes aren’t even important enough to include in a text file they push to iTunes Connect. So, developers, if your release process is so agile that you release updates regularly, then track what you’re releasing and add it to the notes. Otherwise, I think your release process is crap and I’ll delete your app to keep said crap off my devices. 

Update 7/6/16: The Dropbox app is currently rated 2 of 5 stars in the App Store, despite being a great sync service and listed in The App Store’s “essentials” list. Why? No release notes. 


Oh, and I did delete Facebook (I highly recommend doing so), and switched from Dropbox to iCloud Drive. 

How to replace meetings and improve efficiency

Meetings Are Inefficient

A 5-minute status meeting uses about 35 minutes of productive time for each person in the meeting or on the call.  Meetings are also a poor way to communicate ideas, unless you have a white board, someone taking pictures of the white board, and someone carefully capturing and organizing all the notes from the meeting.  Still, you’ll usually end up with decisions based on the loudest person in the room.

Fortunately with today’s technology, there is a better way.

These techniques apply equally to calls and in-person meetings.  Since remote work is more efficient to begin with, I’ll use “calls”.

Replace The Status Call

This is probably the worst offender of time-sucking.  The 5 minute status or “scrum” call takes about 35 minutes of time for each person on the call.  Imagine: you’re working on something, but at 2pm you have a call.  At about 1:45 you check the clock – there isn’t really enough time to start into a new task, so you putter and find things to do until the call. After the call, you need to get back into what you were doing, which takes another 15 minutes.

There are far better ways to communicate status, which I’ll cover in order from best to least best:

  1. Use a shared task management system like JIRA, Bugzilla, FogBugz, Clarizen, Asana, or Trello (that’s in my order of preference, if you’re looking for a tool to use).  Any tool that lets you create a task, assign it to *one* person, and enter comments will do. Entering time worked and remaining time estimate is a plus. Ability to link tasks in a parent/child relationship is a major plus (JIRA, Bugzilla, FogBugz and Clarizen all do this).
    • Have each person enter notes as they work on a task. Use the lottery clause: “If you win the lottery tomorrow, will someone be able to look at your notes in the task and pick up where you left off?”. At least, have them enter a daily status as a comment. At slightly more than least, have them enter the approximate hours worked on the task and the approximate time remaining. You can make this precise and use it as a timesheet if you like, but in most instances you’ll want to use it as a rough, real-time gauge of how the task is progressing.
  2. Use Email. Send an email to your team (or whoever you would have had on the status call). Or just have them email you daily status, if they’re disciplined enough. I think it’s better to start the discussion though – that way people are just replying and don’t have to remember on their own. Remember: you want them focusing on their work, not on email. Here’s a sample email.

    Subject: Daily status “call”!

    Please reply all with what you worked on, what you’ll work on next, and if you have any blockers!

    Make sure you prepare your team for this – don’t just ambush them with a status call email. For example, if you’re having daily calls already, say “to save time and let you focus on work more, I’m going to try switching this call to a daily email. I’ll email you at the same time as the call – reply with your status, like you would on the call. This way we can all reply when convenient instead of dropping everything for the call”. Keep the same tone in the email that you would in the call. e.g. joke as you would on the call, be serious if that’s your team’s culture, etc.

  3. Use a chat room. I shy away from Instant Messages in general (because they interrupt work), but if you’re using an IM client or a chat room to connect a team (local or virtual – I’ve done it in both environments), it’s a good forum for the daily status call. Just do it the same way I suggested for email above: At a specified time, post “daily status call! Please post a sentence or two about what you worked on, what’s up next, and if you have any blockers!” in the room.

If you have someone who doesn’t provide status, or if you need more status, follow up with them directly (via email or your task manager system). Think if them as someone who missed the call.

Replace The “Discussion” Call – Scheduler

A lot of meetings are “let’s discuss (project scope, ideas for new product, what to do for Kathy’s birthday)”. Or worse, they’re scheduled because someone doesn’t know something so they want to get people on the phone to discuss the something.

I’ll approach this first from the standpoint of the scheduler – you’re the person who wants to discuss something, so you’re going to schedule a call. Stop, prepare, and back off that meeting invite. 🙂

First, what’s the desired outcome of the meeting? A document defining the scope of a product? A document defining a workflow for your coffee ordering process? A group consensus on the color of frosting for someone’s birthday cake?

Then, make a Google Doc (or drawing, or “slides”, but doc is usually best). Put in any information you have. If you’re not sure what to put in, imagine you’ve just started the call: what would you say? Type that into the document. Share it with the people who would be on the call, and invite them to edit and comment on the document.

Google Docs provides an amazing forum to discuss and create. The document serves both as a whiteboard and as a discussion forum. Using the “comment” feature, users can highlight sections of the document and ask questions or, well, make comments. This is the same process that would happen in a well-run meeting: You’d present ideas on a board (or slides), people would discuss verbally, someone would write the ideas from the discussion down, and you’d end up with a final document (which usually someone would have to compile later and email to the team). In a Google Doc, you can do this entire process in one document, stay focused on the emerging document, and achieve the actual outcome without post-processing. The entire process can be done asynchronously (that is, not everyone needs to be available at the same time). The lets you take advantage of people in different time zones (the UK office can edit while you’re sleeping and vice versa). The document also tracks revision history – who changed what and when – so you can drop back to an earlier revision if someone messed up your brilliant idea or see who changed the header to “Dodgers suck!”.

Replace the “Discussion” Call – Invitee

To: Half the office
HOLD: Discuss Feature Scope Kickoff
When: Thursday, middle of lunch until half-past when you were going to do actual work

I’ve covered how to not schedule the “discussion” call, but what do you do if someone invites you to one?

Reply to the meeting invite with the following template. Update your response as appropriate based on the invite.

Hi _____?,

So I can best prepare, can you provide me with a list of things we'll be discussing at the meeting?  Also, is there anything specific you need from me on the call? *

If/When the scheduler replies with the things you’ll be discussing at the meeting, respond to those things via email. e.g. if he/she says “I want to discuss the scope of the widget project and I’d like your input”, reply with the scope, e.g. “I think it’ll take about 5 days, unless we have to ___, in which case add another 3 days”. Then ask, “Is there anything else you need from me on the call?”

This dialog will often kill the need for the call.  If it doesn’t, it’ll at least hone in your purpose for being on the call, so the call time will be as productive as possible.

* Template from The Four Hour Workweek by Tim Ferris, mostly – I may have made minor alterations over the years.  I keep it in a TextExpander snippet.