Can Jobs to be Done Research and Personas Co-Exist? Should They?
Jobs to be Done is the theory that customers are trying to achieve something, and they hire the products and services they believe will help them get the Job Done.
Whether you’re a startup seeking problem-solution fit, or an established company with a dedicated UX team, you should already be conducting customer interviews to help guide your product and innovation efforts.
Maybe you already have some user or buyer personas up on the wall, and people cheerily talk about “Molly the Marketer” or “Bob from Sales” as they discuss possible new features or messaging.
If your team has a shared understanding of your existing customer personas, do you still need to conduct Jobs to be Done interviews?
Are the personas your team created worthless?
Are the two approaches even compatible?
Let’s see.. Yes. Probably Not. Yes.
“The whole point of creating personas is to get past our personal opinions and presuppositions to understand what users truly need.” — Kim Goodwin
Jobs to be Done research is unlike any product-related research you’ve done before
Jobs to be Done interviews are powerful for the same reason they can seem wasteful to a product team.
A customers’ Job to be Done is solution-agnostic.
Most of us spend our time working on solutions.
If we have a web conferencing product, we spend our time understanding how customers use web conferencing. Seems pretty obvious. We want to help our customers get the most from our solution.
But web conferencing didn’t exist 30 years ago. It probably won’t exist in its current form 30 years from now.
Does that mean that 30 years ago, customers didn’t need to do whatever it is they use web conferencing for now?
Of course not. Thirty years ago, people may have held conference calls or flown to meetings in order to communicate with people who aren’t in the same physical location. The Job is stable, but people are hiring a new solution they believe helps them get the Job Done better/more cheaply.
If you’re working on web conferencing today, you need to understand the Job you’re helping customers get Done, or risk being replaced. It’s not about helping customers hold the best Web Conferences, it’s about helping customers best communicate with people who aren’t in the same physical location.
It’s not about the product. Customers don’t care about your product. They care about getting their Job Done.
How do personas stand up in a Job-centric world?
First off, let’s be clear here. There are several types of personas, of differing levels of fidelity and applicability.
- Proto-persona. Often not based on research, but rather assumptions the team holds about its users.
- Marketing/Demographic Personas. Demographic personas are likely the ones you’ve seen on your corporate intranet.
These types of personas can help a team remember they’re designing for humans, but the demographic information is of very limited use when it comes to providing product direction. Once upon a time this may have been useful for ad buys, but even advertising has largely evolved from demographic to behavioral targeting. Samantha being 28 doesn’t drive her behavior. The Job she is trying to get Done does. - Goal-driven or design personas. In these personas, the focus is on what the user is trying to achieve, his current behavior and pain points and rather than speculative buying preferences. According to Cooper, “Design personas are good for communicating research insights and user goals, understanding and focusing on certain types of users, defining a product or service, and avoiding the elastic user and self — referential design.”
Focusing on the goals of the Job Executor rather than an aggregate demographic description allows designers and marketers to develop an offering that’ll best resonate with and serve customers under the appropriate circumstances.
In theory, a Job-centric Persona should be solution-agnostic, staying away from references to specific products or features. But in practice, a product team may find they have to include some references to specific product-related behavior.
Which should come first, the Job or the Persona?
This topic was discussed in the #JTBD podcast “Adding Jobs to be Done to a persona-based product development process” from April 2017, with conflicting viewpoints on the matter. As you may guess, the Manager of UX Research proposed starting with Personas, while the JTBD researchers felt it was best to start with the Job.
I’d say that if you already have goal-driven Personas, it’s ok to start with them. If not, starting with the Job will give you a more complete view of the possibilities for your work.
This is because starting with an existing customer anchors the focus on those who are already hiring solutions to get the Job Done.
Attractive markets are those that are growing, which typically means non-consumers are entering the market. If you’re only focusing on designing for customers who are currently being served by solutions in the market, you’re potentially missing out on those who have the Job, but for whom there isn’t a current solution that serves them.
Uncovering customers’ decision-criteria
There are two prevailing approaches to uncovering what drives customers’ ‘hiring’ decisions as it relates to their Job to be Done.
These are ‘Switch Interviews’ (a derivative of Customer Case Research) and ‘Outcome-Driven Innovation (ODI) interviews’.
In Switch interviews, customers who’ve made a “switch” in the solution they’ve hired to get their Job Done are interviewed. These qualitative interviews focus on uncovering the forces pushing, pulling or inhibiting customers while choosing between existing products on the market.
This approach likely feels the most natural for a UX team. We are anchored on describing behavior a customer has taken, and trying to connect the dots to understand the motivating factors behind it.
The Outcome-Driven Innovation approach is much more intensive, as it focuses on creating a comprehensive inventory of the Desired Outcomes a customer has as it relates to a Job. This is independent of what solutions already exist. (For example, a Desired Outcome for ‘communicating with people who aren’t in the same physical location’ is to “minimize the time it takes to connect with people who aren’t in the same physical location”.
A Web conferencing Product Manager could choose to develop a calendar-scraping app that immediately dialed into your conference at the time of your call, or an Innovator could design vc vtime travel.
Is there a 1:1 mapping of Job to Persona?
Very unlikely! To use the model developed by Jim Kalbach, a Job to be Done is a combination of the Situation, Motivations, the Functional, Emotional and Social Jobs to be Done, and the Desired Outcome(s).
Two people may have the same Job to be Done, but have different motivations for doing so. Or, they value certain outcomes differently. In Outcome-Driven Innovation, this is termed “outcome-driven segmentation.”
You could develop a persona for Job Executors who have a social Job to be perceived as professional and trustworthy by others, and another for Job Executors who have a dominant emotional Job to feel competent and confident.
In this case, the core functional Job is stil the same: “to communicate with others who are not in the same physical location”, but you could develop personas to segment them by Desired Outcome.
In other cases, you may find that customers are hiring your product for a number of different Jobs. Those would also be great candidates for personas.
Developing Personas
Looking at the “10 Steps to Personas” infographic by Lene Nielsen, one can imagine that the Job serves as step 0 in identifying the users.
In the 2008 article “Getting From Research to Personas: Harnessing the Power of Data”, Kim Goodwin outlines 6 considerations in developing useful personas.
- Start with the right kind of research
- Identify behavioral patterns from the data
- Assemble your persona descriptions around behavioral patterns
- Describe your personas in narrative form
- Avoid false precisions
- Build your product on the best foundation
There is nothing here that is incongruent with the theory of Jobs to be Done.
Can we retro-fit our existing personas?
If you have existing design/goal-driven personas, you have a great starting point. But be careful you’re not falling prey to assumptions about what drives or inhibits your customers’ decisions, and that your personas are tied to context.
“Organizations with more than one product often want to use the same personas over and over (“We have a salesperson persona already — why can’t we use her for the spreadsheet as well as the contact management software?”). Unfortunately, this doesn’t work because effective personas must be context-specific — they should be focused on the behaviors and goals related to the specific domain of a product. A persona’s behaviors and goals related to contact management have very little to do with those related to manipulating financial data. ‘ — (Kim Goodwin, Perfecting your Personas)
Summary
Personas are wonderful artifacts to help a team hold a shared understanding of the customer they’re designing for. There is nothing inherently incompatible about Jobs to be Done and Personas. The nuance is in how detailed to make the personas so they can serve as a useful tool for their intended audience.
Learned something? Click the 👏 to say “Thanks!” and help others find this article.
Andrea Hill is the principal consultant at Frameplay. Frameplay is an innovation consultancy that helps companies become more customer-focused and thrive in a rapidly changing world. Learn more at frameplay.co
