Agent Skills for Customer Discovery: A Practical Workflow (2026)

Agent skills for customer discovery are small, focused instruction sets that structure the messy work of turning customer conversations into product decisions. They plan your interviews, synthesize transcripts into grounded findings, and rank opportunities against real evidence — without pretending to do the interviews for you. The eight Discovery skills in Product OS, the MIT-licensed skill collection maintained by BuildBetter, run in any agent harness and work with or without a connected data corpus. This guide walks through each skill, why evidence-grounding matters most at the synthesis step, and how a B2B product team turns 40 interviews into a defensible roadmap.

What 'agent skills for customer discovery' actually means

Agent skills are small, composable instruction sets written in the common SKILL.md format, portable across any agent harness — Claude Code, Cursor, Codex, and others. They are not tied to a single vendor or IDE. Each skill does one job well, which is what keeps it reliable and auditable instead of a giant prompt that behaves differently every run.

The Discovery pack is one of four packs in Product OS. The full collection is 32 skills — four packs of eight, plus a Complete pack. Product OS is MIT licensed and vendor-neutral, and every workflow ships with an artifact-only fallback, so you can paste transcripts and notes straight into your agent and run the whole thing without BuildBetter.

Discovery is the highest-intent pack for product managers because it sits upstream of everything else. A pricing mistake is expensive; building the wrong thing because you misread what customers wanted is more expensive, because it costs a quarter of engineering time before anyone notices.

One honest expectation to set now: these skills structure the work, they do not conduct the interviews. You still talk to customers. The skills make planning sharper, synthesis faster, and prioritization traceable.

The eight Discovery skills, in sequence

The Discovery pack contains exactly eight skills that run as a pipeline, not a menu. The shape is plan → collect → synthesize → structure → prioritize:

1. plan-product-discovery — frame the decision and hypotheses
2. plan-customer-interviews — build the guide and recruiting criteria
3. synthesize-customer-research — turn raw transcripts into cited findings
4. cluster-feedback-into-jobs — group findings into patterns
5. define-jobs-to-be-done — write structured JTBD statements
6. map-customer-journey — locate friction across the journey
7. analyze-competitors — find real market gaps
8. map-product-opportunities — return a ranked, evidence-linked list

A few design principles shape every one of these skills: evidence before confidence, outcomes before features, decisions before documents, exact states instead of implied completion, and explicit approval for consequential mutations. Those principles are why the synthesis step refuses to invent findings and why the agent asks before it writes anything back to your systems.

Progressive disclosure is the mechanic underneath all of it. Each skill stays small and focused rather than collapsing into one monolithic mega-prompt. A small skill is easier to test, easier to trust, and easier to audit when a stakeholder asks where a conclusion came from. The primary source for all of this is github.com/buildbetter-app/product-os.

Skill-by-skill: input, output, and the failure mode it prevents

Each Discovery skill exists to prevent a specific, common way that discovery goes wrong. Here is what each one takes in, what it returns, and the mistake it guards against.

plan-product-discovery

In: a fuzzy problem area. Out: a discovery plan with research questions and hypotheses. Prevents: running interviews with no decision in mind — the classic "let's just go talk to some customers" project that produces notes nobody can act on.

plan-customer-interviews

In: research goals and target segments. Out: an interview guide and recruiting criteria. Prevents: leading questions and unrepresentative samples that quietly bias every downstream conclusion.

synthesize-customer-research

In: raw transcripts. Out: grounded findings with citations back to specific moments. Prevents: confident fiction from a model that never actually read the transcripts. More on why this is the pivotal step below.

cluster-feedback-into-jobs

In: findings. Out: clustered patterns. Prevents: feature-request literalism — treating "add a dropdown here" as the need instead of the job the dropdown was supposed to serve.

define-jobs-to-be-done

In: clusters. Out: structured JTBD statements with functional and emotional context. Prevents: vague personas that read nicely and predict nothing.

map-customer-journey

In: jobs plus research. Out: a journey map with friction points. Prevents: optimizing a step that isn't the real bottleneck.

analyze-competitors

In: market context plus jobs. Out: competitive gap analysis. Prevents: shipping a table-stakes feature and calling it differentiation.

map-product-opportunities

In: everything above. Out: a prioritized opportunity list. Prevents: a roadmap driven by the loudest voice in the room instead of the weight of evidence.

Why evidence-grounding is the whole point of the synthesize step

The most dangerous output in discovery is not an error message — it is plausible, confident, wrong synthesis from a model that never read the transcripts. An agent asked to "summarize what customers said about onboarding" will happily produce a coherent paragraph even when it has no real data behind it. That output looks like a finding, gets pasted into a deck, and shapes a roadmap. Grounding every claim with a citation back to a specific moment is the only reliable antidote.

To understand why standard retrieval struggles here, sort discovery questions into three shapes:

• Lookup: "What did Acme say about SSO?" — the answer lives in one passage.
• Population: "How many customers complained about onboarding, ranked by severity?" — the answer is a count and ranking across everyone.
• Absence: "Which enterprise accounts never mentioned the feature?" — the answer is about what is not in the corpus.

Top-k retrieval, the engine inside most RAG-based agents, returns the k best-matching passages for a query. That is exactly right for lookup questions. It structurally cannot answer population or absence questions, because the answer is a property of the whole population, not of any single passage. You cannot retrieve a count, and you certainly cannot retrieve a passage that doesn't exist. Many agents commit this category error silently — they return a confident number that is really just a summary of the handful of passages they happened to grab.

To be fair to RAG: this is not a quality complaint. It is the correct tool for lookup. The issue is question shape.

