View/Export Results
Manage Existing Surveys
Create/Copy Multiple Surveys
Collaborate with Team Members
Sign inSign in with Facebook
Sign inSign in with Google

Jobs To Be Done Survey Template

Use this Jobs To Be Done (JTBD) survey to capture the real trigger, desired outcomes, alternatives, and the hiring/firing criteria behind a decision. You will turn open-text responses into 3-6 job stories, message bullets, an onboarding checklist, and a roadmap opportunity list. Start by sending it at one lifecycle moment (trial decision, days 7-30, or post-churn) and tagging every response by stage + situation + constraints.

9
Questions
5 min
Completion Time
4.5
☆☆☆☆☆
4.9k+
Uses
Use This Template Copy & Edit
What is the primary task or goal you want to accomplish when using a product or service?
In what context or situation do you typically need to perform this task?
What challenges or frustrations do you encounter when trying to complete this task?
Which of the following factors is most important to you when choosing a solution for this task?
Ease of use
Cost
Speed
Reliability
Other
Please rate your satisfaction with your current solution for this task.
1
2
3
4
5
Very dissatisfied Very satisfied
How likely are you to consider switching to a new solution that better meets your needs?
1
2
3
4
5
Very unlikely Very likely
What specific features or improvements would make a new solution more valuable for you?
What is your age range?
Under 18
18-24
25-34
35-44
45-54
55-64
65+
Which industry do you primarily work in?
Technology
Healthcare
Education
Finance
Other

Trusted by 5000+ Brands

Trusted by Red Bull, Yale, Apple, Harvard, Shopify and more

When to Run a JTBD Survey (Pick the Moment That Reveals the Truth)

Right after the trial/demo decision (win or loss)

