Personas and their jobs

The usage of personas has always been controversial amongst designers and professionals within the industry. But lately a few practitioners in the field of product development / design pushed for the substitution of the personas' method by the framework jobs-to-be-done (JTBD)
Which is the best tool/methodology? Should you change from personas to jobs-to-be-done?

Despite the fact that personas seem to be “out-of-fashion” we, at Imaginary Cloud, defend that this technique is still bringing some huge advantages to product design and development when done properly with that context in mind. A careful analysis of both the personas' and JTBD method, allied to the insights coming from field practice, make us believe that while there are, in fact, some problems with the personas' method, this technique helps in some critical aspects of design and project management that the JTBD method is not able to cover.

Our approach is to merge both techniques, to bring together the best of each one, resulting in a hybrid solution.

What are Jobs to Be Done (a.k.a. JBTD)?

The title "Jobs to be done" refers to a framework that can be used to help define a product scope, its requirements or marketing positioning. It's based on the premiss that when a person buys a product (or service), that person is not actually buying it, but hiring it to execute a certain job: “People don’t want a quarter-inch drill, they want a quarter-inch hole

If you want to understand better the JTBD framework, we recommend you to check this video by Clayton Christensen, or consulting the website But, in sum, a "job to be done" consists of four parts:

  • exposition,
  • observation,
  • situational analysis and
  • the "Job to be done".

The exposition presents the context of the product, meaning the customer struggle, briefly explaining the who, what, when and where (but not the why).

In the observation, the current and past users' behaviours are identified, namely what products they're using.

The situational analysis is about the motivations and anxieties of the users, explaining the challenges that customers are facing and what is pushing them to and from different solutions.

Finally, the "Job to be done" itself is about the desired outcome that the user is looking for - It shouldn’t present a solution (product/feature/requirement) but, instead, a description of what should be accomplished by the user at a higher level (see)

This methodology is considered for some to be better suited than personas for product development due to the fact that it is Outcome-Driven, objective and measurable (from here). Already personas would be based on demographics, therefore not having a clear causality relation with behaviour by being based on stereotypes and consequently, on prejudices (from here and here).

The Problem of personas

While we agree that this is sometimes the case (maybe too often the case), resulting in detrimental effects to the product development (and compromising professional ethics, I would say); the main reasons why this happens is that while personas seem like a very straightforward technique to understand and execute, in reality, they take a lot of time, study and practice to fully understand.

There are a lot of approaches that can be taken to personas, with some being fairly poor and others being ok, but only to serve some specific purposes that shouldn't include product design and development.

Loosely defined personas are a technique to model users; they are archetypes, formalised in writing as fictional (but realistic) characters. While many designers and design/engineer companies claim to use personas, when observing their practice, we see that what is being called “personas” includes a range of very diverse materials. The information that configures in a persona (and even the source of information) changes considerably from one designer/company to another, and so, naturally, the potential of this technique changes as well. If we carefully observe the several ways of doing personas we can identify 3 or 4 different types (see here)

The first type of persona is not actually a persona but a “proto-persona”, and all the other types of personas can be made as a true persona or as a proto-persona. Proto-personas are personas that are not based on actual research, but instead in assumptions about the users. This type of persona requires the people involved in making them to have insightful knowledge about the real users; you shouldn't only have designers (or engineers) doing them, but you should instead gather people from the customer support department at the table, for instance. Proto-Personas are ok to use ONLY as a first step to guide further user research but never as a basis for the product requirements (because, well, assumptions!).

The second type of personas we can identify are “Empathy personas”. Empathy personas are built around a persona's background story (a narrative about the persona life and context) usually with a name, age, photo and quote. This type of persona may be useful to create empathy in the development team, helping them to keep motivated during the project. Professionals who don’t have regular contact with costumers may loose, or not have, the vision about the utility and relevance of the product, in which case, knowing someone for whom the product will make a difference, may help them understanding their efforts in a higher context. But, in the end, this type of personas are of little to no use when it comes to establishing the product requirements and the project plan.

