A note on provenance. The examples below come from the two sample reports published on this site. Both are composite products built for demonstration, assembled from patterns that appear across shipped products. No client is implied. The leaks are real patterns; the product they are illustrated on is not a real company.
1. The empty first turn
What it looks like. The user arrives at the moment the product is supposed to start helping and finds a blank input, a cursor, and nothing that tells them what to type. In the sample assistant flow, the task-driven user needs two abandoned drafts before composing a first prompt; the curious user opens with "what can you do?" because nothing else was offered. On a screen product the same leak is the empty dashboard, the blank canvas, the form with no example.
What it costs. This is the highest-severity finding in the sample critical-flow report, because the drop happens before the product has demonstrated any value at all. A user who leaves here never learns what they were leaving.
The shape of the fix. Do the first turn for them. Offer three things the product can do right now, in the user's language, and make one of them a single tap. This is almost always a small effort, which is why it sits at the top of the "ship this sprint" bucket.
2. Confidence without provenance
What it looks like. The product gives an answer, a number, a recommendation, and gives no indication of where it came from or how sure it is. In an assistant, this is fluent prose with no source. In a checkout, it is a delivery date with no basis. In a dashboard, it is a metric with no definition.
What it costs. Trust that is not calibrated is trust that breaks all at once. The first time the confident answer is wrong, the user re-rates every earlier answer, and the product cannot earn the rating back with copy.
The shape of the fix. Show the basis, or show the uncertainty. "Based on your last three orders." "Usually, but check with your carrier." A source link. The fix is rarely more than one line, but it has to be a line the product is honest enough to write.
3. The dead-end apology
What it looks like. The product cannot help, says sorry, and stops. No alternative, no human, no "try this instead." In the sample assistant flow it is an apology with no fork. In onboarding it is the validation error that names the problem and not the way out. In checkout it is the declined payment with a single "try again."
What it costs. Every dead end is an exit. The apology does not soften that; it confirms to the user that the product has run out of ideas.
The shape of the fix. Treat failure as a fork, not a terminus. Every "I can't" gets at least one "but you can": a different path, a human, a saved draft, a way to come back. The sample report lists this fork among the first fixes to ship because it is cheap and it stops a leak that is otherwise invisible in analytics.
4. The money moment that hides its consequences
What it looks like. The user is about to change something that costs them, a plan, a quantity, a subscription, a delivery option, and the product does not say what changes as a result. In the sample full-product report this is the plan-change flow: the consequence lives in an unwritten modal, and the leak converts a plan change into a support ticket and a grudge.
What it costs. This is the leak that shows up in support volume and refund requests rather than in drop-off. The user completes the action, discovers the consequence later, and blames the product for hiding it.
The shape of the fix. One sentence, in the product's own voice, at the moment of the decision, stating what changes for the user. Not a legal paragraph. Not a tooltip. The sentence.
5. The edges in a different voice
What it looks like. The core of the product explains itself well. Then the user reaches settings, billing, account, permissions, and the copy changes register: terse, technical, silent. In the sample full-product report this is the settings page that answers in a different voice. The product teaches users to expect explanations, then goes quiet exactly where the consequential controls live.
What it costs. Users conclude the quiet parts are the dangerous parts and stop touching them. Features go unused, and the ones that matter for retention, like notification and plan controls, are exactly the ones in the quiet zone.
The shape of the fix. Bring the centre's voice to the edges. Each consequential control gets the same one-sentence explanation the onboarding already gives. This is copy work, which is why it lands in the "next sprint" bucket rather than a redesign.
Why five, and why ranked
A full audit of one flow runs to many more findings than five, each with its severity, evidence, cost, fix and effort. The teardown is not a shorter version of that list. It is the answer to a narrower question: of everything leaking in this flow, which five cost you most, and what is the fix for each? Ranked, because a list without an order is a way of avoiding the decision. If you later want the full plan, the teardown counts toward a full audit within 30 days.