Learning objectives
- Convert symptoms into testable hypotheses
- Identify technical and organizational constraints
- Agree a measurable next step
The mental model
Discovery converts a complaint into a problem you can investigate. A customer saying that the network is slow has supplied a symptom, not a root cause or an architecture requirement. Ask which users, requests, regions, and times are affected; what changed; and what the impact is. Then ask what a successful result would look like. Good discovery is not a quiz designed to expose missing knowledge. It is a collaborative reconstruction of a system and its constraints. Summarize what you heard in plain language and invite correction. This makes room for hidden requirements, such as a migration freeze or an application team that cannot change code this quarter.
How it works
Use four layers of questions: outcome, workload, evidence, and constraints. Outcome identifies the business process that is impaired. Workload identifies the request path, data flows, protocols, users, and dependencies. Evidence identifies measurements and observations, including what still works. Constraints identify security requirements, budgets, owners, deployment windows, and unacceptable failure modes. This structure prevents an architecture discussion from becoming a product checklist.
Turn statements into falsifiable hypotheses. If only uncached dynamic requests are slow and origin CPU saturates, a capacity or application bottleneck is plausible. If requests fail before reaching the edge, inspect DNS and transport instead. Ask for representative request identifiers, timestamps with time zones, and sanitized logs. Avoid collecting credentials or unnecessary personal data. Distinguish observations from interpretations in your notes: a customer report that a firewall is blocking requests is an interpretation until matched to a policy event. Finish discovery with an agreed problem statement, a prioritized uncertainty, and the smallest next test. The objective is enough shared understanding to make the next decision, not an exhaustive inventory of every component.
Applied example · hypothetical
Hypothetical example: an engineering manager requests a CDN because an application is slow overseas. You learn that static assets are already cached, while a personalized report waits for a synchronous database aggregation. The report affects a small set of high-value customers at month-end. The next step is to compare report timings by phase and test asynchronous generation, while separately measuring asset delivery. The conversation changes from buying generic speed to improving a specific business workflow with evidence and an acceptable completion target.
In a customer engagement
In a Cloudflare conversation, ask whether traffic is proxied, which endpoints are affected, and what origin evidence exists before suggesting a policy or product. Confirm the customer's goal in their terms. A relevant Cloudflare capability can then be evaluated against that goal rather than used to redefine it. Keep a visible list of unknowns and explain which test will reduce each one.
Interview relevance
A discovery interview often rewards the quality of your next question more than the speed of your solution. Demonstrate active listening by using the answer to change direction. End with a short recap of impact, scope, constraints, and next evidence. This reveals both technical depth and respect for the customer.
Common mistakes
- Leading with a product before understanding impact
- Treating customer interpretation as measured fact
- Gathering sensitive logs without a purpose
Key terminology
Symptom — An observed undesirable behavior, such as timeout or high latency.
Hypothesis — A testable explanation that predicts observable evidence.
Success criterion — A measurable condition agreed in advance for judging an evaluation.
Explain it without the page
- Which discovery answer would cause you to abandon your first hypothesis?
- How would you define success when the customer only says faster?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.