Best time: within 24-72 hours of the decision. Sending it soon helps reduce memory and hindsight bias (see Pew Research Center's questionnaire design overview for practical wording and recall guidance). First step: send to every evaluator and tag responses by stage + situation + constraint level.

  • What you learn: the trigger that started the search, what they compared you against (including do nothing), and the exact hiring criteria that closed (or lost) the deal.
  • Who to include: buyers and evaluators in the opportunity (won and lost), plus anyone who did the first research (often different people).
  • Distribution tip: add a 2-minute link to the sales follow-up email so it feels like part of the decision recap, not a separate survey ask.

7-30 days after signup/purchase (early success definition)

Best time: after they have attempted the core workflow (not day 1). First step: send to new accounts and branch by use case.

  • What you learn: what "good" looks like, what outcome they expected first, and what constraints slow time-to-value (approvals, data access, training, setup).
  • Who to include: the primary user plus the person who owns the result (manager, ops lead, founder) if they differ.
  • Distribution tip: use in-app at the moment they complete (or fail) a key setup step; you will get more specific answers than a generic email blast. If you also send email reminders, follow basic multi-mode and contact-strategy guidance such as AAPOR's best practices for survey research.

Within 7 days of churn/cancel (firing criteria)

Best time: within a week of cancellation while details are still concrete. First step: send from the cancellation confirmation and branch straight to "what broke".

  • What you learn: the firing criteria (what disqualified you), the last-straw moment, and what they switched to or replaced you with.
  • Who to include: the admin who canceled and the person who felt the pain (they are often not the same person).
  • Distribution tip: keep it one screen per question and under 5 minutes; post-churn respondents will quit fast if it feels like a long exit interview.

Who to Invite (and Who to Avoid) + How to Tag Respondents

Goal: capture clean switching stories so you can group responses into job-based segments. Best time: pick one lifecycle moment per run (trial decision, days 7-30, or post-churn). First step: build your invite list from one bucket and tag every respondent before you read a single verbatim.

  • New customers (7-30 days in): you will hear the "definition of success" in plain language. Send the survey after they have attempted the core workflow once.
  • Churned customers (within 7 days): you will get firing criteria and constraints you missed (budget changes, missing workflow, trust issues). Send automatically from the cancellation flow.
  • High-intent prospects (right after a decision): you will learn what you were compared against and what proof points mattered. Send as part of the win/loss follow-up.
  • Recent category solvers (used an alternative in the last 30-90 days): you will learn the real alternatives, including spreadsheets, agencies, or "we built it." Recruit from communities, referral partners, or a small paid panel, then tag heavily.
Avoid these respondents (they will blur the job)

Only power users: they answer from mastery, not from the moment they "hired" the product.

Long-tenured customers: habit replaces memory; the trigger and alternatives get rewritten over time.

Internal stakeholders: they can help you interpret themes, but they cannot report the real last-time switching context.

Tagging: prevent apples-to-oranges comparisons by adding 4-6 tags to each response before you start grouping themes. This matches the practical quality focus in AAPOR's best practices for survey research -- you will make fewer overgeneralized claims when you keep groups separate.

  • Stage: prospect (won/lost), new (7-30 days), mature, churned
  • Situation/use case: "reporting for leadership," "reduce manual ops," "pass an audit," "ship faster"
  • Constraint level: low/medium/high (time pressure, approvals, compliance, budget)
  • Frequency: daily/weekly/monthly/one-off project
  • Team size: solo, 2-5, 6-20, 21+

Copy this tag set: stage + situation + constraint_level + frequency + team_size. Do the tagging as responses arrive so you can branch your follow-ups to the clearest switching stories.

JTBD Sample Size: Directional Patterns First (Plus 5-8 Follow-Up Interviews)

Start small, balanced, and stage-specific

Goal: spot repeated triggers and outcomes so you can draft job stories fast. Best time: run one lifecycle bucket at a time (trial decision, days 7-30, or post-churn). First step: aim for 10-20 responses per bucket and keep the invite list tight.

Do 10-20 for prospects, then 10-20 for new customers, rather than 60 mixed responses that you cannot compare cleanly. If you want a deeper read on planning directional samples, use sample size guidance for directional surveys.

Stop when themes repeat, then expand only if needed

Goal: reach "enough" clarity to write outcomes and segments, not perfect measurement. Best time: after the first 10-20 responses. First step: track whether each new response adds a new trigger/outcome/alternative.

When you are no longer seeing new themes, you are usually ready to draft your first job story set. Research on open-ended saturation shows that new information often drops off as samples grow, especially when questions are focused (see Open-ended interview questions and saturation).

Pair the survey with 5-8 follow-up interviews

Goal: capture full timelines and tradeoffs so you can write credible switching narratives and objection handling. Best time: immediately after you see 3-5 strong switching stories in the verbatims. First step: invite 5-8 respondents with clear alternatives and constraints.

Use the survey to recruit ("You mentioned you switched from X -- can you walk me through what happened?"). Interview sample size is typically justified by sufficiency for the question, not statistical precision (summarized in sample size sufficiency in interview-based studies).

Copy-Ready JTBD Survey Questions (with Optional Modules)

Goal: capture trigger + outcome + alternatives + decision criteria so you can write job stories and message bullets. Best time: keep one primary stage per run, then branch to stage-specific prompts. First step: copy the questions below, swap in your category/product words, and keep everything in "last time" language.

  • Customize: replace [product] and [category] with your terms, and define the focal event ("the last time you decided to look for a [category] solution"). Example: if you sell Acme Analytics, [product] = "Acme" and [category] = "product analytics". Remove the brackets before you send.
  • Keep neutral: ask what happened and what they tried, not why they "chose" you. Use avoid leading questions and response bias as your quick check before sending.
  • Keep it codeable: if you will not tag it, cut it. If you want stronger prompts, use open-ended question best practices to keep answers specific and scannable.

"Thinking about the last time you decided to look for a solution like [category], what happened that prompted it?"

Why it matters: This captures the real trigger (the moment that created urgency), which becomes the opening line of your job stories and landing page hooks.

When to use: Include in every run. If you are surveying post-churn, you can reword to "the last time you realized [product] was no longer working..."

Open text Segment by: stage, situation/use case, constraint level

"What did you try first (before you looked seriously at any product)?"

Why it matters: First attempts reveal default behavior (spreadsheets, workarounds, an internal process). Those are your true competitors.

When to use: Use early, right after the trigger question, while the story is still chronological.

Open text Segment by: situation/use case, existing tool stack

"What options did you seriously consider? (Include tools, services, manual workarounds, or 'nothing'.)"

Why it matters: You will learn the comparison set and the "do nothing" option, which shapes your positioning and objection handling.

When to use: Use for prospects and new customers. For churn, ask "What did you switch to, if anything?"

Multi-select + Other Segment by: stage, team size, constraint level

"What were you trying to accomplish in that situation?"

Why it matters: This keeps the conversation on the job (the progress they wanted), not your feature list.

When to use: Ask before you mention your product name. If answers drift into features, follow with: "What result did that feature help you get?"

Open text Segment by: situation/use case, frequency

"What would a successful outcome look like for you, and how would you know it worked?"

Why it matters: You get outcomes plus the yardstick (time saved, fewer errors, faster approvals, more signups). Those become message bullets and success metrics for onboarding.

When to use: Best for days 7-30 after signup and for recent wins. Keep it concrete: "How would you measure it in a week?"

Open text Segment by: stage, role level, team size

"What felt most frustrating, risky, or time-consuming about the situation?"

Why it matters: Pain language gives you copy you can actually use (and highlights what to fix first in onboarding or the product).

When to use: Use for all stages. For churn, add: "What changed that made this worse?"

Open text Segment by: constraint level, frequency

"What did you want to avoid (errors, rework, looking unprepared, missing a deadline, etc.)?"

Why it matters: Avoidance outcomes are often stronger purchase drivers than aspirational goals. They also map cleanly to objection-handling and risk-reduction messaging.

When to use: Include if your category is tied to risk, compliance, trust, or deadlines.

Open text Segment by: industry, compliance needs, role level

"How did you want to be seen by others when this was done (team, boss, customers)?"

Why it matters: This captures the social/emotional side in plain language. It often explains why two people want the same functional outcome but buy differently.

When to use: Use when you need better positioning and sales talk tracks, not just feature priorities.

Open text Segment by: role level, team size

"What nearly stopped you from starting (or switching)?"

Why it matters: You will get switching barriers (price, security, migration effort, approvals). These become onboarding fixes and objection handling.

When to use: Always include for prospects and new customers. For churn, reword to "What would have kept you?"

Open text Segment by: constraint level, industry (security/compliance)

"What made you confident [product] (or another option) would work for your situation?"

Why it matters: This is your hiring criteria and proof points (demo moments, references, integrations, trial experience). It turns into landing-page proof and sales talk tracks.

When to use: Ask right after barriers so respondents naturally explain what reduced risk.

Open text Segment by: stage (won vs lost), constraint level

"If you stopped using [product], what would be the reason? (Or, what was the reason you stopped?)"

Why it matters: This captures firing criteria in the respondent's words. It turns into churn job stories and a prioritized save-playbook.

When to use: Show this to churned respondents, or keep it conditional for active users ("If you were to cancel...").

Open text Segment by: stage, situation/use case, constraint level

"Who was involved in the decision, and what steps did you go through from first look to decision?"

Why it matters: You will map the real decision process (research, shortlist, demo, security review, approval). That becomes a tighter funnel and better enablement content.

When to use: Include when sales cycles vary or when activation depends on internal approvals.

Open text Segment by: team size, buyer type, constraint level

Optional modules (add one, not five): keep the core switching story intact, then add a short module tied to your immediate output.

"What price (or pricing model) would have felt like a no-brainer? What price would have been a deal-breaker?"

Why it matters: This gives you directional willingness-to-pay language and the mental "price fences" people use. It becomes a pricing hypothesis list to test, not a final number.

When to use: Add when price is frequently mentioned as a barrier or firing reason.

Open text Segment by: team size, budget owner, stage

"In the first week, what was the hardest part of getting value (setup, data, training, approvals, something else)?"

Why it matters: You get onboarding friction in the same "last time" story, which turns directly into a checklist and in-app guidance priorities.

When to use: Add for new customers at days 7-30, and route churned customers to "what got in the way".

Single select + Other Segment by: situation/use case, constraint level

Keep wording simple and behavior-based ("last time," "what happened right before," "what did you try"). That pattern is consistent with general questionnaire design guidance from Pew Research Center's questionnaire design overview.

How to Analyze JTBD Responses into Job Stories, Segments, and Priorities

  1. Tag stage first, then code the switching story

    Goal: turn raw verbatims into job stories you can share in your next roadmap review. Best time: right after you close the survey (or after the first 10-15 responses). First step: add stage tags and split the spreadsheet by stage so you do not mix churn with new users.

    Code each response with short labels: trigger, desired outcome, constraints, alternatives, proof points, hiring criteria, firing criteria. Do this in a shared sheet so PM, PMM, and UX can align on labels quickly.

  2. Group into 3-6 job-based segments (situation + constraints)

    Goal: create segments you can actually act on with different messaging and onboarding. Best time: once you have 20-40 coded responses in one stage bucket. First step: cluster by situation + constraints, not by persona titles.

    Write segment names as a situation: "Need approvals + tight timeline" vs "Solo evaluator + budget capped." If you want a ready structure to collect segment variables, pair this with a market segmentation survey template.

  3. Turn themes into job stories and outcome statements

    Goal: produce artifacts you can paste into docs: job stories, outcome statements, and proof points. Best time: after you have 3-6 clusters. First step: draft one job story per cluster and keep it tied to the trigger.

    Job story format: "When [situation/trigger], I want to [progress], so I can [outcome]." Then add 3-5 outcome statements per segment ("Reduce time to X," "Avoid Y risk," "Get approval in Z days").

  4. Prioritize directionally with importance x dissatisfaction

    Goal: produce a roadmap opportunity list without over-claiming precision. Best time: once you can list the top 10-20 outcomes. First step: add two quick rating questions in the next wave: importance (0-10) and current satisfaction (0-10) per outcome.

    Rank outcomes that are high-importance and low-satisfaction as your first opportunities. This is a practical adaptation of importance-performance thinking introduced in Importance-Performance Analysis.

  5. Ship outputs: messaging, onboarding, and roadmap notes

    Goal: make the work visible and useful. Best time: within 48 hours of synthesis. First step: publish a one-page summary with (a) top 3 triggers, (b) top 5 outcomes, (c) top barriers, (d) 3 job stories.

    Turn insights into artifacts: outcomes become value props and feature benefit bullets; triggers become landing page headlines; proof points become case-study angles; constraints become objection-handling; barriers become an onboarding checklist; top opportunities become a roadmap candidate list.

Frequently Asked Questions

What is a JTBD survey (and how is it different from CSAT or NPS)?

A JTBD survey captures the switching story: the trigger, desired outcomes, alternatives, and the hiring/firing criteria behind a decision. CSAT and NPS track experience and loyalty over time, but they do not reliably tell you what progress someone was trying to make. Use JTBD to write job stories and update messaging, then use CSAT/NPS to monitor whether delivery matches expectations.

Should I survey prospects, new customers, or churned customers?

Pick one primary stage per run so the stories stay comparable: prospects explain alternatives and proof points, new customers define early success, and churned customers reveal firing criteria. If you mix stages, tag and branch hard or your conclusions will blur together. Run a second wave for the next stage once you have coded the first set.

How many open-ended questions is too many for a JTBD survey?

Stop at the point where you can still code everything you ask; for most teams, that is about 8-12 open-text questions plus a few structured selects. Keep the switching story (trigger, alternatives, outcomes, barriers, decision process) and cut the rest. If you need help tightening prompts, follow open-ended question best practices.

How do I write a good JTBD question without leading the respondent?

Use "last time" wording and ask for sequence: what happened right before, what they tried first, what almost stopped them, and what "good" looked like. Avoid loaded words like "love," "best," or "why did you choose us" because they push respondents toward justification. Use avoid leading questions and response bias as a final pre-send checklist.

How do I turn JTBD responses into messaging and a positioning update?

Map desired outcomes to value props, triggers to homepage hooks, proof points to case-study angles, and constraints to objection handling. Then write 3-6 job stories and turn each into a short talk track for sales and a headline set for marketing. If you want to pressure-test the new copy fast, run a follow-up with the message testing survey template.

Do I need interviews if I already have survey responses?

Do 5-8 short interviews to capture full timelines and tradeoffs that surveys often miss (who said what, what changed, what finally tipped the decision). Use survey answers to recruit people with clear alternatives and constraints, then have them walk you through the last-time story step by step. This keeps interviews focused and turns verbatims into sharper job stories.

FREE TO START -- NO CREDIT CARD REQUIRED

Create Your Jobs To Be Done Survey Template Now.

Start Building ➔