The competitor teardown: turning a rival's YouTube channel into a feature-gap spec

A competitor we were tracking had no public documentation, no pricing page that gave anything away, and a sales team that would only demo to people who passed qualification. What they did have was a YouTube channel: roughly forty product videos, webinars and feature announcements, most of them screen-recorded walkthroughs of the actual software.

That is a feature spec sitting in plain sight. The problem is that watching forty videos at human speed, taking notes, and turning them into something structured is two days of mind-numbing work, and nobody on the team wanted to lose two days to it.

So we did not. We pointed Claude at the channel, had it sample a frame every five seconds across every video, and gave it back a structured inventory of every screen and capability the competitor demonstrated, diffed against our own product. The whole thing ran in an afternoon and cost less than a team lunch. This is the recipe, the prompts, and the parts that needed babysitting.

The shape of the workflow

The instinct most people have is "can I just paste a YouTube link into a chatbot and ask what features it shows." Sometimes you can, for one short video. It falls apart at forty, because you lose structure, you cannot control sampling, and you have no audit trail back to the frame a claim came from. For an analysis you are going to put in front of your team and base roadmap decisions on, you want something reproducible.

The pipeline has five stages, and each one is boring on its own, which is exactly why it automates well. You pull the video list. You download the videos. You sample frames at a fixed interval. You send batches of frames to a vision model with a strict extraction prompt. You merge the per-frame output into a deduplicated feature inventory and diff it against your own. The cleverness is not in any single stage. It is in keeping every claim traceable to a timestamped frame so the output is something you can trust rather than something that reads well.

Stage one and two: get the videos

yt-dlp does both jobs. List every video on the channel first, eyeball it, then download only the ones that are actually product walkthroughs rather than recruiting clips or culture reels.

# list the channel's videos as a clean table of id + title
yt-dlp --flat-playlist --print "%(id)s  %(title)s" \
  "https://www.youtube.com/@competitorhandle/videos" > videos.txt

# download the ones you want, capped at 1080p, into ./raw
yt-dlp -f "bestvideo[height<=1080]+bestaudio/best" \
  -o "raw/%(id)s.%(ext)s" \
  --merge-output-format mp4 \
  $(grep -E "walkthrough|demo|feature|how to" videos.txt | awk '{print $1}')

While you are here, pull the transcripts too. Half of what a competitor tells you is spoken over the screen ("and this is where our new forecasting engine kicks in") and never appears as on-screen text. yt-dlp --write-auto-subs --sub-format vtt --skip-download gives you the auto-captions per video, which the model can read alongside the frames.

Stage three: sample frames

Five seconds is the sweet spot for screen-recorded software demos. Faster and you drown in near-identical frames and burn tokens; slower and you miss the quick clicks where a menu opens and closes. ffmpeg does it in one line per video.

