Personas vs. Jobs to Be Done

A persona is a fictional but realistic and rich representation of a typical user of a product or service, and it is used to understand the needs, goals, and behaviors of different types of users.

Role-based personas synthesize quantitative data you gathered from user and market research, including demographic and behavioral information. Proto-personas are based on the assumptions and past experiences of stakeholders and team members, and they help describe a product's potential user base.^[1]

Personas are a valuable tool for understanding and empathizing with your users and can help guide product and marketing decisions.

The jobs to be done (JTBD) technique is a framework that focuses on understanding the needs and motivations of customers by identifying the "jobs" they try to do when using a product or service. The JTBD framework consists of identifying a job, understanding the context in which it occurs, and determining the desired outcome and solution. It is based on the assumption that users "hire" products to accomplish their tasks and "fire" unsatisfactory products.^[2]

Unlike personas, it focuses on the job that users are trying to accomplish rather than their demographic or behavioral characteristics. This means that JTBD is better at identifying and meeting customer needs, and it also helps businesses differentiate themselves from competitors by focusing on specific jobs. However, one disadvantage of this technique is that it does not provide as much detail into what users are doing and feeling, so it may not capture all the complexities involved in customer decision-making.

Team members can relate to personas on a personal level — by giving the user a name, face, and backstory. Personas make users more realistic and easier to understand.

Personas are different from jobs to be done in that they provide details about users' deep motivations and feelings, making it easier to empathize with them. For example, if a persona describes users who are frustrated with their current product because it takes too long to complete a task, team members can empathize with that frustration and work to develop a product that addresses that pain point.

Personas also include more information about the high-level context in which users are using products or services or facing issues. For example, if a persona describes users who are always on the go, team members can empathize with their need for mobile accessibility and work to develop a product that meets that need.

By creating relatable fictional representations of their users, team members can better understand their perspectives and develop products that work for them.

The jobs to be done (JTBD) approach focuses on the specific tasks — or jobs — that users are aiming to achieve when using a product or service, rather than their demographic or behavioral traits. This makes them more valuable for short-term decision-making.

As they understand the tasks and desired outcomes, product teams can directly address users' needs and create features that satisfy them. Personas, on the other hand, offer more insight into users' daily life and behaviors, but they may lack clarity on what exactly users are trying to achieve.

By zeroing in on users' specific goals and uncovering their unmet needs, jobs to be done offer opportunities for building business innovation, making services more competitive, and improving their overall experiences.

Personas and jobs to be done (JTBD) provide complementary insights for product design, enabling prioritization among different user needs. Personas focus on unique user groups (like busy parents or budget-conscious seniors), while jobs to be done focus on their different tasks or goals (like finding products quickly or comparing prices). Together, they help teams determine what users aim to achieve and prioritize features accordingly.

Using both multiple personas and jobs to be done makes sense as they offer varied perspectives on users. A multifaceted approach captures the breadth of users' needs and goals, allowing teams to address a wider audience. For example, if a particularly significant job to be done, like "quick product search," is associated with multiple personas, it can be prioritized over other, less important functionalities.

While both tools are valuable, there's a key difference between using multiple personas and jobs to be done. Personas provide insights based on demographic or behavioral characteristics, helping teams understand unique user needs and empathize with varied user groups. On the other hand, jobs to be done reveal common user goals across different groups, regardless of their personas, focusing on task completion. When used together, they provide a comprehensive understanding of user needs, supporting strategic product development.^[3]

Research objectives can help you decide whether to use personas or jobs to be done (JTBD) in a project. They will guide what kind of data is needed, how it will be collected, and what insights should be derived from it. Here are a few examples:

• Understanding customer needs: If the goal is to understand customer motivations, JTBD is the best fit. This method focuses on the tasks customers want to perform and their conditions, providing insights into their motivations and unmet needs.
• Crafting marketing campaigns: For targeted marketing efforts, personas are ideal. These provide key characteristics of your audience, allowing you to tailor your campaigns to specific groups.
• Guiding product development: If the goal is to guide product design, a mix of personas and JTBD works best. While personas highlight your audience's characteristics, JTBD sheds light on their tasks. This combination informs effective product development.

Choosing between using personas and jobs to be done (JTBD) depends on available data and the product development stage. JTBD involves deep qualitative research, like interviews, to reveal customer motivations. It's most useful in early product development to identify and meet customer needs.^[4]

On the other hand, personas use a blend of qualitative and quantitative data, including demographic details and usage stats, giving a broad view of user needs and behaviors. This method is more effective for refining the features of an established product based on user feedback.

In short, both personas and jobs to be done offer valuable insights into user needs. The choice between them hinges on data type, product stage, and research goals.

Choosing between personas and jobs to be done (JTBD) depends on resources, time, and the level of detail required.

JTBD research may be more resource-intensive and time-consuming because it involves carrying out in-depth interviews or ethnographic studies to understand customers' needs. This method demands significant investment for research, data analysis, and generating insights.

On the other hand, persona research is quicker and requires fewer resources. It can use existing data or brief surveys to get an overview of user needs and behaviors. Teams might use website analytics or demographics surveys to create personas, representing different user groups based on their requirements, goals, and habits.

If a detailed understanding of user needs and requirements is crucial, jobs to be done are suitable. But for a broader comprehension of user needs, persona research is sufficient. Both personas and JTBD are vital for comprehending user needs, and the choice hinges on the available resources, the level of detail needed, and the specific research goals.

The decision between personas and jobs to be done (JTBD) can vary based on project needs and team goals.

In projects involving a diverse team, personas can be beneficial. They provide a relatable depiction of the user, helping align differing views towards one common goal.

In contrast, for teams focused on product development or innovation, jobs to be done might be more valuable. JTBD aids in identifying customers' unmet needs and problems, potentially inspiring new product ideas or enhancements to existing ones.

Ultimately, whether to use personas or jobs to be done will depend on the project's unique requirements and the team's objectives.