The third type of personas we can identify are the “Marketing / Demographic” personas. Whilst the worst that can happen with an empathy persona being used for other goals that not the ones listed above, like establishing product requirements, is that it turns out being a waste of time, the marketing/demographic personas can really be damaging for your product development (specially if we are talking about marketing proto-personas). Marketing personas have a focus on demographics, trying to find the root for the user's behaviours and desires in that data. This is the type of personas against which most job-to-be-done defenders raise against, since there is no true causality between demographics, goals and behaviours, and the identified patterns are usually the result of prejudices and stereotypes. Even if they're not the result of prejudices and stereotypes, those "patterns" will still end up being their perpetrator.

It's worthy to take a minute to think about the context where this mindset comes from. When marketing started to be developed as a subject matter of its own we were then in an extremely segmented society, marked by gender, class, “race” and political prejudices. Individuals were severely constrained by those attributes; plus a few other practical constraints, like lower geographical mobility, low quality of life for senior people, etc. What someone could, therefore, do or aspire was conditioned without much leeway. Consequently, the relation between demographic attributes, goals and behaviours were more straightforward.

Nowadays,the situation is completely different. Today, the access to information is much more democratic: people, goods and data, travel faster; woman and people of color have more opportunities, senior people live longer and better, keeping active minds and lifestyles, and so on. It is only natural that a new way of modelling users is needed to face a liquid society. But this doesn’t necessarily imply breaking up completely with personas. A fourth approach to personas answers this new paradigm.

This fourth approach named "goal oriented personas" or "design-personas", relegates the persona's background story and demographics to a secondary plan and focuses on goals & needs. These personas specifically identify life goals, experience goals and end goals, as well as needs, frustrations and behaviours. This type of persona gets very close to the "Jobs to be done" methodology while preserving some attributes that give personas some of their power, a power that goes beyond creating empathy to motivate the team. If you want to know more about goal-oriented personas we recommend you to check Alan Cooper book “About Face”.

Looking at the critic from Intercom for instance, one of the most prominent voices in the defence of "JTBD" and against personas; they present us, as an example, the following user story based on a persona:

“As a 35 old man called Peter, I want to eat something tasty when I'm hungry, so I don’t feel hungry anymore”.

While we couldn’t agree more with the critic pointed that the first part “As a 35 old man called Peter...” is irrelevant - since there is no causality between that data and the last part of the sentence - this is a persona's method's example that uses user-stories and not user-journeys (but that would be material for another post). Therefore, as we see, this argument is only applicable to marketing personas and not to design or goal-oriented personas.

If it was a goal-oriented persona the story would have been something like: ”As a senior chronicle patient who wants to enjoy her/his retirement the most, I want to be able to easily contact my doctor anytime I need, so I can feel relaxed about my wealth status” - it would only refer to demographics that would have a causality relation with the persona's goals and focus on the desired outcome, making it very similar to the job-to-be-done.

The problems with JTBD / In defense of personas

Continuing with the critics from Intercom (from here and here), when presenting their equivalent JTBD they give the following example:

“ When I have only 2 minutes to stave off hunger between meetings, I want to grab something that will be quick and easy”.

But what is “easy”?

Things like “easy” or “pleasant” are subjective attributes, it's not an attribute of the product itself but of the experience of the user with the product, being completely dependent on the user's attributes. This means it is impossible to evaluate those attributes without having some sort of user profile; specifically experience goals, expertise, knowledge, intellectual, motor skills…

Let’s say the JBTD is “to have a place to save my files in a way that is easy to find them”. In terms of design, for some, this may reflect in a hierarchical and well-organized folders structure or in a simple repository folder with a search field. How do we solve those questions?

This brings us to three common project pitfalls that personas have the potential to avoid, but, in our opinion, JTBD don’t. These are: the elastic user, self-referential design and edge cases (from here).

