Jobs to Be Done (JTBD) - it's a term that has gained enormous traction in software development in the last few years. Everybody, from sales, through marketing, customer success, to product teams, talk about customers' Jobs to Be Done. Yet I find more often than not that the term it's misunderstood and misused.
In this article I will try to help you understand how Jobs to Be Done differ from feature requests, tasks, and solution statements.
What Exactly Is A Job To Be Done?
In essence, a job to be done is a functional, social, or emotional objective a given type of customer aims to achieve in a specific context, guiding their choices and actions. It's not a task or a solution, in fact a good JTBD statement should be solution agnostic. A JTBD statement should capture the outcome the customer has in mind. For instance:
Jobs To Be Done Vs. Feature requests
One common misconception is conflating JTBD with feature requests. Features are aspects of a product or service that enable the customer to get the job done, they are not the job itself. Let's compare two statements:
The former is clearly a JTBD statement. It is highly contextual and points to the desired outcome. The latter is merely a feature. And one of potentially many that could help address the JTBD and rather not the best one (I personally always mute voice guidance!) You could listen to the traffic news at your local radio station, you could use GPS navigation that relies on data from other users' phones (Google Maps), and others.
Jobs To Be Done Vs. Solutions
Solution statements are specific demands for products or features that customers believe will help them accomplish their job. They are very similar to feature requests, only bigger. Again, let's look at 2 statements:
Again, the former statement is a highly contextual job to be done. The latter is a more generic description of a solution. But there can be many different solutions for the same JTBD. We could invest in a public speaking course, or a tool for creating engaging infographics, and many others.
Jobs To Be Done Vs. Tasks
Tasks are specific actions that customers take while trying to get a job done. But tasks are specific to the processes and tools being "hired" by the customer to address the JTBD. Tasks can be as simple as "pressing a button to start a video call", but the job to be done is still "to feel connected with distant loved ones". Again, let's look at 2 statements:
The latter statement is a single task that needs to be performed while using a specific feature in a particular solution. It is an extremely granular statement. But JTBD, as we covered above, can be served by different solutions and different features. And each one would necessitate a different series of tasks to be performed to get the job done.
What's next?
Most customer feedback is passed to product managers and business analysts as feature requests. Most internal ideas focus on specific solutions. And a lot of 'market feedback' is presented as observation of what tasks the users are involved in.
But trying to deliver against such statements would be irresponsible and most likely damaging - since we don't know whether this is indeed what customers want or get motivated by. By identifying and focusing on the true job to be done, we can unveil the core motivations of our customers and design solutions that truly fulfill their needs.
If you would like to learn more about Jobs to Be Done and how to conceptualize them, consider taking my "Total Story Visualization" course. You can learn to unleash your potential to deliver solutions that truly resonate with customers. The course teaches a novel, syncretic method of doing best-in-class business analysis.
