Mining for Skills: What an FDE Must Uncover During Customer Discovery

You've landed the engagement. The customer is excited about AI, the leadership team has bought in, and now it's on you - the Forward Deployed Engineer - to turn that enthusiasm into something real. But before you write a single line of code or configure a single integration, you're in the phase that quietly determines whether the whole project succeeds or stalls: Customer Discovery.

And here's the thing most FDEs learn the hard way - discovery isn't about the technology. It's about understanding the work. Specifically, at this first rung of the AI adoption ladder, it's about uncovering Skills: the discrete, repeatable capabilities that AI can execute well.

Get discovery right, and you'll surface the handful of skills that deliver outsized value fast. Get it wrong, and you'll spend weeks building something impressive that nobody actually needed. This post is about what you should care about - and what you should dig into - when you're hunting for Skills during discovery.

First, Anchor on What a "Skill" Actually Is

Before you walk into that first discovery call, get crystal clear on your own definition, because you'll be teaching it implicitly through the questions you ask.

A Skill is a scoped, repeatable capability - a packaged recipe of instructions that lets AI perform one specific task reliably. Think of Claude generating a properly formatted slide deck, or Copilot turning a comment into a working function. A skill isn't "AI that does everything." It's AI that does one thing, predictably, with defined inputs and defined outputs.

Your job in discovery is to find the customer's version of that "one thing" - ideally several of them - hiding inside their day-to-day operations. So every question you ask should be pulling toward specificity, structure, and repeatability.

What You Should Care About in Discovery

1. Find the Repetitive, Structured Work

The best skill candidates are tasks people do over and over, the same way each time. Your instinct as an FDE should be to listen for phrases like "every week we have to...", "it always takes forever to...", or "someone manually pulls..."

Ask questions that surface volume and frequency:

• "Walk me through a task your team does at least a few times a week."
• "What's the work everyone dreads because it's so repetitive?"
• "If you could clone one person to do one boring task all day, what would it be?"

You're not just looking for pain - you're looking for patterned pain. A one-off crisis isn't a skill. A recurring, structured process is.

2. Hunt for the Tribal Knowledge

Here's where great FDEs separate themselves. The most valuable skills often encode knowledge that lives entirely in someone's head - the senior analyst who "just knows" how to format the report, the CSM who "can tell" when an account is at risk.

During discovery, care deeply about this implicit knowledge, because turning it explicit is what makes a skill trustworthy. Probe with:

• "When you do this task, what are you actually checking for?"
• "What would a new hire get wrong that you'd catch immediately?"
• "Are there unwritten rules or exceptions you apply without thinking?"

If you can extract that tacit expertise, you can encode it. If you can't, the skill you build will produce output that looks right but misses the nuance - and the customer will lose trust fast.

3. Define "Good Output" Precisely

You cannot build a reliable skill without knowing what success looks like. This is the single most under-asked question in discovery.

For every candidate skill, care about the shape of the output:

• "Show me an example of a great version of this deliverable. Now show me a bad one."
• "How do you know when this is done correctly?"
• "Who reviews this today, and what do they check?"

Ask for real artifacts - actual reports, real emails, sample tickets. A skill defined against a concrete "gold standard" example is a skill you can build and validate. A skill defined against a vague description is a guessing game.

4. Map the Inputs and Their Availability

A skill takes inputs and produces outputs. During discovery, you need to know both - but inputs are where projects secretly die. The customer might describe a beautiful skill that requires data that's locked in a PDF, scattered across three systems, or simply doesn't exist in usable form.

Care about:

• "What information do you need in front of you to do this task?"
• "Where does that information live today?"
• "Is it clean and consistent, or does it need interpretation first?"

This is your early warning system. If the inputs are messy or inaccessible, you've either found a data-quality workstream that comes first, or a skill that has to wait. Better to know now than three weeks in.

5. Understand the Edge Cases and Guardrails

Skills fail at the edges. During discovery, deliberately push toward the exceptions, because a skill that only handles the happy path will embarrass everyone in production.

• "How often does this task go 'off-script'? What does that look like?"
• "What's the worst outcome if this is done wrong?"
• "Are there things the AI should absolutely never do here?"

The answers tell you how much guardrail engineering the skill needs, and how much human review to build around it. A low-risk skill (formatting a draft) can run loose. A high-risk skill (anything customer-facing or financial) needs tight boundaries.

6. Gauge the ROI Before You Fall in Love

FDEs get excited by interesting problems. Resist building the clever skill over the valuable one. During discovery, quietly do the math on every candidate:

• How much time does this task consume, per week, across how many people?
• How painful is it when it goes wrong?
• How ready is the data and process to support automation?

The winning first skills sit at the intersection of high frequency, clear value, and low readiness friction. Prioritize those. They earn you the credibility and momentum to tackle the harder ones later.

7. Identify the Owner and the Validator

Every skill needs a human who owns the process and a human who trusts the output enough to sign off on it. During discovery, find those people early.

• "Who owns this workflow today?"
• "Whose judgment do people trust on whether the output is right?"
• "Who would need to be comfortable with AI doing part of this?"

These are your champions and your reviewers. A skill without a validating owner is a skill nobody will actually adopt, no matter how well it works.

The Discovery Mindset That Sets Great FDEs Apart

Notice the through-line in everything above: you're not selling AI, and you're not architecting a system yet. You're being a detective of work. The best FDEs treat discovery like an anthropologist - watching how people actually operate, listening for the gap between how work is described and how it's really done, and translating that into scoped, buildable skills.

Three habits will serve you well:

Watch, don't just ask. Whenever possible, get someone to screen-share and do the task live. You'll see the copy-pasting, the workarounds, and the tribal knowledge that no one thinks to mention.

Chase specificity relentlessly. Every time a customer says something vague - "we handle reporting" - drill down until you have a concrete, bounded task with real inputs and a gold-standard output.

Prioritize ruthlessly. You'll leave discovery with a list of ten possible skills. Your value is in identifying the two or three that are high-impact, well-defined, and ready to build - and having the discipline to start there.

What Comes Next

Skills are rung one. Once you've discovered the capabilities worth building, the natural next question is: where does the data live, and how does the AI reach it? That's the domain of MCP - the Model Context Protocol - and it's what the next post in this series is all about.

But it starts here. Nail your Skills discovery, and everything upstream gets easier. Rush it, and no amount of clever engineering downstream will save the engagement. Because as an FDE, your real product isn't the code you ship. It's the understanding you build before you write it.