How to use Claude AI for product research (the methodology that actually works)

Most teams using Claude (or any frontier LLM) for product research are doing the same three things: paste a webpage, ask "summarize this", save the bullets to Notion. It feels productive. It produces nothing you can actually build from.

The problem isn't Claude's capability — it's the prompt. A summary is a compression. Product research is the opposite: you're trying to expand a vague hypothesis into a concrete, defensible brief backed by evidence. That requires a methodology, not a single prompt.

This is the methodology we use internally — battle-tested across finance, dev-tools, and B2B-sales research projects — and it's the same one our product (YouTubeToSaaS) automates end-to-end. Even if you don't use our tool, you can run this manually with Claude Pro and a few hours.

Why "summarize this" fails at product research

A good product brief answers four questions:

1. What do real users actually do (not what they say on a survey)?
2. Where do credible voices disagree on what works? (Disagreement is signal — it's where defensibility lives.)
3. What claims are hype with no evidence behind them? (You'll waste months building toward those if you don't filter them out.)
4. What's the smallest thing you can ship that proves the real opportunity?

A summary erases #2 (it averages disagreements into a single consensus), hides #3 (verbose hype reads identically to verbose truth in a 200-word digest), and never reaches #4 because it's still operating on the input layer.

We watched ten developers describe their workflow on Loom. Eight said "we use TypeScript everywhere." Two said "we tried, it didn't stick. Here's the file we deleted." The two were the signal.

Step 1 — Scope the question, narrowly

The output quality of any LLM is bounded by the specificity of the input. "Research the AI agents space" produces wishy-washy output from any model on any prompt. You need a question that can be falsified.

Notice the pattern: a scope-able question names who, what they do, and what would convince you the answer is wrong. If you can't write a one-line falsifier, the scope isn't tight enough yet.

Step 2 — Gather evidence that has skin in the game

Surveys lie. Tweets are performance. Blog posts pump products. The evidence types that don't lie are:

• Long-form video where someone shows their actual screen running real software (the cost of faking a 90-minute screen recording is too high; people don't bother)
• GitHub issues and PRs on relevant repos — the complaints are unfiltered
• App store / Product Hunt comments over 30+ days (initial-launch reviews are too noisy)
• Reddit threads with 100+ comments on niche subs — there's a critical mass for honest disagreement

For most builders, YouTube is the densest source: long-form, screen recordings, real numbers, and creators with a reputation cost for getting it wrong. We found that 15–20 well-chosen videos in a niche produce more usable signal than 50 blog posts.

Step 3 — Extract structured signal, not summaries

For each source, run Claude with a schema, not a prompt that says "summarize". This is the move that separates 10x results from generic ones.

You are analyzing a single video transcript. Extract structured signal — not a summary.

Return JSON exactly matching this schema. Be specific: "they used pgvector" beats "they used a database".

{
  "main_thesis": "<one-line claim the creator is making>",
  "tools_mentioned": [{"name": "...", "purpose": "...", "creator_endorses": true|false}],
  "workflow": [{"step": "...", "input": "...", "output": "..."}],
  "claims_with_evidence": [{"claim": "...", "evidence": "screen recording | code shown | dollar amount | A/B result | other"}],
  "claims_without_evidence": [{"claim": "...", "why_no_evidence": "..."}],
  "open_questions": ["<things the creator didn't address but a builder would need to answer>"]
}

Two things make this work. First, the JSON schema forces Claude to commit to specifics — it can't hide in fuzzy prose. Second, the explicit claims_without_evidence bucket teaches the model to be skeptical, which generic summary prompts never do.

Step 4 — Synthesize across sources

This is the step everyone skips. Once you have 15 structured per-source outputs, the magic comes from running a second Claude call that operates on all of them at once.

The synthesis prompt should ask for four specific things:

1. Repeated patterns — claims that appear in 3+ sources, ideally with explicit evidence in each. These are your candidate truths.
2. Conflicting opinions — places where credible sources disagree. Each side gets quoted with its evidence. This is where your defensible wedge lives.
3. Hype signals — claims advanced enthusiastically with zero evidence ("10x faster", "30-second setup", "changed everything"). List them by name. You'll be tempted to build toward these. Don't.
4. Technical failure modes — production-level things that broke for someone, with the specific trigger. "Token limit hit when processing > 90-minute videos" is a failure mode. "AI is unreliable" is not.

Step 5 — Produce the buildable brief

The final output of product research isn't a Notion page. It's a document an engineer (or a Claude Code agent) can read and start building from immediately. The structure matters:

• Project mission — one sentence, no jargon.
• What we learned — split into proven, experimental, and hype.
• Defensible wedge — one specific positioning competitors miss, named.
• MVP features — the smallest set that proves the wedge.
• Failure modes — at least 4, with mitigations.
• Do not build yet — the things every other source said to build but the evidence doesn't support.

If you skip the "do not build yet" section, you'll burn months chasing the loudest claims in your corpus. Whatever shows up there is, by construction, the most tempting and least supported.

Common pitfalls (and how to avoid each)

1. Recency bias

Don't only watch what came out last month. The best research mixes recent claims with one or two reference videos from a year+ ago. If the year-old approach still works, that's signal. If it doesn't, understanding why is signal too.

2. Single-creator confirmation

Two videos from the same creator are one source, not two. Even if the creator is excellent, you're getting one perspective on the question. Diversify by name before you diversify by topic.

3. Letting the model write the brief in prose

Long prose hides hand-waves. Force structured output with named sections. If a section is empty in the output, that's information — either the corpus didn't cover it or the model couldn't extract it with confidence. Both are useful.

4. Stopping at synthesis

The synthesis isn't the deliverable. The brief — the thing an engineer can build from — is the deliverable. If you handed it to someone who has never used Claude, could they begin coding tomorrow? If not, you stopped early.

Closing thought

Claude is excellent at product research when you give it a job description, not a pile of documents and a "summarize" button. The job description is: find what's repeated across sources, what's contradicted, what's claimed without evidence, and what would break in production. Then write a brief I can build from.

That methodology is the entire reason the YouTubeToSaaS pipeline exists. If you'd rather skip the prompt engineering and the cross-source synthesis math, the product runs all five steps above automatically — including the failure-mode enforcement and the defensible-wedge detection.