User and JTBD
JTBD describes not a demographic profile, but a situation in which a user “hires” a product for a particular job. A good job contains a trigger, context, desired progress, and constraints. “The user wants AI” does not explain what should change.
Separate observed fact, assumption, and desired outcome. Even a very specific JTBD in a capstone remains an educational hypothesis until it has confirmed research or actual usage evidence.
JTBD in a verifiable format
| Field | Documented example |
|---|---|
| When | When a reviewer receives a small but ambiguous change |
| I want to | Quickly understand the scope, checks, and remaining Unknowns |
| So I can | Make the next review decision without repeating discovery |
| Constraint | No access to unconfirmed production claims |
| Success signal | Required evidence anchors are found in one review pass |
Success metric and interpretation boundaries
A metric has a name, unit of measurement, baseline, target, observation window, and collection method. For an early MVP, do not substitute a vanity metric such as the number of AI calls for an outcome metric. If the baseline or real observation window is missing, record that explicitly.
One leading metric can show flow completion, while one outcome metric shows whether the result became more useful to the user. A guardrail metric is needed when optimizing speed could harm quality or safety.
Canonical lesson source · JavaRush
Open JavaRush material