# Job statement structure patterns The canonical structure: "When [situation], I want to [motivation], so I can [outcome]." Each level demands specificity. Vague levels produce job statements that drive nothing. --- ## The three levels ### Situation The context, trigger, or moment when the job becomes active. **Strong situation patterns.** - "When my team is rolling out a new feature and I need to communicate it to customers..." - "When I am preparing the quarterly board deck the night before the meeting..." - "When I get a customer escalation outside of business hours..." - "When a new engineer joins my team mid-quarter..." **Weak situation patterns.** - "When I am at work..." (too broad) - "As a marketing manager..." (demographic, not situational) - "Whenever I need to communicate..." (lacks the specific trigger) **Why specificity matters.** Situations name the moment when the job activates. Different situations can produce different jobs even for the same user; collapsing situations together loses the patterns. --- ### Motivation What the user is trying to do in that situation. **Strong motivation patterns.** - "...I want to write a clear announcement that explains what changed and why it matters..." - "...I want to assemble revenue and engagement data into a coherent narrative..." - "...I want to triage the escalation and respond without disrupting my evening too much..." - "...I want to onboard the new engineer to our codebase without becoming their full-time guide..." **Weak motivation patterns.** - "...I want to do my job better..." (too vague) - "...I want to use feature X..." (motivation is a feature, not a goal) - "...I want to be more productive..." (universal; not actionable) **Why specificity matters.** Motivations name what the user is trying to accomplish in their own words. The motivation should describe the job the user is doing, not the product the user is using. "I want to use Slack to communicate" is not a motivation; "I want to coordinate with the team on the rollout" is. **The product-independence test.** A good motivation should make sense without naming any specific product. If the motivation is bound to the product, it has slid into feature framing. --- ### Outcome What success looks like; what the user is trying to achieve by doing the job. **Strong outcome patterns.** - "...so I can ship the rollout without flooding support with confusion." - "...so I can answer the board's likely questions before they ask them." - "...so I can address the customer's concern while still being present at home." - "...so the new engineer can ship their first PR within two weeks without depending on me for every question." **Weak outcome patterns.** - "...so I can succeed." (too vague) - "...so I can use the feature." (outcome is feature use, not user goal) - "...so I can be efficient." (universal; not specific) **Why specificity matters.** Outcomes name what success looks like in the user's terms. Different outcomes for the same situation+motivation can produce different jobs. The outcome anchors the job in the user's success criteria, not the product's metrics. --- ## Worked examples across product domains ### B2B SaaS for engineering teams - "When a production incident is detected and I am the on-call engineer, I want to identify the root cause and roll back if needed, so I can restore service before the SLO breach without escalating unnecessarily." ### Consumer fitness app - "When I have 30 minutes between meetings and I want to use the time well, I want to do a workout that fits the time budget and uses the equipment I have at hand, so I can stay consistent without skipping when life gets busy." ### Internal tools for finance teams - "When the month-end close is starting and I need to reconcile vendor payments, I want to identify discrepancies and document explanations, so the auditors can review without follow-up questions." ### Creator-tools SaaS - "When I am editing a podcast episode the day before publication, I want to remove background noise and balance audio levels across speakers, so the episode sounds professional without spending another two hours on mastering." Each example specifies the moment, what the user is trying to do, and what success looks like. Each is product-independent at the motivation level: the user is trying to accomplish the job regardless of which tool they use. --- ## Common structural failures ### Vague situations **Failure.** "When I am at work..." **Diagnosis.** The situation does not name the trigger that activates the job. Most users are at work most of the time; the situation should name the specific moment. **Cure.** Re-ground in interview data. What was the user actually doing when this job became urgent? Use that moment. --- ### Motivation as feature request **Failure.** "...I want to use the dashboard..." **Diagnosis.** Motivation is a feature, not a goal. The user does not want to use the dashboard; they want to accomplish something the dashboard supports. **Cure.** Ask the why-question. Why does the user want to use the dashboard? What are they trying to learn from it? The answer is the motivation. --- ### Outcome as feature output **Failure.** "...so I can see the metrics." **Diagnosis.** Outcome is feature output, not user success. Seeing the metrics is intermediate; the user wants something the metrics enable. **Cure.** Ask another why. Why does the user want to see the metrics? What does seeing the metrics enable? The answer is the outcome. --- ### Demographic as situation **Failure.** "As a marketing manager..." **Diagnosis.** Demographic, not situational. Different marketing managers in different moments have different jobs. **Cure.** Replace with the specific moment. "When the marketing manager is preparing the quarterly campaign retrospective..." --- ### Universal as motivation or outcome **Failure.** "...I want to be more productive, so I can be efficient." **Diagnosis.** Universal language; could apply to any user, any job. Says nothing. **Cure.** Specificity at both motivation and outcome. What kind of productivity? What does productivity enable? The specifics are the job. --- ## Multiple jobs per situation A single situation can produce multiple jobs. Different motivations or outcomes within the same situation are different jobs. **Worked example.** Situation: "When I am preparing the quarterly board deck..." Job A: "...I want to assemble revenue and engagement data into a coherent narrative, so I can answer the board's likely questions before they ask them." Job B: "...I want to flag the risks I want the board to engage with, so I can get their input on the calls I cannot make alone." Both jobs share the situation but have different motivations and outcomes. They may need different product responses. The discipline. Do not collapse multiple jobs into one because they share a situation. The motivation and outcome distinguish them. --- ## Job statements vs alternatives in JTBD literature The "When... I want to... so I can..." format is the most widely used job statement structure. Other formats exist (outcome statements in outcome-driven innovation, struggle statements in switch interviews). They each name the same fundamental thing: the user's situation, motivation, and success criteria. This skill uses the When/I-want-to/So-I-can structure because it is the most teachable and the most consistently understood. Teams familiar with other JTBD lineages can translate; the underlying principles are the same. **The structure-vs-substance discipline.** The structure is a scaffold for analytical work. Job statements written in the right structure but without grounding in interview data are still ritual. Job statements written in slightly different structures but grounded in interview data and driving decisions are still jobs. --- ## The job statement editing pass Strong JTBD work runs an editing pass focused on job-statement quality. **Per job statement, the editing questions.** 1. Is the situation specific (a moment, not a demographic)? 2. Is the motivation product-independent and goal-directed? 3. Is the outcome the user's success criterion, not a feature output? 4. Is the statement specific enough that another team could distinguish it from related jobs? 5. Could the team use this job statement to evaluate a product decision? **The editing investment.** 1-2 hours per round of revisions on a typical job-statement set. The investment pays off in clarity for downstream applications (discovery, prioritization, positioning). --- ## Methodology-level choices that stay in the public skill The three-level structure (situation, motivation, outcome). Strong vs weak patterns at each level. The product-independence test for motivation. Common structural failures and their cures. Multiple-jobs-per-situation discipline. The structure-vs-substance principle. The editing pass. ## Implementation choices that stay internal Specific job-statement templates in the team's writing system. Specific document conventions for job-statement libraries. Specific A/B testing of statement variants in interview prompts. The team's own conventions for how many job statements per discovery cycle. These vary by team.