mkdir -p frames
for v in raw/*.mp4; do
  id=$(basename "$v" .mp4)
  mkdir -p "frames/$id"
  # one frame every 5s, scaled to 1280 wide, named by sequence
  ffmpeg -i "$v" -vf "fps=1/5,scale=1280:-1" -q:v 3 \
    "frames/$id/%04d.jpg" -hide_banner -loglevel error
done

A forty-minute video at one frame per five seconds is about 480 frames. Across the channel you will land somewhere in the low thousands. That is fine. The next stage handles them in batches.

Stage four: extract with a strict prompt

This is where the analysis lives, and where most people get a result that looks impressive and is quietly useless. The failure mode is a model that pattern-matches "this is a SaaS dashboard" and invents plausible features that were never on screen. The fix is to forbid it from reporting anything it cannot point to, and to make it cite the frame.

Send frames in batches of fifteen to twenty per call, grouped by video so the context stays coherent, with this system prompt:

You are a product analyst doing a competitor teardown. You will receive a batch
of screenshots sampled every 5 seconds from one product demo video, in order.

Report ONLY what is visible on screen or stated in the supplied transcript.
Never infer a feature from the type of product. If you cannot see evidence of
it in a specific frame, do not report it.

For every distinct feature, screen, or capability you observe, output one JSON
object: { "feature": short name, "evidence": "frame 0042", "category": one of
[reporting, data-entry, integrations, admin, collaboration, AI, billing, other],
"verbatim_label": the exact on-screen text if any, "confidence": high|medium|low }

Merge obvious duplicates within this batch. Return a JSON array, nothing else.

Then a user message with the batch: the transcript chunk for that timespan, followed by the frames. Claude is good at this because it can actually read small UI text and hold twenty images in context at once. The verbatim_label field is the anti-hallucination seatbelt: if the model claims a "Scenario planning" tab, it has to give you the literal text it read, and you can spot-check that against the cited frame in seconds.

A small Python loop drives it. Read each video's frames, chunk them, attach the matching transcript window, call the API, append the JSON to a per-video file. Nothing fancy, and it is restartable if a call fails halfway.

Stage five: merge, dedupe, and diff

Now you have a few thousand raw observations with duplicates everywhere, because the same dashboard sits on screen for ninety seconds and gets reported eighteen times. One more model pass collapses them.

Here is a JSON array of raw feature observations from a competitor's demo
videos, each with an evidence frame and a verbatim label. Collapse them into a
canonical feature list. Group near-identical entries, keep the clearest
verbatim label, and keep one representative evidence reference per feature.
Output a JSON array sorted by category, each: { feature, category,
verbatim_label, evidence, video_count }.

video_count is the quietly useful one. A feature that shows up across eight videos is something they sell hard. A feature that appears once in a two-year-old webinar might be abandoned. The frequency tells you what the competitor thinks matters, which is its own intelligence.

The final move is the diff. Feed the canonical list alongside your own product's feature inventory and ask for three buckets: what they have that you do not, what you have that they do not, and where you reach parity. If you do not have a tidy inventory of your own product, you can generate one the same way from your own demo videos or by pointing Claude Code at your app's routes and components. We did the latter, which had the side benefit of surfacing two features of our own that we had built and forgotten to market.

What broke, and the gotchas

The first pass over-reported. Before we added the "never infer from product type" instruction and the verbatim_label requirement, about a fifth of the reported features were hallucinated category-typical guesses. Forcing a frame citation and the exact on-screen text killed almost all of it, and the few that slipped through were trivial to catch because we could open the cited frame and see nothing there.

Marketing slides are noise. Competitor videos open with thirty seconds of logo animation and customer-logo walls, and the model dutifully reports "customer logos: Acme, Globex." Either trim the first and last frames of each video in ffmpeg, or add a line to the prompt telling it to ignore title cards, testimonials and pricing-tier marketing and report only the working software.

Spoken features need the transcript. Several of their strongest capabilities were never shown clearly on screen but were described in voiceover. Without the captions feeding in alongside the frames, we would have missed them entirely. This is the single highest-leverage addition to the whole pipeline.

Watch the token spend, but do not fear it. A few thousand frames sounds expensive. Batched at fifteen to twenty images per call it came in under the cost of a single analyst hour, for a job that would have taken sixteen of them. The economics are not close.

And the obvious one: respect the platform's terms and use this for analysis you are entitled to do. Watching a competitor's public marketing and taking structured notes is something every product team already does by hand. This just does it faster and writes the notes down properly.

Why this is the actual point

The reason we teach this kind of workflow in the Moonlabs Academy and run it inside our own companies is not the competitor teardown specifically. It is the pattern underneath it. There is an enormous amount of unstructured signal sitting in plain sight around every business you compete with, in video, in PDFs, in recorded talks, in support forums, and the cost of turning it into structured, decision-grade data used to be human attention you could not spare. That cost has collapsed. The teams that internalise this stop treating "we'd need someone to watch all of that" as a reason not to know something.

We knew more about that competitor by dinner than their own junior PMs probably do, and we knew it in a format we could act on. The videos were always there. The only thing that changed is that watching all of them stopped being expensive.

James Freestone is a co-founder of Moonlabs, the operator-led AI incubator and academy. Moonlabs builds and funds AI-first companies, and teaches the operator workflows behind them. Site: moonlab.ventures.