So You Want to Produce A Podcast? Part Two: Topic and Control

For each of the areas in my introductory "5000-foot view" post, I will take some time and dig deeper into them and provide a little closer look at each region. Warning, this may get messy as we continue.

All successful podcasts tend to hang on a central theme. That theme can vary wildly and cover a  lot of different areas, but there should be some anchor point that you as a show producer can draw on. Some of my favorite "wide net" podcasts are "Stuff You Missed in History Class" and "Stuff You Should Know" both from HowStuffWorks.com. Their format allows them to cover a huge array of topics, and with that, there's the high probability that such a broad range will not hook every listener. By contrast, a focus on a very specific niche area, like Joe Colantonio's "Test Talks" Test Automation Podcast) or Ruby Rogues, means that you are likely to be hitting areas that you are familiar with and comfortable with, but also run the risk of hearing things you have heard before. In my opinion, the more niche the show, the less likely one or two people will be able to do it justice. Unless you are a genuine super-nerd on the area in question, and you can go into great depth on the topics you are covering, it's much harder to produce solid shows with only one or two people talking. Guest contributors make this kind of a podcast essential. By contrast, covering something broad or that changes week to week means that you can riff on it and provide your own thoughts and opinions and keep things fresh.

Regardless of the topic areas that you choose to cover, you will have to do your homework for any given show. If you invite a guest on the podcast, it's always a good idea to do some research on what they've done in the past, what their level of expertise is, how they acquired it, and get them to open up and share their journey to where they are today. Even if you are not appearing "on mic", if you have thoughts or ideas, or questions you would like to get covered, make sure the participants know about them. If you have the time to do so, compile a list of questions you'd like to ask your guest and send them to them in advance. You don't have to go by a set script, but by giving them heads up on the areas that you are interested in, they can answer back and either give you more areas to consider and broaden your questions or let you know ahead of time where there might be better resources for those questions. Either way, it helps you tailor what you ask your guests or, barring that, what you choose to ask yourself as you discuss those areas.

As a show producer, if you are appearing on air, one of your jobs is to be the show runner. With "The Testing Show", I usually defer to Matt Heusser when he's on to be the moderator of the discussions, but I take the lead to manage the topics and "watch the clock". This is an important part of topic and voice, and that's to make sure that all participants keep focused. That's not to say that a good conversation should be abruptly stopped, but as show runner, I need to make sure that I'm not going to have to be heavy handed about editing, so I tend to remind people of our timing.

Many podcasts are free-form, and they go as long as they feel like going. Some people do this better than others. One of my long time favorite podcasts is "Back to Work" with Merlin Mann and Dan Benjamin. Suffice it to say, every episode is long, an hour plus, sometimes as much as two hours. There is a lot of banter in their shows like two old pals just talking about whatever comes to mind. They use a lot of inside jokes, and it takes awhile to get to the topics, but they do so, and they make it engaging. Other shows I have heard don't do this quite as well. It's important to decide on your tempo, and how you want to achieve it. The Testing Show has settled on a general format, and we reached this format after discussions with our sponsor, QualiTest. We decided that the average show length would be 30 minutes. Sometimes they are shorter, sometimes a little longer, but generally, we aim for that sweet spot of 30 minutes. We also tend to have a "news segment" at the start of each show, which allows us the opportunity to be open and casual discussing a current-ish topic. We post new episodes every two weeks. That makes what we think is topical sometimes seem like old news by the time it appears. With that in mind, we aim to cover news items that have broader messages and takeaways. That leaves us with twenty minutes to talk about the main topic. The advantage of a set times show is that we can keep the message tight and focused. The disadvantage, at times, is that it can sound shallow or not go into the depth that some listeners would want. We take these on a case by case basis, and if a topic is really deserving, or covers enough unique ground to warrant it, we will do a two-part episode. Generally, though, I prefer to keep the shows as standalone entities, so I try my best to help make sure that heavy editing is not required. Sometimes I succeed. Often, I don't, but that's its own post ;).

GEEK TRICK: I encourage anyone producing a show to keep a production schedule on hand. This is key as you go through recording episodes. Based on the queue of recordings, and your posting schedule, when will this current recording appear? We have had experiences where we have been very lean with guests. A recording we make might get turned around and uploaded to the feed within a week (definitely stressful, but the content is fresh and current). At other times, we have a backlog of recordings to work through. We have had shows recorded that didn't get posted as episodes until two months later. As a show producer looking at this schedule and being aware of the post dates for any potential recording can help you decide if it makes sense to record a show on a given date or wait until later. Sometimes, a guest has a really tight schedule and you will only get them for that time period. If that's the case, you may need to shuffle your backlog a little, so that that special guest can appear in your episode stream sooner rather than later. Additionally, when guests or panelists are talking about upcoming events, it really helps to have a clear window as to when the show will air. It makes no sense to talk about an appearance or an event that will have already happened. One exception to this is if the materials for presentations are going to be made public by the time the podcast appears. You can then make a note of their location in the show's transcription and show notes.

Another thing a producer should consider is if they will be willing to "correct" items "in post" (meaning as they are editing, they notice something that's either incorrect/outdated, or could use clarification). Personally, my preferred method is to use the show transcript and notes for this purpose, but occasionally, something will stick out. To avoid confusion, or add clarity, it will make sense to drop a comment into the show mid-stream. I recently did this with regards to a discussion that we were having about Socialtext current CI system. Though I wasn't on that show, there had been enough changes that I felt it warranted to drop a small voice recording in and clarify what we are doing currently.

It may take awhile for your show to "find its voice". It's tempting to think that you will go live immediately with your first recording as your first episode. I strongly encourage you to record a "Pilot" podcast first, to see if you like the format, and to see what you will have to do to produce the show you want to produce. We did this with "The Testing Show" and decided that the first recording was just too rough to go live with. We still have it, and at some point, we may post it as an example of "first steps" to show what we started with, and how we made changes over the subsequent episodes. I have heard several people make the recommendation to record five episodes, and then record episode six and label that one as the first episode, discarding the previous five. If you are a one or two-person podcast with the same people each time, that makes sense. If you are asking for guests to appear on your show, it's not cool to take up their time and then not post their contributions. Since we decided from the outset to be a guest driven show, we went live with episode two.

Are there any other questions or things you wonder about when it comes to developing the voice of your podcast, and how to "run the show" once it's recording time? If so, please leave questions below, and I will be happy to answer them, expand on them in this post, or write new posts to talk about them.

So You Want To Produce a Podcast? Part One: The 5,000 Foot View

I need to thank Saron Yitbarek. She posted a tweet that had me laughing last night, as she was talking about how she needed to edit a podcast, but that she was procrastinating the editing, and she wanted to write a blog post about podcasting instead.

Please forgive me misspelling #TheTestingShow in my reply. I was a little tired. Still, her Tweet has been rattling around in my head all day. What if someone who listens to The Testing Show wanted to start their own podcast. What would I tell them? How should they start? What should they do? How do you actually produce a show? Could I put this all into one post?

I decided the answer to that was "probably not", but I could do a series of posts about what I do as a quick and dirty tutorial about my approach as to how I edit and produce The Testing Show, so if you will indulge me, that is exactly what I am going to do.

First, you need a show, and to have a show, you need a topic. It helps if the topic is something you are nerdy about, has a direct connection to your professional life, or is otherwise something you would climb a mountain of people to do and, thus, talk about it with a passion. Hyperbole much? Maybe, but seriously, if you dig the topic in question, you will be motivated to make many installments, and that tends to encourage the commitment to keep making episodes.

Second, you need to decide how you want to present your show. Do you want to be a first person podcast, where you do all the talking? Don't dismiss this, as several of my favorite podcasts are exactly this. Dan Carlin's shows Hardcore History and Common Sense, Stephen West's Philosophize This, most of the podcasts on QuickandDirtyTips.com, and a new one that I am currently enjoying called The Ends, all of these shows have a single speaker/narrator and work well in this format. Upside: you can produce shows anytime you want to. Downside: it's all on you, and that means you have to provide all of the research, commentary, and thoughts. An interview or panel show add the elements of additional speakers and commentary. Upside: you get a variety of viewpoints. Downside: your ability to schedule everyone to record can be a logistical challenge, and the more people you want on the call, the greater the challenge. For The Testing Show, we have a rotating recurring cast. The general rule is that three of us together meet the minimum requirements to record a podcast on a topic, or two of us and a guest also meet that requirement. In a pinch, if we are remote or at an event, we will do a one on one interview with someone, but we strive to get three people into the conversation so there's some give and take.

Third, how do you want to capture your audio? For the time being, I will leave video out of the mix. I will also leave in person recording out (though the Voice Recorder apps on iPhone and Android are actually quite good, and I have used them in live settings to great effect). We're talking just an audio recording done with remote participants. If you'd like an inexpensive, but quite reliable, recording method, I recommend using Skype and the ecamm Skype Call Recorder. There are numerous recording options, but for now, focus on the voice-only option. The calls are saved as .mov files, and each file can be imported into your audio editor of choice.

Fourth, you need an audio editor. Which one you use is up to you. For the past seven years, I've used Audacity. It's got a lot going for it, and once you get a handle on how to use it, it can be very fast to work with. Truth be told, there's a lot of features that will feel like overkill, and if you want to record a podcast, 90% of the features will remain untouched, but I promise, the 10% that you do use you will use all the time, and they will become second nature to you (and as soon as they do, don't be surprised to find out that the number of "essential features" starts to creep up ;) ). Whatever you use, make sure that you can import the file types you save. Yes, I'm using a Mac, so I'm using Mac vernacular here. Once I've imported the Skype call as a .mov file, I am presented with a stereo track that has two channels. The first is the channel with just my dialog or the dialog of the person that recorded the call. The second channel is the dialog of everyone else on the call. If you want to go very clean and are willing to spend the time to do it, you can have everyone record their own version of the call, send you their .mov files, and you can import them all together.

