Vibe Engines Learn
Forward Deployed Engineer  /  Discovery & Scoping
FDE Track 02~13 min readIntermediate
The Highest-Leverage Hour

Find the real problem
before you build the wrong one.

The most expensive mistake an FDE makes isn’t a bug — it’s three weeks building the thing the customer asked for instead of the thing they needed. Discovery is how you avoid it: a disciplined hour of watching, asking, and scoping that decides whether everything after it lands or misses.

01

The wrong-problem tax

Every hour of discovery you skip, you pay back with interest later. Build the wrong thing and you don’t just lose the build time — you lose the credibility of the demo, the momentum with the champion, and often the second chance. This is the wrong-problem tax, and it’s the single biggest reason deployments fail. Not bad code. The right code for the wrong problem.

The trap is that a customer hands you a solution shaped as a request. “We need a dashboard.” “Can you build us a chatbot?” Those are guesses at a solution, made by someone who lives with a problem you haven’t seen yet. Your job in discovery is to walk backwards from the requested feature to the pain that produced it — because the best solution to that pain is frequently not the feature they named.

→ The reframe that saves weeks

When you hear a feature request, silently translate it: “They’re telling me they have a problem important enough to imagine a fix. What is it?” Then go find the problem. The feature is a clue, not a spec.

02

Watch, don’t (only) ask

The highest-signal discovery activity isn’t an interview — it’s sitting next to someone while they do the thing you’re there to fix.

Ask a person to describe their workflow and you get a clean, idealized story: step one, step two, done. Watch them actually do it and you see the truth — the spreadsheet they export and paste into, the three tabs they flip between, the field they always leave blank because it’s wrong, the exception that shows up twice a week and derails everything. The mess is the opportunity. It’s where time is lost, errors creep in, and value is waiting.

This is the jobs-to-be-done lens: people don’t want your software, they want a job done — “get this report out by Friday without three people touching it.” Frame discovery around the job, not the tool, and you naturally find the parts of the job that hurt most.

Do

  • Ask them to “show me how you do this today,” then go quiet.
  • Note every manual step, copy-paste, and workaround.
  • Ask “what happens when it goes wrong?” — the exceptions are gold.
  • Count: how many people, how often, how long.

Avoid

  • Leading questions that confirm your pre-built solution.
  • Accepting a summary — “basically we just…” hides the mess.
  • Talking about your product before you understand their job.
  • Interviewing only managers; watch the people who do the work.
03

The questions that surface truth

A handful of questions do most of the work. They fall in four buckets — the problem, success, constraints, and people. (The full list is in the discovery questions cheatsheet; here’s the logic behind each bucket.)

BucketWhat you’re really finding outA question that gets there
The problemThe pain behind the request, and its cost“Walk me through the last time this went wrong.”
SuccessWhat “solved” looks like, concretely“If this worked perfectly, what’s different on Monday?”
ConstraintsThe landmines that reshape the whole build“Where can this run, and can data leave your network?”
PeopleWho wants it, who can block it, who decides“Whose approval could stop this?”

The constraints bucket deserves special care because it’s the one engineers under-ask and later regret. “Where can it run?” and “can the data leave your network?” often reshape the entire architecture — a SaaS design becomes an on-prem one — and finding that out in week one instead of week six is worth a dozen clever features. It’s the bridge from this handbook to integration and deployment.

04

Define success as one number

A deployment without a success metric is a deployment you can’t win, because “better” is unfalsifiable. Push, gently but firmly, for one number that would move if you succeeded: hours saved per week, error rate on a task, time-to-answer, percentage of cases handled without a human. It doesn’t have to be perfect; it has to be agreed.

Pair the metric with a good-enough bar. Most AI-shaped solutions aren’t 100% accurate, and that’s fine if you know the threshold that makes them useful. “If it’s right 85% of the time and flags the rest for a human, that saves us four hours a day” is a scoping goldmine — it tells you exactly what to build and when to stop.

→ The demo bar

Also ask directly: “What would you need to see to believe this is real?” The answer defines your first demo — and stops you from polishing things the customer doesn’t care about.

05

Scope the smallest slice that proves value

