LLMOpsThe LLMOps lifecycle · MLflow 3 · FastAPI · Docker · AWS/Azure
Dashboard
0%
1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
41 small wins to finish your pathNext lesson →

Planning and requirements

Planning and requirements is the first stage of the LLMOps lifecycle: before any data or model, you fix what the app is for, how you will know it works, and who owns it.

Last updated: 15 Oct, 2026 · LLMOps

The four LLM use cases gave you the shape of the thing being built. This lesson is the stage that comes before everything else in the lifecycle video, where the project is scoped and its requirements are gathered.

Who owns this stage

In the video the planning stage belongs to the product owner and the business analyst. The product owner carries the goal; the business analyst gathers the requirements. Their output is a clear statement of the use case, which the data and model work downstream is then built to serve. The video is explicit that data collection follows from the use case you are solving, so a vague scope here spreads confusion through every later stage.

What to decide before building

Three things are worth writing down before a single document is collected or a model is chosen.

  • Scope. The one use case the app serves, and the questions or tasks it will handle. A support assistant that answers from your return policy is a scope; an assistant that does everything is not.
  • Success criteria. How you will know it works, in numbers you can measure later: the answers it must get right, the latency a user will accept, the cost per request you can afford. These become the targets the evaluation stage checks.
  • Ownership. Who signs off on the scope, who owns the data, and who is called when the deployed app misbehaves.
DecisionWho answers itWhy it matters later
Scope and use caseProduct ownerDecides what data is collected and which build is chosen
Success criteriaProduct owner with the ML leadBecomes the metrics the evaluation stage measures against
Data ownership and accessBusiness analyst, data ownerGoverns what can go into a prompt or a training set
Who is on callThe teamDecides who responds when monitoring raises an alert
Four planning decisions on the left, each with who answers it, joined by an arrow to the later stage it governs on the right: scope and use case decides what data you collect and which build you choose; success criteria become the numbers evaluation measures against; data ownership and access governs what may go into a prompt or a training set; and who is on call decides who answers when monitoring raises an alert.

Where you use planning

  • Starting a project, where an hour spent on scope saves weeks of collecting the wrong data.
  • Settling a disagreement, where a written success criterion ends an argument about whether the app is good enough.
  • Handing over to evaluation, where the criteria you wrote become the pass marks a later stage checks.
Watch out. The easiest thing to skip is the success criteria, because the app seems to work in a demo. Without a number agreed up front, there is nothing for the evaluation stage to measure against, and what counts as good enough turns into opinion. What to evaluate: RAG vs a plain LLM is where those numbers are put to work.
Try it yourself
  • Write a one-sentence scope for a shop support assistant, naming the single use case it serves.
  • Set three success criteria for it as numbers: an accuracy target, a latency a user will accept, and a cost per request.
  • List who owns the scope, who owns the data, and who is called when it breaks.
PreviousThe four LLM use cases

Little by little, you're building something great.