KNOWLEDGE WIKI  (LOCAL-MD-001)MODE: READ_ONLYSYS_TIME: --:--:--
SECTION:fdePAGES:40CURRENT:field-patterns/customer-discovery-and-requirements-gathering.md
FDE-007field-patterns/customer-discovery-and-requirements-gathering.mdUPDATED: 06/18/2026

Customer Discovery And Requirements Gathering

Pattern

Name: Customer discovery and requirements gathering

When to use it: At the start of a customer engagement, before proposing architecture, automation, or AI behavior.

Why it matters for FDE roles: The technical solution only works if it matches the real workflow, constraints, owners, and failure points.

Plain-English Description

Customer discovery is the process of learning how work actually happens. Requirements gathering turns that reality into a clear implementation target.

Situation Signals

  • Job listing signal: customer discovery, requirements, stakeholder management, ambiguous environments.
  • Customer signal: different people describe the workflow differently.
  • Project signal: the team wants a demo before the problem is clearly scoped.

What To Ask

  • What starts the workflow, and what counts as finished?
  • Who owns each step, handoff, approval, and exception?
  • Which systems are authoritative for each record?
  • What breaks most often today?
  • What would make the first version trustworthy?

What To Do

  • Map the current workflow before designing the future workflow.
  • Separate must-have requirements from nice-to-have requests.
  • Identify data sources, owners, permissions, and failure cases.
  • Confirm success criteria in plain language.

Artifacts To Produce

  • Diagram: current-state workflow map.
  • Checklist: open questions and assumptions.
  • Demo/prototype: narrow happy path plus one exception path.
  • Customer-facing note: agreed scope and success criteria.

Failure Modes

  • Accepting the first description as the full truth.
  • Skipping exception paths.
  • Mistaking a feature request for the underlying problem.
  • No named owner for decisions.

Interview Language

One sentence I could say in an interview:

I start by mapping the real workflow, owners, systems, and exception paths so the first build solves the operational problem instead of just matching a feature request.

Relevant work experience for this pattern: