Engineering Requirements for Podcasts

I listen to a lot of great podcasts. Dan Benjamin and Leo Laporte in particular amaze me with the sheer volume of high-quality podcasts they're able to produce. But there are some podcasts with great content that I just can't listen to. Below are some ideas to help avoid losing listeners that want to hear your content.

The first thing you need to make a great podcast is great content. A lot of people are good at this part of the process, getting good talent, with well-defined topics, and a comfortable format. It's frustrating when some non-content gripe takes me out of the moment, making it hard to enjoy the content.

In the software design world there are functional requirements, which describe what the software is supposed to do: screens, buttons, calculations, etc. In a podcast, the content is the "function." Just as important, but often hidden from view are how software does its job: how fast, how often, how secure, how easy, etc. These are often called "non-functional," "technical," or "engineering" requirements.

Engineering requirements for podcasts aren't about the content — they're about the stuff around how you deliver your content. Below are some pointers on my engineering requirements for high-quality podcasts.

Get To It

This isn't radio — no one needs a minute-long intro. We all know which podcast it is: it's in the ID3 tag, your graphic is covering the screen of the audio player, and the user likely just selected it from a list. Your listener is more likely to have too many podcasts to fit into their spare time, so adding filler time isn't doing anyone favors.

A bad example comes, regrettably, from Leo Laporte's TWiT podcasts. Leo has a network intro, followed by an individual show intro, followed by a reading of the ID3 tag data, followed by short announcements of the sponsors, followed by a minute or two introducing the hosts and guests. Each is only a few seconds long, but it's generally 1m30s or 2m until there's anything that a listener may care about. And 2 minutes is an eternity when you're crushed on a subway train with nothing else to do but to wait.

A great example comes from Dan Benjamin's 5by5 network. His intros can last 5-10 seconds in total, often at the short end of that. And in an extreme example, he and John Gruber just start with no intro at all on The Talk Show. It's refreshing.

Don't Go Crazy With Live Ads

It's great to hear a skilled announcer read a live ad, and to spice it up with some embellishment. It can get too much when an ad becomes an impromptu testimonial from a guest. Often the guest rambles unprepared for minutes only to tell us that their dog Sparky likes the product. I'm sure the advertisers like this content — it's free and genuine. But as a listener, there is a limit where we reach for the slider to advance a few minutes.

Some bad examples are coming with Audible ads recently. The copy and embellishment is only a minute or two, but then a book recommendation — often unrelated to the show's topic — can take 5 minutes. If you just happen to line up with the tastes of the recommender, then it's decent content. But if it's unrelated to the podcast content, it's just a 7 minute boring ad. This is exactly why many listeners abandoned radio in the first place.

Dynamic Range

The main engineering requirement is audio quality. In 2006 I unsubscribed to many podcasts because the audio quality was low. Since then, the average audio quality of podcasts is stellar. I have only one remaining complaint that can make me hit fast-forward, and that's excessive dynamic range.

I listen to podcasts in one of two ways. One is with earbuds on a subway train, and the other is while driving. In both cases, there is a significant noise floor from the environment. Train noise and road noise are each enough to require jacking the volume on the podcast way up. Unfortunately, if there is a huge dynamic range, that means that laughs and outbursts can just burst eardrums. And no one should need to reach for the volume knob when someone decides to speak softly.

The essential requirement is that the user should be able to listen to the podcast without having to touch the volume knob more than once at the start. And this has to be true in a high-noise floor environment like a car. It's a sin to compress and "volumize" music to the point where you lose dynamic range, but on a mono voice-only talk show it's a requirement. Get the Levelator and try it out.

Produce For Audio First

If you release both an audio and a video version of your podcast, engineer for the audio podcast as the primary product. There shouldn't be dead audio air, or extended discussions about things "held up for the camera." The video content should just be purely extra content, not necessary content.

If the podcast really should be primarily video, then don't put out an audio feed at all. The few people that want audio only can just download the video and not watch as it plays. You won't be continually churning through listeners who find the audio feed, but get annoyed and soon unsubscribe. If you have no plans to make the audio a good standalone product, just don't release it.

The Listener Is Primary

Above all, think of the experience from the perspective of the listener. Make the listener happy, and worry about other considerations later. If you try to please advertisers at the expense of listeners, you'll lose both in the end.

Posted by Steve on 2011-03-27 17:04:00