Ahead-of-time comprehension (AOT) takes a different approach. It comprehends each conversation at ingestion time rather than at query time, so it isn't bound by a per-query search budget. That is why corpus-wide synthesis actually works. The published AOT benchmark puts numbers on the gap:

AOT reaches 99.0% coverage (95% CI 98.3–99.7%) on population-scale questions, versus 27.9% for hybrid search at 400 passages and 11.3% for keyword search at 100 passages. Cost is $0.03 per question for AOT against $33.55 for a full-corpus scan — roughly a 1,000x difference. The evidence base: 6,018 call recordings, 8,533 support conversations, and 836 verified evidence pieces.

The detail worth internalizing: scaling k from 100 to 400 passages barely moved hybrid search coverage. That is a structural limit, not a tuning problem.

Worked example: 40 customer interviews to a prioritized opportunity list

Consider a B2B product team with 40 recorded discovery interviews spread across three customer segments. Leadership needs a decision: invest the next quarter in onboarding or in integrations? Here is how the Discovery pack moves that from a pile of recordings to a defensible plan.

1. plan-product-discovery frames the decision explicitly — onboarding versus integrations — and writes the hypotheses each interview should test. Now every conversation has a purpose.
2. plan-customer-interviews produces the guide and recruiting criteria across the three segments. The team then runs the 40 interviews. The skill does not do this part. Humans talk to humans.
3. synthesize-customer-research reads all 40 transcripts and returns findings, each cited back to the specific moment it came from. This is the population-scale step — the one that only holds up because every finding traces to real customer language, not a summary of a summary.
4. cluster-feedback-into-jobs and define-jobs-to-be-done convert raw signal into six to eight structured jobs, translating solution talk ("I wish there was a bulk import") into the underlying job ("get my existing data into the tool without a week of manual entry").
5. map-customer-journey and analyze-competitors locate where friction actually lives and where the market has real gaps versus table stakes.
6. map-product-opportunities returns a ranked list, each item traceable to the evidence behind it.

The payoff shows up in the roadmap review. When someone challenges opportunity #3, the answer isn't "the team felt strongly." It's a link to 11 interviews across two segments, ranked by severity, in the customers' own words. That is the difference between a discovery output you can defend and one you hope nobody questions.

How the skills run: artifact-only fallback vs BuildBetter acceleration

Every Discovery skill runs in one of two modes, and both are genuinely usable. In artifact-only mode you paste transcripts and notes directly into the agent. With BuildBetter connected, the evidence-heavy skills draw on organization Skillsets and AOT retrieval across your full corpus of calls, tickets, and Slack via 100+ integrations.

What BuildBetter adds that most tools cannot: it unifies internal team voice and external customer feedback in one place. Most platforms handle one or the other. BuildBetter connects both — the call your team ran and the support ticket that followed — so synthesis reasons over the whole picture.

A fair scope note. For dedicated research-repository workflows like tagging and highlight reels, purpose-built repositories are more mature. For massive-scale review mining, dedicated theme engines go deeper. For enterprise survey distribution, survey platforms are built for exactly that. The Discovery pack is about grounded synthesis and prioritization, not replacing those. And throughout, the design principle holds: explicit approval for consequential mutations. The agent proposes; the human decides.

How to adopt the Discovery pack this quarter

You can adopt the Discovery pack in an afternoon, and you should start small. Here is the practical path.

• Install from the source. Product OS lives at github.com/buildbetter-app/product-os — MIT licensed and vendor-neutral, so there is nothing to procure.
• Evaluate before you commit. Use skillrank to find, install, and evaluate skills with real numbers rather than picking on vibes.
• Start with one decision, not eight skills. The highest-leverage pair is plan-product-discovery followed by synthesize-customer-research. Frame the decision, then ground it in evidence. Add the rest of the pipeline once that pair earns its place.
• Keep a human in the loop. The skills structure and speed the work. They do not replace interviews or final prioritization — judgment stays with your team.
• Wire up your corpus only if you need scale. If your questions are population and absence questions across dozens or thousands of conversations, connect calls, tickets, and Slack so AOT can answer them. If you're synthesizing a handful of transcripts, artifact-only mode is fine.

Frequently asked questions

Do agent skills replace doing customer interviews?

No. Agent skills structure the planning, synthesis, and prioritization around interviews, but the interviews themselves remain human work. The skills speed and organize the workflow; they do not substitute for talking to customers.

How many Discovery skills are there?

Eight. They are part of Product OS's 32 total skills, organized as four packs of eight, plus a Complete pack. The Discovery pack is one of the four.

Can I use the Discovery pack without BuildBetter?

Yes. Product OS is MIT licensed and vendor-neutral, and every workflow has an artifact-only fallback — you can paste transcripts and notes directly into your agent and run the full pipeline.

Why can't a normal RAG-based agent synthesize 40 interviews reliably?

Synthesis is a population question — the answer is a property of all the interviews together. Top-k retrieval returns only the k best-matching passages and structurally cannot reason over the whole corpus. AOT avoids this by comprehending each conversation at ingestion time rather than at query time, so it isn't bound by a per-query search budget.

Is RAG bad for discovery?

No. RAG is excellent for lookup questions like "what did this account say about SSO?" The limitation only appears for population questions (counts, rankings across everyone) and absence questions (what was never mentioned). It's a question-shape issue, not a quality problem.

What does AOT cost compared to a full-corpus scan?

$0.03 per question for AOT versus $33.55 for a full-corpus scan, at 99.0% coverage on the published benchmark — roughly a 1,000x cost difference to answer a population question comprehensively.

Make churn optional.

The Discovery pack turns customer conversations into decisions you can defend. BuildBetter grounds every one of those decisions in real customer language across calls, tickets, and Slack — so your roadmap reflects what customers actually need, not who spoke loudest. Book a demo.