My Product Discovery OS in Claude Code: Step 1 - ICP screen

Part 1 of the Product Discovery OS series. I’m breaking down product discovery into 8 steps, each with a reusable system + Claude Code skill you can fork. More interesting than the skill itself is the reasoning behind each step: why take it, what does good look like? Surprise - this starts to look a lot like Product Discovery 101.

1. ICP screen ← you are here

2. Opportunity analyst

3. Opportunity sizer

4. Solution generator

5. Assumptions mapper

6. Test strategy generator

7. Test assets creator

8. Test result analyzer

My favorite thing about writing skills and agents isn’t the all-knowing all-mighty AI (though that’s pretty cool). It’s that they force me to codify my process and my judgment, which also forces me to notice when I’m cutting corners.

A Claude Code skill that filters my interview transcripts down to one Ideal Customer Profile (ICP) before I analyze them. Every interviewee who doesn’t match your ICP creates noise.

Fork the Claude Code skill here

My god, have I lived through many ICP pivots. As a startup or scale-up, you don’t really know which Ideal or Early Customer Profile to target. You take your best guess, start testing, collect learnings, and either double down or change. At Wave Terminal we went from DevOps, to Developers, to the blurry “Product Builders”, back to DevOps.

Many of you have felt that pain, and I bet that many of you have struggled to make sense of an ever-growing body of interview transcripts belonging to a mixture of ICPs.

If I ask Claude Code to pull customer opportunities and insights out of all the transcripts in that messy old folder, the outcome will look convincing but be meaningless.

Why? Each ICP has their own very distinct jobs to be done, job steps, unsolved opportunities, etc. If you mix them all up, it’s garbage in, garbage out.

I am bullish on a) aligning clearly on which #1 ICP we are building for right now and b) ONLY looking at evidence coming from that ICP.

This has been relatively easy to do with quantitative data (most product analytics tools let you build custom audiences), but near impossible with qualitative data.

In swoops our hero: AI! Let’s gooo.

The ICP screener is a skill I invoke before (!) I try to extract insights and opportunities out of transcripts (for which I have a separate skill, called “customer opportunity analyst”.

The job of the ICP screener skill is narrow: take a folder of interview transcripts, an ICP definition, and produce a filtered, inspectable subset.

It handles two folder realities, because that’s what I’ve actually run into in practice.

The tidy case. Inside my `interview-transcripts/` folder, I already have sub-folders named by segment:

```

interview-transcripts/

developers/

devops/

qa-engineers/

```

I invoke the skill with the path to my `interview-transcripts/` folder. It first tries to read the current ICP from my company context file, and only asks me inline if it can’t find one there. Then it scans the folder structure, spots the matching sub-folder, and asks: “There’s a `developers/` sub-folder that lines up with your target ICP. Should I treat everything in there as a match?”

Yes. Done.

The less tidy case - and honestly, the more common one. A single `interview-transcripts/` folder with every interview I’ve ever done, in no particular order.

Here, the skill doesn’t rely on folder structure. It reads the _profiling header_ on each transcript file and classifies from that.

Which brings me to the prerequisite.

Mode B only works because every transcript I store follows the same structure. Not a raw dump. Every interview lives in an `.md` file with three sections, in this order:

1. Profiling info. A short metadata block I collect pre-interview or in the first minute of the conversation. Role, company maturity (seed, Series A, scale-up, enterprise), years of experience, team size, tools they use. Whatever attributes matter for the ICPs I’m testing.

2. My manual notes. What I thought was interesting as the conversation happened. The customer opportunities and insights I pulled out myself.

3. Raw transcript. The verbatim text.

Without that first section, the skill is guessing. Maybe it can infer role and seniority from content, maybe not, and the confidence is low. With the profiling header, classification attributes become explicit . Match the attributes, include the file. Don’t match, exclude.

The skill writes copies of the transcripts that match the ICP to a temp folder. Something like:

icp-screened-TEMP-2026-03-14/

screening-overview.md

interview-05.md

interview-12.md

interview-27.md

...

1. Copies of the transcripts that matched the ICP. Just copies - the originals stay put.

2. A `screening-overview.md` file with three categories: Matches, No Match, and Uncertain.

The overview is the part that earns trust.

The Uncertain category is doing important work. When profiling info is missing or ambiguous, the skill flags the transcript rather than silently excluding it. I get to make the call.

I skim the overview before I trust anything downstream. Sometimes I disagree with an exclusion - the skill got too strict. Sometimes I catch an inclusion that shouldn’t have passed. Either way, the decision is visible. No black box.

Watch my buddy Claude in action:

My ICP screener skill is published on GitHub. Install it as a Claude Code skill and invoke it with `/icp-screener <path-to-transcripts-folder>`.

A clean transcript subset is the setup. The next step is pulling customer opportunities and insights out of the filtered down subset of interview transcripts. That’s Step 2 in this series: my opportunity analyst skill.

The ICP screener doesn’t make discovery faster, but it makes my inputs cleaner. You can run the fanciest synthesis in the world across a contaminated dataset and still get confidently wrong answers.

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