GEEK TRICK: If you want to go this route, and you want to be a little cheap on the sync-up options, record a "beep series" at the start of the recording, and occasionally, during silences, insert the beep series again, as a standalone audio spot. Also, run the beep series at the end of the recording. Why? This series of beeps will be a visual cue when you import the audio files to help you line everything up. One you do that, split all of the stereo tracks into mono, then mute the secondary tracks that have multiple voices together. If you do this, you will get multiple first person recordings, made local to their systems, and the odds of removing drop outs and clicks/audio artifacts are much higher.

If you can't get a native recording from everyone, or if you are the only one able to do the recording (common if you ask a guest to be on the show; it's rude to ask them to shell out for software they may never use again), then you can import a single .mov file, split it into two mono tracks, and sync-lock the tracks together. This way you can select sections in each track to mute, and if you cut out sections of audio from one track, you will also be cutting the same time period in the other track.

GEEK TRICK: One of the easiest ways to do a fast condensing of a recording is to use the "Truncate Silence" feature. You enter in a minimal time limit that you want to search for (usually anything longer than a second), and you truncate all of that down to individual silences of one-half second. Why? This is a typical time space in average conversations. By reducing all silences to anything less than a second, you can take out several minutes from a podcast recording easily, with very little chance of cutting off something important. Along with this, if you listen to tracks and decide you want to cut sections, I suggest selecting the section and muting it first (meaning silence everything in that selected space, which on the Mac is Command-L, and Ctrl-L on the PC). By doing this, you can do a rough cut of your show, chop out the bits you know you're not going to use, then run Truncate Silence to squeeze everything together.

Another consideration; this is important when you decide to publish... do you want to have show notes? Do you want to have a Transcript? Do you want to have both? The Testing Show provides both show notes and a full transcript of the audio. I have tried a number of methods for this, and truth be told, I keep returning to this approach. Fire up whatever word processor you want to use in one window, and your editor in another. As you do your fine editing, type out your transcript in time with the second by second audio scrubbing you are doing. If you are not providing a full transcript, this will be overkill. If you are not doing what I refer to as "grammatical audio editing" (that's removing the "um's", ah's", like's", "you know's", and other vocal tics we all use when we speak) then again, this is overkill. If, however, you decide to provide both a grammatical audio edit and a full transcript, you might as well do them both simultaneously. You may incur a 15-20% overhead by doing both at the same time, but that's not bad, really.

GEEK TRICK: If you come across a comment that you think might need referencing in the show notes, either highlight it or insert an end-note and type a reminder text about that entry. Later, when you review the end notes, fill in the actual reference values or URL's to resource links. If you are online and can do it right then and there, all the better. Seriously, do this, and you will have produced 75% of your show notes. As to the pithy commentary to add as your "selling paragraph", that's an everyday struggle, but you will get better the more you do it. Seriously, though, I think I spend more time trying to get the introductory paragraph together at times as compiling all of the reference materials, and yes, I frequently feel like I'm an idiot as I review the text I've written, but over time, you just learn to roll with it. Sometimes, it works. Sometimes, it falls flat. So it goes.

Finally, you may want to spice up your podcast with music, inserted comments (bumpers) and some intro and outro comments. You may decide to do this differently each time, or you may want to standardize what I call "audio beds" that include these. For The Testing Show, our intro and outro music is provided by my band, Ensign Red. If you can make your own music, that will provide you with the ability to customize it as you need for your intros and outros or other uses. If you are not musically inclined, there are numerous sources of Creative Commons free use music samples that you can download and use. If you'd like to take the plunge, start with CreativeCommons.org and see what sounds interesting to you. It's good protocol to give credit to the artists whose music you choose to use in your podcast. Mention them in your show notes and in the podcast itself. It encourages discovery of their music and thus, makes them more willing to keep creating Creative Commons content.

So there you have it, a whirlwind look at creating a podcast. Have I left a lot of stuff out? Most certainly. Would you like to know more? I'm happy to share what I know and how I do it, partly because I know the challenges of getting started and how large a mountain that is. Also, I have a slightly selfish ulterior motive. My hope is that, by sharing these posts, and giving people a peek into my world of producing these shows, someone might comment back and say "you know, you could do this sequence of steps so much more efficiently if you just [fill in the blank]." Hey, it happens with code review all the time, so why not with podcast production review as well :)? 

Oh, and Saron, if you do publish that blog post, please let me know. I'd love to read it.