user-personas-behavior

## Purpose Produce a document that defines who a product or feature serves, what job they are trying to get done, what "success" concretely means for them and for the business, and what must be instrumented to measure it. **A persona is a tool for decisions, not a character sketch.** "Priya, 34, marketing manager" tells an implementer nothing actionable. "A user who needs to approve or reject an expense report in under 60 seconds from a phone, several times a day" tells them exactly what to build and how to judge whether they succeeded. ## Input **Works best with:** The name of the product or feature. **Also valuable:** Any existing user research or support tickets, known user complaints, business goals this needs to serve, existing analytics setup. **Example invocation:** `Define user personas and success metrics for our team calendar-scheduling tool. Two clear user types so far: people trying to book a meeting fast, and people managing their own availability so they get booked less often outside working hours.` ## Key Concepts ### Jobs-to-Be-Done (JTBD), Not Demographics Define personas by the job they're hiring the product to do, not by age, gender, job title, or other demographic labels - those rarely change what gets built and can bake in assumptions that don't hold. Structure: "When [situation], I want to [motivation], so I can [expected outcome]." ### Behavior Over Biography Describe usage patterns that affect design decisions: frequency of use (daily vs. rare)...