Somewhere around minute twenty of almost every product management podcast, a guest leans back and says something like "so the way we think about prioritisation is really a two by two", and then spends three minutes describing four boxes with their hands, and the listener on a treadmill or in a car is trying to hold an imaginary grid in their head while the host nods along, right, and that is the exact moment a good product show either becomes useful or becomes background noise.
Product people love frameworks, and they love demos, and they love hearing how another PM handled the roadmap fight they are about to have themselves, so the content of these shows is often excellent. What lets them down is that the format leans on visuals the edit never supplies, so here is how we think about editing a product show so the ideas actually land on screen.
Why do product podcasts lose viewers when the frameworks come out?
Because frameworks are visual ideas described in words, and without something on screen the viewer has to build the diagram in their head, which most people quietly stop doing after the second box.
When a guest explains a prioritisation matrix, an opportunity tree or a funnel, they are describing a picture, and the people watching the YouTube version can see two faces talking but not the thing being talked about. Audio listeners have it worse, right, though they at least expect to work harder. The fix is not to cover the whole episode in motion graphics, which gets distracting fast, it is to draw the framework at the moment it is introduced, keep it simple, and let it sit on screen long enough for the explanation to catch up.
On Pixel Samy Podcast, the editor who builds that graphic is the same person who has listened to the whole conversation, which matters more than people think, right, because the guest often names the framework in minute twenty, corrects themselves in minute twenty two and refers back to it in minute forty, and the graphic needs to reflect the corrected version and reappear when it is referenced again.
How should a framework appear on screen?
As a clean, simple drawing that builds in the same order the guest explains it, matched to the show's own colours and type, appearing beside or over the speaker rather than replacing them entirely.
The pattern that works best for product content is the build. If the guest is explaining a two by two, the axes appear first as they name them, then each quadrant fills in as they talk through it, so the picture and the words arrive together and the viewer never reads ahead of the speaker. A finished diagram dumped on screen all at once tends to make people pause the video and read, which sounds good but usually means they lose the thread of what is being said.
For instance, a guest describing a discovery process in five stages gets a row of five labelled steps that light up one at a time, and when the host later asks about stage three, that same row comes back with stage three highlighted. It sounds like a small thing, right, yet it is precisely the kind of continuity that makes a product show feel considered. I wrote about keeping on screen text calm in why lower thirds should be boring, and the same restraint applies to framework graphics, and the trade off between reusable and bespoke designs is in my post on templates versus custom graphics.
What should happen with a live product demo inside an episode?
Record the screen separately at full resolution and send that file with the camera footage, so the editor can cut the demo in cleanly, zoom on the part being discussed and keep the host's commentary in sync.
A demo filmed by pointing a camera at a laptop, or captured as a shared window inside a video call, almost always ends up unreadable on a phone, and a demo nobody can read is worse than no demo, because it signals that the detail did not matter. When the screen recording comes in as its own file, we can crop to the relevant area, hold on the important click for a beat longer, and switch back to the speakers' faces when the conversation moves on.
The catch I would mention is confidentiality, so do check before recording that the demo does not show customer names, internal dashboards or features that have not shipped, because something can be hidden in the edit, yet it is far safer when nothing sensitive was captured in the first place. If you are building the show for a software company, the page for SaaS founders covers how product episodes support a wider company content plan, which I will not repeat here.
Chapters for every topic, because product people skim
Product managers rarely watch a long episode from top to bottom, they jump to the section that matches their problem this week, so a chapter for every distinct topic turns the episode into something closer to a reference library.
A typical product conversation covers five to eight separate subjects, discovery, prioritisation, a stakeholder story, metrics, a hiring question, and each of those deserves its own marked starting point. On YouTube those markers become video chapters, visible on the progress bar and in search, and the same timestamps go into the show notes for Spotify and Apple listeners. We write these as part of show notes and chapters, done by the person who edited the episode, so the chapter titles describe what is actually discussed rather than what a transcript guessed it might be.
The detail I always push for is chapter titles written in the viewer's language, right, and not in the guest's. A chapter called "the Q3 thing" means nothing to someone browsing, while "Saying no to a sales led feature request" tells a PM instantly whether to jump there.
How do guest PMs from other companies change the edit?
Guest product managers are usually careful about roadmaps, unreleased features and internal numbers, so the edit has to catch anything they would regret, and the guest should see the cut before it goes live whenever specifics came up.
Product people talk shop, that is what makes the conversation good, and in the flow of it a guest might mention a launch date, a churn figure or a competitor they are watching. Our editors listen through every minute, so when something like that comes up we flag it in the first cut with a timestamp and let you decide with the guest, rather than making a quiet call on their behalf. I am pretty sure that habit is a big reason guests say yes to a second appearance, because they trust the show not to embarrass them.
On top of that, guest PMs often join remotely from wherever they work, so their audio and picture need matching to yours, and a show with a rotating cast of guests needs consistent lower thirds and titles so every episode looks like it belongs to the same series.
A product show should respect the viewer's time the way a good product does, show the thing, label it clearly, and let people jump to what they need.
What should a product host send before recording?
A short prep note listing the frameworks, tools and product names likely to come up, any slides or sketches the guest plans to reference, and the show's colours and fonts, because graphics built from real source material are faster and far more accurate.
Guests in product often have a favourite diagram they have drawn a hundred times, in a talk, a blog post or an internal deck, and if they share it beforehand we can redraw it in your show's style rather than reconstructing it from a verbal description, right, which is where small errors creep in. The same goes for product and company names, which transcripts love to misspell, and for any acronym your guest uses that the audience may not know, since a quick on screen label for something like a north star metric saves a whole tangent.
If the show already has a look, share a few episodes that represent it and we carry the intro, type, colour and pacing over, so regular viewers never notice a new editor arrived. If it is new, tell me who the audience is, junior PMs, product leaders or founders, because that changes how much we explain on screen and how fast the cuts move.
Frameworks also make some of the best short clips a product show can post, a guest drawing one clear idea in ninety seconds, and we cut those as captioned verticals at 25 dollars each, which our shorts and clips page explains in more detail. The graphic built for the episode can travel into the clip too, right, so the short version explains itself even to someone who never saw the full conversation.
Budgeting for a graphics heavy product episode
Because product episodes lean on custom graphics, most shows sit on the Studio plan, 299 dollars for a single episode of up to an hour, which covers multi camera cutting, lower thirds and custom graphics, with show notes and chapters as a 35 dollar add on.
A show built around frameworks can take an extra day compared with a simple conversation, and when an episode is graphic heavy we tell you that before we start, so your publishing date is planned around reality rather than hope. If the show runs every week, the monthly plan brings the per episode price down, and the full set of options is on the pricing section. Unused episodes on a monthly plan roll forward a month, which is handy when a release cycle swallows your recording time, and there is no retainer to escape from if the show ends.
When you probably do not need us
If your show is a casual audio chat between two PMs with no frameworks, no demos and no plan for YouTube, a good audio editor or even a careful automated cleanup may be all you need, and paying for custom graphics would be wasted money. If your company has an in-house design and video team that already produces product content, they can handle the graphics with full access to your brand assets and unreleased designs, which an outside team cannot see. And if you record one episode a quarter, a freelancer per project is a reasonable route. Does any of that sound like your show, or is yours the weekly, framework heavy kind?
We fit best, right, when the episodes are visual by nature, published regularly, and hosted by someone who wants the frameworks drawn properly rather than waved at. The post on editing tech podcasts is worth a look too if your show leans more toward engineering than product.
Draw the thing being discussed
The whole idea fits in a sentence, really, which is that a product podcast is full of pictures being described in words, and the edit's job is to draw them at the right moment, label every topic so people can skip to it, and protect the guests who shared more than they planned to. Get those three habits right and the show stops being something PMs half listen to and becomes something they send to their team. If you have an episode recorded already, send it over before your next recording and I will show you exactly where I would put the first framework on screen. So yeah. That's my way of saying it.