Discovery ends in a decision: what to build first. The art is cutting scope without cutting the point.

The instinct is to build the whole vision. The discipline is to build the smallest end-to-end slice that a real user could try and that would make them believe. One workflow, one real data source, one convincing result — beats ten features in mock-up every time. A POC is an argument, and a narrow argument delivered fully is more persuasive than a broad one delivered in slides.

Cutting scope without cutting the point
MustOne workflow, end to end, on real data — the thing that proves the value.
Fake itAnything not core to the proof: hardcode it, stub it, do it by hand behind the scenes.
LaterEvery “can it also…”. Write it on a visible list so the customer feels heard.
TimeboxGive the slice a deadline (a week or two). A demo date forces the cuts.

Two techniques make the cutting concrete. MoSCoW (Must / Should / Could / Won’t) forces everything below “Must” to prove its way up. And a hard timebox — “we demo Friday” — is the best scope-cutter there is, because it converts an open-ended build into a set of decisions about what to leave out.

06

Red flags and when to walk

Discovery also protects you. Some engagements are set up to fail no matter how good your code is, and the signals show up early if you’re watching. Surfacing them is a service to everyone — including the customer.

Red flagWhy it kills deployments
No problem ownerIf no single person owns the pain, no one will adopt or defend the solution.
No success metricYou can’t prove value, so “it works” becomes an opinion you’ll always lose.
No path to the dataThe data you need is behind a system no one will grant access to. The build stalls at integration.
No championNobody internal wants it to succeed and will fight for it. Momentum dies at the first obstacle.

One red flag is a caution; several is a conversation. You don’t always walk away — sometimes the move is to fix the flag (help them define a metric, find a champion, start the access request) as the first deliverable. But naming the risk beats silently building into it. With the real problem, a success metric, and a scoped slice in hand, you’re ready for the part where most POCs actually die: integration.

Frequently asked

Quick answers

What is customer discovery for an FDE?

It’s the process of finding the real problem behind a customer’s request, the constraints around it, and what "solved" actually means — before building. For an FDE it’s hands-on: watching users do the work, asking targeted questions, and scoping the smallest slice that proves value. Good discovery is the difference between a solution that lands and weeks spent on the wrong thing.

Why watch users instead of just asking them?

People describe an idealized version of their workflow and skip the messy parts — the spreadsheet they copy-paste into, the field they always leave blank, the exception that happens twice a week. Those messy parts are usually where the real problem and the real value live. Watching surfaces them; interviews alone rarely do.

How do you scope a proof of concept?

Pick the single workflow that best demonstrates value, cut it to the smallest end-to-end slice that a user could actually try, and timebox it. Everything else goes on a “later” list you can point to. A good POC does one real thing convincingly rather than ten things in mock-up. The scoping question is: what is the least I can build that would make them believe?

What are red flags in a customer engagement?

No clear owner of the problem, no metric that would prove success, no realistic path to the data you’d need, and no internal champion who wants it to work. Any one is a warning; several together mean the deployment is likely to stall regardless of how good your code is. It’s better to surface these in discovery than discover them in week six.

Customer Discovery & Scoping · part of the FDE track · Vibe Engines · 2026
Finished this one? 0 / 139 Handbooks done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

Forward Deployed Engineering

More Handbooks

Explore more from Vibe Engines

Roadmaps →
System Designs →
AI System Designs →
Algorithms →
Labs →
Paper Breakdowns →

Cite this page

Reference it in your work, paper or an AI's context window.

APASingh, S. (2026). Customer Discovery & Scoping for FDEs. Vibe Engines. https://vibeengines.com/handbook/customer-discovery-and-scoping
MLASingh, Saurabh. “Customer Discovery & Scoping for FDEs.” Vibe Engines, 2026, vibeengines.com/handbook/customer-discovery-and-scoping.
BibTeX
@online{vibeengines-customer-discovery-and-scoping,
  author       = {Singh, Saurabh},
  title        = {Customer Discovery & Scoping for FDEs},
  year         = {2026},
  organization = {Vibe Engines},
  url          = {https://vibeengines.com/handbook/customer-discovery-and-scoping}
}