Target User
A Target User is the clear group whose needs and limits guide the first product choices.
Another example
The first release is for independent café owners, not for every kind of small business.
Main parts
- 01Segment boundary
- 02Shared needs and constraints
- 03Who is deliberately excluded
Use it when
Use this group to focus user research, writing, workflows, and the places where you launch.
Do not use it when
Never choose a group so broad that the team can't make a clear trade-off.
Name used in code
audience segment Before you ship
Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision.
Outcome: Use Target User to make a focused product decision backed by evidence. User context: The first release is for independent café owners, not for every kind of small business. Product concept to apply: Target User. Why it fits: Use this group to focus user research, writing, workflows, and the places where you launch. Do not use it when: Never choose a group so broad that the team can't make a clear trade-off. Product framing: Name the target user and wanted result. Record the current baseline and evidence. Set what is in and out of scope, the limits, the owner, and the time frame. Decision quality: Keep facts, guesses, and unknowns separate. Record the options you did not choose and what evidence would change the decision. Acceptance criteria: The document names an owner, target user, measurable result, scope limit, evidence source, open risks, and next test. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Target group, baseline, success level, owner, time frame, dependencies, and review schedule.
Check this request
Review the current use of Target User. Definition: A Target User is the clear group whose needs and limits guide the first product choices. Release checks: Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.