The Telecom Case Brief
Explore a realistic customer brief from a fictional telecom operator seeking an AI agent for customer service. Learn to read a brief like an FDE by separating the stated ask from the underlying problem and identifying constraints, unknowns, stakeholders, and risks.
Every FDE engagement begins with a brief. Sometimes it is a formal document, sometimes a slide deck from an executive sponsor, and sometimes a few paragraphs in an email. Whatever the format, the brief describes what the customer believes they want. It rarely describes everything they need, and it almost never lists the constraints that will decide whether the project succeeds. Reading a brief well is a core FDE skill, and in Google’s interview loop, system design scenarios often begin with a brief that candidates must interpret before they design anything.
The rest of this chapter follows a single customer case from brief to design. The customer is a fictional telecom operator, and the case brings together the topics covered so far: Gemini, agents, tools, retrieval, data, deployment, cost, security, and evaluation. This lesson presents the brief and shows how an FDE reads it.
The customer brief
The brief below arrived from the customer’s executive sponsor ahead of a first meeting with the Google Cloud team. ...
Question | What it uncovers |
What is the stated ask? | The solution the customer has already pictured |
What is the underlying problem? | The business outcome that actually matters |
What constraints are stated or implied? | Limits on data, systems, timelines, and compliance |
What is unknown or assumed? | Gaps that must be filled before scoping |
Who are the stakeholders? | The people who sponsor, approve, operate, or block the project |
What are the risks? | What could prevent the project from reaching production |