Jobs to Be Done

Outcome: Use Jobs to Be Done to make a focused product decision backed by evidence. User context: A commuter uses a podcast app to turn an uncertain train ride into useful learning time. Product concept to apply: Jobs to Be Done. Why it fits: Use it when a feature request may be hiding a larger goal or reason. Do not use it when: Never describe the job as one button click or as a person's age or job title. 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.