You now have a pile of notes on what went wrong. Analyze is turning that pile into a decision about what to actually do, and it is where error analysis becomes action.

The first move is to cluster and count. Group your notes into recurring failure types, "it used the wrong tone," "it invented a detail," "it formatted the output wrong", and count how often each happens. This simple act reorders your priorities immediately, because the failure that annoyed you most in the moment is often not the one that happens most, and you want to fix what happens most. The goal is emphatically not to catch every possible failure; evaluation costs effort, so you are being pragmatic, aiming at the failures that actually occur frequently rather than every failure you can imagine.

The second move is to notice that some fixes are cheap and obvious, and to just make them. A formatting error might be one missing instruction in your prompt. A wrong tone might be a line you never wrote. Not everything needs a formal evaluation; some things you spot and fix on the spot, and doing so clears the noise so you can focus your real evaluation effort on the failures that are genuinely hard to pin down.

Keep your judgments binary as you go, pass or fail, not a score out of five. A rating like "3.7 today, 4.2 tomorrow" tells you nothing you can act on, because you cannot say what changed or whether it is really better. "Did this output get the tone right, yes or no" is something you can count, track, and improve against. Binary beats a vague score every time, and adopting that habit now will make everything downstream sharper.

You will leave this lesson knowing your product's real top problems, ranked by how often they happen, with the obvious ones already fixed, which is exactly what you need heading into the sprint.