Select Page

How to make a kick-ass release deck

Jun 13, 2017 | Perspectives in Engineering, Productivity

With every software release, there’s a common functionality problem that no amount of coding or patching can fix. No engineering skills in the world will remedy it. It has nothing to do with the way your product functions.

Instead, the issue has everything to do with communicating your work to the rest of the company so that they can actually use it.

Software releases are typically communicated from engineers to other engineers. That’s why we end up with release notes: a bulleted list of one-liners describing the top tickets. But this type of rundown is wholly inadequate for educating the rest of the organization about what you just built. You might as well not announce anything.

This type of silent software release is also a huge disservice to the company. You miss the opportunity to make sure your intended audience understands how to use the software your team just improved.

Make sure your intended audience understands how to use the software your team just improved.

Instead, you need to showcase the update in a way your organization can digest quickly and effortlessly. Your customer service team or your sales team don’t give two hoots about what’s under the hood of your new software update. They just want to know how to drive it.

So your most effective tool is a simple, visually-driven release deck.

Collecting the Materials for the Release Deck

When you come out of release and start to build your deck, you’re not starting from scratch. Because guess what? Your engineers already have all the materials you need. A simple and effective strategy is to email every single person who worked on that release, in any capacity, and say, “Send over screenshots of your work.”

That’s it. That’s all you need to ask for.

The release deck should include the results of their work—the same things that the end users will see.

The deck doesn’t require explanations or justifications for why something was built. Users don’t want to know why the work is important. So you just need a screenshot. Show. Don’t tell.

Show (don't tell) why the work was important

Ideally, each engineer will pick one or two things that were the highlight of their cycle. You want the highest-visibility changes—the pieces that your organization will come in contact with. Navigational tools. Data input screens. (Note: these often won’t be the highest-value changes from an engineer’s standpoint.)

And then you want to deliver these features to your organization from their point of view.

The release deck should include the results of their work – the same things that the end users will see.

Building a Winning Deck

Would you like to know a super-low-tech secret to communicating your work effectively and quickly with a whole organization? It’s simple: share the information in a format and a forum they’re already comfortable with. And that format is PowerPoint.

Say what you will about PowerPoint. But the truth is that executives use PowerPoint every day of their working lives. It’s their language, which makes it your friend for building an effective release deck.

The good news for you is that you don’t have to spend a lot of time designing an intricate slideshow. Nobody would ever use a release deck as a measuring stick or a progress report. It’s simply a tool. It should feel lightweight and easy. And it should go quickly—an hour spent on assembling a deck is too much time.

It will be sloppy. It will look kind of ugly. And you definitely don’t need to worry about formatting.

A good release deck should have about 20-30 slides. That’s a loose number—feel free to come in a bit over or under depending on your specific situation. Expect a deck that size to take 30-45 minutes to put together. It will be sloppy. It will look kind of ugly. And you definitely don’t need to worry about formatting.

Each slide need only a few basic elements: a headline, the screenshot with big arrow pointing at the feature, and possibly a bullet point or two. That’s all they need.

Slide example one: Support Team - Filter Notifications

Slide 2: Customer-Facing - Date Selector

Once you have created all of the individual slides, you’ll want to spend some time organizing them so they are more digestible as a whole. You’ll figure out the best way to present the release deck for your organization. A common approach is to organize the slides by audience, with a separator slide for each major constituency. The first section may be “Customer Facing,” followed by “Customer Service” and “Marketing” and “Executive Team.”

This way, each group knows where to look and when to pay attention. And you show them all what they need to know. It’s like you’re passing out candy and you want everyone to get some.

Section groups, such as Support Team, Marketing, etc.

The Discard Pile – What NOT to Include

If the release deck is candy for your company, you don’t want to be the person handing out toothbrushes. You want to give them the good stuff and send them on their way.

That means you have to avoid the temptation to include any context. In fact, your deck should be devoid of context altogether. No explanations. No buzz words.

For instance, if you say you put in three tracking beacons, you don’t have to explain what a tracking beacon is. And if you say “We reworked the credit card screens for the customer service reps,” you don’t have to justify why that revision was important.

A few more things to avoid:

Don’t talk about your challenges. Don’t talk about the individuals on your team who did the work. The release deck isn’t about personal credit; some engineers worked on elements that just aren’t usable for one reason or another. And that’s okay.

After all, you’re designing the deck for the consumers’ point of view, presented as the product of engineering as a whole.

Dealing the Deck – The Presentation

Here’s an example release deck, so you can see a final assembled product:

If you’d like to download a copy of this example deck to customize and use for yourself, you can grab it here


The frequency of your release decks depends greatly on your team’s cadence.

If you’re a sprint-based organization and you’re releasing sprints every few weeks, then present a release deck at least every other sprint.

If you’re rolling thunder and you do a continuous release, consider a monthly roundup. Same if you’re project-driven: go for the monthly option.

This timing is in large part to keep you sane and manage your overhead. An hour a month is much more doable than an hour a week. And if you wait too long… well, quarterly is long enough for folks to forget about engineering, and your deck will get so long that they’ll want to forget you.

However often you present the release deck, though, make the event informal and high-energy. I like to take a 30-minute slot around lunchtime on a Friday to do a screencast. It’s direct and punchy, with a lot of rah-rah positivity. Anybody can come. And as soon as the presentation is finished, I distribute the deck as a PDF to the entire organization. Because it’s so light on text, it’s suddenly a simple reference tool on everyone’s phone.

And then you’re done, until the next cycle.

The art of the release deck is a pretty straightforward and effective craft. Your efficient decks are not only painting a backdrop of consistent delivery of services. They are also ensuring that the entire enterprise is able to benefit from the updates your team has developed for them.

And all for maybe an hour’s time each month. Deal me in.



John Witchel

John Witchel

John co-founded Prosper and has led technical teams for 20+ years. He is now the President/COO of GitPrime.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.