As a product manager, one of my favourite ways to prioritise problems to solve for users is to understand their Jobs to be Done (JTBD). The best way to get this data is by having conversations with many users, but this is not always something users have time for. Surveys are a great complementary method to gather this data quantitatively and quickly. In this post, I share the thinking behind the Jobs to be Done survey I have been running with users in my current role.
What are Jobs to be Done?
JTBD is a framework that helps organisations understand user needs by understanding the underlying job they are trying to accomplish. The idea is that the jobs a user needs to get done remain quite similar over time, but the products or services they use to get those jobs done vary.
What is a Jobs to be Done survey?
A JTBD survey is a quantitative method used to gather data on user needs by assessing both the importance of a job to the users and their satisfaction with existing solutions. Important jobs with low satisfaction are the ones where users are more likely to be open to try using a new product to help them get the job done.
Why I wanted to run a survey
The best way to learn about a person’s JTBD is to talk to them. However, it is not always easy to get busy people to sign up for face to face conversations. I wanted a 3-minute option I could give to users who want to give feedback, but do not want to spend 15-30 minutes on the phone with me.

Why I didn’t like the surveys I found online
I wanted this survey to be something a participant could complete in a couple of minutes. I did not want the length of the survey to scare them away. So I started looking at Jobs to be Done survey templates online to borrow some ideas.
However, most of the templates I found online had:
- Many jobs for users to fill in data for
- Each question takes up a large amount of screen space for the user
So I decided to try something different.

What I tried instead
1. Identify an online form tool that supports conditional logic
I wanted something that allowed some fields to be shown only if other fields are selected. In my case, I chose Jotform.
2. Identify biggest pain points
First, I ask users to pick their biggest pain points from a list. There is a maximum limit of four. This forces the user to prioritise and stops the form from getting too long.

3. Assess biggest pain points only
Next, I ask the user to rate how important the task is to their work, and how satisfied they are with their approach to the task. Once a user reaches this point, I already know that these are their biggest pain points. I do not want to risk them abandoning the form, so I have made these fields optional. This is important, as some users skip this section of the form. Perhaps they would not complete the form at all if I force them to complete very field…

4. Analyse the results
There are two signals of importance:
- How often the job gets selected as one of the top four tasks
- What score the user gives the job for importance
The satisfaction question helps us understand how they feel about their existing solution.
The best tasks to focus on are ones where the user sees the task as important to their work but they have low user satisfaction with the current solution. A good example is the task below.

Using the results to make better decisions
I don’t change my strategy based solely on the scores from a JTBD survey.
But combining this data with what I am seeing from user research, product analytics, and partner feedback has allowed me to build a more complete and accurate picture of what important jobs our users are struggling with and why. These are the areas where users will be more open to trying new solutions. These are the problems where users might hire my product to help them solve the problem. These are the problems I should focus on solving, assuming, of course, that we can find a sustainable and feasible way of doing so
The survey
Congratulations for getting to the end! Here is the survey. Go forth and conquer learn about your users.