If we don’t precise the term “user” this will cause trouble when applied to specific design problems. Every person on a product team has their own conceptions when it’s time to make product decisions, and so this “user” becomes elastic, conveniently bending and stretching to fit the opinions and presumptions of whoever is talking, and when making design decisions something may be considered “easy for the users” and the next one, of the same complexity, “too hard for the user”.

Inevitably, things fall into a self-referential design with either designers / developers or clients, depending on who holds more power of decision-making in the project, ending up making design decisions based on their tastes and preferences. Especially in the "look & feel" stage, this often becomes an endless discussion between what each person finds “nicer”.

Also, in the same way, “easy”, “pleasant” and “beautiful” are subjective things, so is “important”. Once you start thinking about the several jobs to be done for the product, you will probably end up with a list that you won't have the time nor budget to fully develop. And even if you have it, you will have to know where to start. Information like how often a persona does something will help a lot when it comes to prioritising features.

In sum, jobs to be done reveals itself very useful to uncover the “what” of a product, but it doesn’t give much insight on the “how” - but users are as equally concerned with accomplishing the goal as with the process to achieve it. This is what user experience design is about. The straight-forwardness of the JTBD is temptress but it falls back to the engineering mindset about universality and objectivity, forgetting that, firstly, there are different ways of getting to the same end and that, secondly, users are emotional creatures that look for more than the accomplishment of objective goals.

The solution

So, are goal-oriented personas the answer? We are not sure. In our practice we still find a few problems in that method. While demographics and background stories are relegated to second plan, they are still there and this results in a few problems.

Mainly, because they are intended to be a communication tool between the entire team, personas are being handled by people with different backgrounds, from developers to clients, but it often happens that not everyone is involved in this process of deconstructing the role of demographics.

That being said, those attributes, often, reveal themselves to be considerable distractors. Developers find themselves a bit lost in personas, not assimilating their importance for the implementation work and having trouble to grasp the relevant information from the rest. Clients sometimes have troubles distancing from pre-conceptions about how that "single and shy" demographic in the persona relates to things like the product's look & feel: refer to the persona as a he, and you will find yourself struggling to explain why lavender is still the best color for your interface, since the persona's experience goal is to feel calm, relaxed and luxurious.

So, how to take into account the human subjectivity, being both able to create a character that team members can relate to, see as the person which's “opinion” should be the main one taken into consideration in the decision-making process, and avoid stereotypes and prejudices related to profiling?

Here at Imaginary Cloud, we decided to merge both personas and JTBD. We do develop personas, but in a way that is closer to jobs to be done:

- We avoid demographics to the maximum possible or, when necessary, keep them relevant to each specific product context;

- We replaced the background story for the exposition - the difference being that the first is about the person's life and the second one about the context of usage of the product;

- We limit behaviours' descriptions to the ones relevant for the product context, in a way similar to observation, rather than going with the traditional personas' inclusion of the additional hobbies that are more related with lifestyle than with goals;

- We go a bit deeper in exploring the user's frustrations and needs, correspondent to the "situational analysis" in JTBD, and the "user-goals", in the place of the "job to be done" for that persona;

- We keep the persona nomenclature: "behaviours" rather than "observation", "needs & frustrations" rather than "situational analysis" and "end-goals / experience-goals" rather than "JTBD" for a matter of better conveying what they are about.

For someone who hasn’t read about JTBD is not clear what observation and situational analysis are about, and what the difference is between then. Plus, the name “Job to be done” easily drives people into thinking about solutions (actual system requirements) rather than about desired outcomes from the user's point of view, which is premature at this point of the design thinking process, when no design solutions were yet studied and drafted.

The product design process is a constant work-in-progress. There isn’t a perfect methodology and we should keep a critical posture in face of all methodologies, acknowledging that some projects (or some clients, or some teams) may be better served with something closer to one method and other projects/clients/teams, with others methods.

In the end, above all, methodologies should be faced with a flexible mindset, seen more as guidelines than as rigid prescriptions, being that the space for improvement should be acknowledged. Simply put, you shouldn't be afraid of innovating in the way that better suits your product, teams and professional skills.