Extracting opportunities from interview transcripts: my Claude Code workflow

You’ve got a bunch of interview transcripts. You want to extract relevant insights and opportunities, and ultimately select your #1 opportunity to focus on. How on earth do you get from a to b?

This is probably the most important step in your discovery process: finding the customer opportunity (pain point, need, desire, want - a la Teresa Torres) that’s actually worth solving. I’m too embarrassed to do the math on how much time I’ve wasted solving problems that weren’t really all that important.

On to the magic: the theory and skill behind selecting the right #1 opportunity.

Prefer to watch? Check out the full walkthrough on YouTube

I split this step into 4 sub-steps:

1. Phase mapping (Claude Code skill: `phase-map-analyst`). The stable, cross-interview moments in time, or “phases” in a user’s job-to-be-done. I associate every opportunity I extract from a transcript with one of my pre-defined phases.

2. Extracting opportunities and insights from transcripts (skill: `opportunity-analyst`). Codifies my process and judgement: extracts customer opportunities and insights, filters out the already-solved and goal-misaligned, frames each in the customer’s voice grounded in their story, and tags each to a phase from step 1.

3. Opportunity mapping(skill: `opportunity-mapper", next article) . Cluster opportunities across transcripts into a tree.

4. Opportunity sizing (skill: `opportunity-sizer”, next article). Pick the #1 to focus on.

This article focuses on sub-steps 1 and 2 - the phase map and the extraction skill that depends on it.

The full skill package, including a small reset utility that closes the loop between them, is on my GitHub. Feel free to fork, and read through the skill.md files to understand my process and how I codified my judgement.

I’ll walk through each sub-step with theory and a real-client example interleaved. The client (anonymized) is MyNewTechJob, an AI-forward job-matching platform.

• Where this sits in the pipeline

• The case study: MyNewTechjJob

  • Sub-step 1: phase mapping

    • What the phase-map-analyst skill does

  • Sub-step 2: extracting opportunities

    • Capturing the opportunity context

    • Two filters: “already solved” and “goal-aligned”

    • How the skill writes its output

    • Opportunity-analyst-reset

  • The “doesnt fit any phase bucket” closes the loop

The full pipeline I’m building is six skills, designed as a left-to-right data flow where each consumes the previous one’s output:

The ICP screener (skill 1) has to come first - we don’t want to mix ICPs when we do product discovery (see previous article). The mapper and sizer (skills 5 and 6) come after, because their job is cross-transcript prioritization, which only works once you have phase-tagged opportunities to cluster.

Skills 2, 3, and 4 are the topic of this article. They form the first complete iteration loop in the pipeline.

I’m using “MyNewTechJob” to give concrete examples for the abstract theory.

The product is loosely based on that of a real client of mine: A job-matching platform connecting tech talent with AI-native companies.

The product metric on the talent side is ”increase the percentage of candidates who find a job within 3 months.” Every opportunity gets filtered against it.

We’ve done 10 candidate interviews with job-seekers using a structured guide focused on “What’s the most painful step in your job search, and what was painful about it?” The ICP-screener filtered 10 down to 6 ICP-matching software engineers (inclusive of ML Engineers, exclusive of Data Scientists).

Six transcripts in hand, product metric loaded - now to substep 1.

Most teams skip this. They jump straight to plucking opportunities out of transcripts and dumping them into a flat list. That’s problematic in two ways:

1. It’s easy to falsely assume that two opportunities are the same, just because they share the same words. “Ghosting is painful” from a candidate who never heard back after submitting their CV is a fundamentally different problem from “ghosting is painful” from a candidate who completed five interview rounds and got radio silence. Same sentence, different phase, different opportunity.

2. It makes “which one is most important?” unanswerable. When opportunities float without context (the phase it belongs to is essential context!), we lack the deep understanding we need to prioritize the right one.

I believe that point-solutions - solving one specific phase in a customer’s job to be done - are generally a much stronger sell than “one stop shop solutions” that try to address every single phase/step of a JTBD.

If you don’t associate opportunities to phases, you won’t see that one particular job phase has far more opportunities associated with it than the others - which is the phase you would build your point solution around.

The phase map is a stable, ordered list of 3-8 phases of the customer’s job-to-be-done, drafted upfront and used as the controlled vocabulary every opportunity gets tagged against.

I’m a fan of Teresa Torres’ Opportunity Solution Trees, and I use the phase map as the first level of my OSTs. It’s the spine of all my discovery work.

I didn’t invent the phase map from scratch. I tried Torres’ experience maps, but the teams I worked with struggled to reconcile per-story maps into a shared vocabulary, and we often failed to describe the experience maps in solution-agnostic terms.

So I tried Tony Ulwick’s universal job-step template (ODI) - define, locate, prepare, confirm, execute, monitor, modify, conclude - to find solution-agnostic “moments in time” to associate opportunities with.

This works beautifully for “warm a meal” but less well for multi-week, multi-stakeholder jobs that loop and run partly in parallel.

So I landed somewhere between the two and called it a “phase map” (I’m nothing, if not a pragmatist!).

The point is that some spine has to exist before you tag opportunities against it, and “distinct moments in time” (which I call Phases) serve as a robust spine.

For MyNewTechJob, the JTBD on the talent side is ”find a fitting next job in tech.” This JTBD is broken down into 6 phases:

1. Define ideal next role and company → 2. Find opportunities (roles) → 3. Apply and initial screen → 4. Prepare for interviews → 5. Execute interview → 6. Decide, negotiate, transition

The phase-map-analyst takes a Job To Be Done and helps you break it down into phases. It runs a deductive-then-inductive loop:

Deductive first. It asks me to sketch the phases - verb-led names like “Define ideal role,” “Apply and screen.” The phase map is the spine of all downstream analysis, so getting it wrong silently corrupts everything that comes after; the person with the domain intuition has to be in the driver’s seat. The skill only ideates phases as a fallback if you really don’t have a clue (which is generally a very bad sign).

Once I have a draft, the skill stress-tests it against five risk checks:

• Granularity - do phases splinter into obvious sub-themes?

• Customer vocabulary - do phase names match how customers narrate the job?

• Single-population - could the ICP be hiding two journeys (e.g. employed candidates vs. between-roles candidates)?

• MECE (Mutually Exclusive, Collectively Exhaustive) - do phases overlap, or is there a gap?

• Solution-agnostic - do phase names bake in tools, channels, or specific artifacts?

Inductive next. The skill picks 3 transcripts and checks how many opportunities fit each phase, what doesn’t fit, and where the customer’s vocabulary diverges from mine. It returns a misfit-rate flag. If misfit rate stays high after a revision, the skill recommends pausing and re-interviewing rather than approving a forced map. A forced map looks tidy but quietly distorts every downstream conclusion.

Once the phase map is in place, we can start extracting opportunities from interview transcripts. Now we invoke the `opportunity-analyst`. Its job: read every ICP-screened transcript and extract:

• Opportunities - the customer’s pain points, frictions, wishes, and desires, framed in the customer’s voice.

• Insights - anything else worth remembering that isn’t a customer opportunity (surprising facts, market observations, context).

Every opportunity gets tagged to a phase from the map. Each one runs through Teresa Torres’ theory: written in the customer’s voice; specific (a moment, a context, key players); not a solution in disguise; not a business outcome.

Per opportunity, the analyst writes down:

• The verbatim quote

• The phase (and if possible: moment within the phase) the opportunity is associated with (what specifically was happening)

• Key players (if available)

• An importance score (1-5) - but only when the customer’s words clearly signal it. If not available, it’s left blank rather than guessed.

Interview tip from doing this the hard way: ask for importance during the interview itself. “How important is this to you, 1 to 5?”

Interviewees will talk endlessly about a problem they faced yesterday, only to tell you in the last 5 minutes that this problem almost never happens, and isn’t actually that important. Capture an explicit importance score so it’s easier to pick the hair-on-fire opportunity later.

Not every pain point is an opportunity worth pursuing.

• Already solved. People love telling stories about something that used to be extremely painful, only to mention at the end “oh, this is actually solved now.” I always ask: (a) does this still persist? and (b) if so, how important/urgent/painful is it on a scale of 1 to 5? If the interviewee describes a satisfactory existing solution, the pain point gets logged under “Solved/addressed” rather than counted as an opportunity.

• Goal-aligned. As Torres puts it: ”the team’s goal is to discover opportunities that have the potential to drive their product outcome”. The opportunity-analyst skill asks me for the #1 product metric (for MyNewTechJob: ”increase the percentage of candidates who find a job within 3 months”) and runs this check on every opportunity. Will addressing this opportunity likely move the product metric? Misaligned ones aren’t discarded - they’re logged as “Non-priority opportunities (goal-misaligned)” so I can manually adjust.

The output is appended to each transcript file in a clearly-labelled section: `## Opportunity Analyst Skill detected Opportunities and Insights`. Five sub-sections: Opportunities, Doesn’t fit any phase, Non-priority, Solved/addressed, Insights. Verification is easy - I read each transcript top-to-bottom and the extraction is right there at the bottom, in the customer’s words, with a quote for every claim.

When you invoke the opportunity-analyst skill, it checks for each transcript whether it already has a “Opportunity Analyst Skill detected Opportunities and Insights” section. If so, this transcript is skipped (which means that the results from previous runs stay). Adding interview #10 to a folder of 9 already-processed transcripts triggers exactly one subagent run.

You invoke the opportunity-analyst-reset skill to delete all `## Opportunity Analyst Skill detected Opportunities and Insights` sections across all interviews from the folder you point the skill at. This allows you to start again, fresh (without manually having to remove the section from all files).

Opportunities that can’t be mapped to phases (‘misfits’) aren’t always noise - they could be evidence that the phase map has a gap, or the JTBD scope was off. If 5% of opportunities don’t fit any phase, the map is probably fine. If 30% cluster around a coherent theme - say, “the moment I decided to leave my current job” - that’s a missing phase!

That’s where you can use `opportunity-analyst-reset`, so the analyst can run cleanly again.

1. Run phase-map-analyst to produce a first iteration of your phase map

2. Run `opportunity-analyst` → check misfit count

3. If misfits cluster around a theme, re-run `phase-map-analyst` (it switches into “revise from misfit evidence” mode)

4. Approve the revised map

5. Run `opportunity-analyst-reset` to strip stale tagging

6. Re-run `opportunity-analyst` against the revised map

Without the reset, the only way to re-run cleanly is to hand-edit every transcript.

The skills covered here, plus the icp-screener and the current monolithic sizer, are open source on my GitHub.

Quick install (all skills):

```bash

git clone https://github.com/Elsevanderberg1/product-discovery-skills.git

cd product-discovery-skills

./install.sh

```

Skills install to `~/.claude/skills/` and are invocable via slash commands. One workflow note: I run these in Claude Code’s `explanatory` output style mode (`/output-style explaory`), which prompts the agent to explain the theory behind its actions as it works. This allows you to learn about the theory and my judgement, which I laid down in the Skills.

Next up: `opportunity-mapper` and `opportunity-sizer` - clustering and scoring on the resulting tree.

Work with me? I’m hiring full-stack and staff engineers to come join me at SwitchUp. Connect with me on LinkedIn if you’d like to chat.