Technical Discovery for Forward Deployed Engineers

Technical discovery is the first stage of a customer engagement: finding out what problem really needs solving, which systems and data are involved, and what could go wrong. Good discovery saves weeks later. Its two halves are asking the right questions and looking at real data early.

Questions to ask

The problem

• What decision or task should this improve? Who does it today, and how?
• How is success measured today, and what number would make this project worth it?
• What happens if we do nothing?

The people

• Who will use the solution day to day? Who sponsors it? Who must approve security and data access?
• Who on your side will own and maintain it afterwards?

The systems and data

• Where does the needed data live? How is it accessed (API, database, files)? How fresh is it?
• Which fields matter, and what do their values mean? Are there known problems?
• What rules apply: personal data, data location, retention, approvals?

Write the answers down and send them back for confirmation. Misunderstandings found in week one are cheap.

Profile real data in the first week

People describe their data as cleaner than it is. Ask for a small, realistic sample, such as an export of a few thousand rows, and profile it yourself. This example checks a support-ticket export for duplicates, blanks, inconsistent values and mixed date formats:

import csv, io
from collections import Counter

# A small extract the customer sent in week one (in real life: a CSV export or a read-only database view)
EXPORT = """ticket_id,created_at,customer_email,category,priority,resolved_at
T-1,2026-10-01 09:12,[email protected],Billing,High,2026-10-01 11:40
T-2,2026-10-01 10:05,[email protected],billing,,2026-10-03 16:00
T-3,2026-10-02 14:30,,Delivery,Low,
T-4,02/10/2026 15:00,[email protected],Delivery,Medium,2026-10-02 18:20
T-2,2026-10-01 10:05,[email protected],billing,,2026-10-03 16:00
T-5,2026-10-03 08:45,[email protected],Returns,Urgent,2026-10-03 09:30
"""

rows = list(csv.DictReader(io.StringIO(EXPORT)))
print(f"rows: {len(rows)}, columns: {list(rows[0])}")
dupes = [k for k, n in Counter(r["ticket_id"] for r in rows).items() if n > 1]
print("duplicate ticket ids:", dupes)
for col in rows[0]:
    values = [r[col] for r in rows]
    blank = sum(v == "" for v in values)
    distinct = sorted(set(v for v in values if v))
    note = f", values: {distinct}" if len(distinct) <= 5 else ""
    print(f"  {col:15} blanks={blank}{note}")
odd_dates = [r["ticket_id"] for r in rows if r["created_at"] and not r["created_at"][:4].isdigit()]
print("dates not in YYYY-MM-DD format:", odd_dates)

rows: 6, columns: ['ticket_id', 'created_at', 'customer_email', 'category', 'priority', 'resolved_at']
duplicate ticket ids: ['T-2']
  ticket_id       blanks=0, values: ['T-1', 'T-2', 'T-3', 'T-4', 'T-5']
  created_at      blanks=0, values: ['02/10/2026 15:00', '2026-10-01 09:12', '2026-10-01 10:05', '2026-10-02 14:30', '2026-10-03 08:45']
  customer_email  blanks=1, values: ['[email protected]', '[email protected]', '[email protected]', '[email protected]']
  category        blanks=0, values: ['Billing', 'Delivery', 'Returns', 'billing']
  priority        blanks=2, values: ['High', 'Low', 'Medium', 'Urgent']
  resolved_at     blanks=1, values: ['2026-10-01 11:40', '2026-10-02 18:20', '2026-10-03 09:30', '2026-10-03 16:00']
dates not in YYYY-MM-DD format: ['T-4']

In a few seconds, the profile raises five questions for the customer:

• Why is T-2 duplicated?
• What does a blank priority mean?
• Is “billing” the same as “Billing”?
• Is “02/10/2026” the 2nd of October or the 10th of February?
• Does a blank resolved date mean the ticket is still open?

Each answer becomes a rule in the integration. See integrating customer data.

The discovery summary

Finish discovery with a one-page summary:

1. Problem in the customer’s words, and the success measure.
2. Users and owners.
3. Systems and data, with access method and known issues.
4. Constraints: security, privacy, deadlines.
5. Risks and open questions, each with an owner.

Get it confirmed in writing before scoping the proof of concept.

Common mistakes

1. Accepting the first request as the problem.
2. Trusting descriptions of the data without profiling a sample.
3. Requesting access late, so the project waits on approvals.
4. No written summary, so different people remember different agreements.

Key takeaway

Discovery finds the real problem, the people, and the state of the data. Ask about the decision being improved and how success is measured, profile a real data sample in the first week, and write a short summary with risks that the customer confirms. Next: scoping a proof of concept.