It’s okay to use both personas and JTBD

Michael Le
Feb 12, 2017 · 4 min read
My milkshake brings the product people to the yard. Because JTBD articles mention milkshakes 😜

Many JTBD practitioners say that by doing JTBD you don’t need personas anymore. But is that true? In my personal experience I would say that both work well together.

Understanding who will be using your product

I found personas useful at the beginning of a project when you don’t know much about the users. Mandated by the business or based on a gut feel of who the team thinks the user is, a proto persona is a great way to get a general idea quickly. This can kick start the search/recruitment of users and feedback from the interviews can provide learnings to validate/invalidate points made in the proto persona.

Proto personas when used properly allow teams to have an evolving picture of who they are designing for. Sometimes teams forget to update this picture of the user and this is where personas lose their value.

Understanding why people choose to use your product

Before using your product your users need to choose your product out of all of the other products out there. This is where JTBD comes in. For someone to switch from one product/process to another is not a trivial insight to find. The JTBD framework uses two methods during user interviews of analysis using the timeline and forces.

The outcome of the timeline and forces help define the job that your users are trying to achieve.

Framing context better than “As a user…”

As a designer user stories that start off as “as a user” have rarely given me enough information to be confident that my design is actually solving the user’s problem. The reason is that context of the user is missing. Some product managers include a lengthly piece about context in addition to the user story but most don’t. Switching from user stories “Given/When/Then” to job stories “When/I want to/So that I can” is an efficient way to include context.

In practice, I have used job stories to frame design critiques. It allows the team to jump into the right mindset that a user would be in when encountering this problem and then critiquing whether the proposed solution would allow the user to be successful in achieving that job.

Linking personas with their jobs

As Nikkel Blaase wrote about product thinking that personas and the JTBD framework can be used to find “product-solution fit”.

Having a solution in mind helps with JTBD. However at the beginning of the project, you may not have a solution defined yet so asking questions around the pull of your new solution from their current process might not be appropriate. In an iterative process, like the persona which evolves the understanding of the job to be done evolves as well.

Things may be vague at the beginning but over rounds of research things come into light

Empathy not sympathy

Personas give you that focus when you are first building a product. Otherwise you will end up trying to building for everyone before having product market fit. JTBD allow you to understand and articulate the problem better. This will help you focus on how you are building your product to solve a problem.

With both of these tools, what we want is to do is to listen to users when we speak with them rather than trying to hear for the points that would fit them into one of our predefined boxes just so that we can say we went through user validation.

When we listen, we can empathise with our users and understand enough about their situation to solve their problem as if it was our own.

If the best way right now for me to do this is to use a combination of personas and JTBD then that is the good enough solution for now. Just as we moved from marketing personas to proto personas to get a realistic picture of our user, the principle of getting to know the user better has not changed, only the methods have changed.

Michael Le

Written by

Product designer, speaker, father, design mentor #ux. Based in Sydney. Creator of Navibaby