Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Users don't want 'AI' — they want a job done: a draft written, a document understood, an answer found in their own data. Framing your feature as a job-to-be-done keeps you honest about the outcome the user is paying for and stops you from shipping a generic chat box when what they needed was a one-click summarize button. This framing also tells you exactly what 'good' looks like, which is the input to every later decision about prompts, UX, and evaluation. Get the job wrong and no amount of model quality saves the feature.
Translate a vague 'add AI' ask into a concrete job statement with a triggering situation, the desired outcome, and the current painful workaround — the shape that makes a feature designable.
Use these three in order. Each builds on the one before.
In one paragraph, explain the 'jobs to be done' framing and why it matters for designing an AI feature.
Walk me through how to turn a vague 'we should add AI' request into a concrete, designable job statement.
Given a job-to-be-done with a measurable outcome, how would that outcome shape my prompt design, UX, and success metric down the line?
# A job-to-be-done captures situation -> motivation -> outcome.
job = {
"when": "I open a 40-page support thread", # triggering situation
"i_want_to": "understand what was already tried", # motivation
"so_that": "I don't repeat steps with the customer", # outcome that has value
"today_i": "skim manually for 5 minutes", # the painful workaround AI replaces
}
def is_designable(job):
# A good JTBD names a measurable outcome and a real current cost.
return bool(job["so_that"]) and bool(job["today_i"])
print("designable:", is_designable(job))
# The feature is now obvious: a thread summary that surfaces 'already tried' steps.python3 main.py