Job-based Personas
Augmenting personas with jobs to be done
Design personas have been around since Alan Cooper created them in the 80s. However, the concept of using archetypal market segmentation to help develop software for “target users” has been around even longer. We, at Hostile Sheep, love Alan Cooper and all the work he’s done on personas; especially his manifesto for building personas The Inmates Are Running the Asylum (1999). I followed Alans career early on, and was exposed to work his consultancy (Cooper) produced for a common client. I had a chance to see him speak and was able to learn from their CooperU initiative. Suffice it to say, I heavily bought into Cooper-style personas and his Goal Directed Design process. I helped several organizations develop personas and implement Goal Directed Design principles into their product design process. Then I met Clayton Christensen (Harvard Business School) and learned about work he, Bob Moesta and Rick Pedi were doing. After some robust training, I moved away from Cooper-style personas in favour of a jobs-to-be-done-based product design process.
Persuasion and the JTBD blind-spot
Jobs-to-be-done is great for developing products that function well; they help users get jobs done. However, there’s a major blind-spot in the jobs theory. If you’re familiar with Aristotles modes of persuasion (Logos, Pathos, Ethos), Jobs-to-be-done is a very Logos-heavy framework. It heavily relies on logic and reason (logos); conversely, it almost ignores emotion (pathos) and credibility (ethos). But, as Aristotle taught us, the most persuasive arguments use logic, emotion, and credibility. And, for those who aren’t familiar, JTBD is all about persuading customers to ‘hire’ (or use) your product instead of your competitors. So, bringing emotion and credibility to JTBD has been an important evolution of the theory.
Tony Ulwick (and Strategyn) built a patented design process known as Outcome Driven Innovation (ODI) that used much of the work Christensen and Moesta pioneered with JTBD. The Strategyn Jobs-to-be-done framework involves defining core (functional) jobs, then defining related emotional and social jobs. Ultimately, customers use products to get functional jobs done; thus, defining the functional aspects of the core job is a smart way to begin. We know that people also use products to feel a particular way; for instance, my MacBook makes me feel comfortable, focused and secure. These are emotional jobs. We also know that people use products to make a “ethos” based argument; remember Aristotle defined the ethos-pillar-of-persuasion as “trust, credibility, or character”. You can see this in action when people take selfies in a mirror, showing off their phone over their face. In this case, people want to be perceived in a certain way by their friends. “I have an iPhone, so I must be smart, hip, edgy, rich, doing well, etc.” These are social jobs.
So, defining emotional aspects of jobs-to-be-done is something that’s being done and has guidelines and rationalization available. That said, emotional jobs aren’t able to replace personas. Remember, personas were created to empathize with the customers who would eventually be using the product. As well, personas were supposed to help product designers internalize the mindset of the customer in order to fix flaws and exploit opportunities early in the design process. Well, Hostile Sheep saw the opportunity to combine the best parts of JTBD, design personas, and Goal-Directed-Design.
Combining Jobs-to-be-done with design personas
Another design leader we love is Jared Spool, who has been vocal about the inclusion of scenarios within design personas for years. He developed a process for creating “scenario-based personas”, which was the inspiration for our job-based personas. In order to develop job-based personas, we begin by defining the job-to-be done (if not already done). Organizations and systems often help users get several jobs done, while products often focus on getting a single job done. Depending on the complexity and stage in the product lifecycle, we may conduct some research to validate the job-to-be-done.
- JTBD market survey: A quantitative method for validating the job-to-be-done and defining the market as a component of the job. A target market shouldn’t be changing every year or iteration, it should be stable over time; thus, should be integrated with the job-to-be-done. As such, the survey will result in the identification of a target audience that can be concatenated with the job. For instance, a job may be to “Fix a hole in drywall.” and the target audience may be “Homeowners”. This can be concatenated as “Homeowners fixing a hole in drywall.” and that represents a specific market. A side-effect of this type of survey is that the job-to-be-done will also be validated.
After we have a valid job-to-be-done defined and a market who’ll be targeted with the product (or system or organization), we generally want to uncover the customers “goals” or “desired outcomes” of using the product. We do this through qualitative customer interviews.
- JTDB customer interviews: We recruit people who’ve recently ‘hired’ the product (or organization) or ‘hired/fired’ the competition. We find out why each person hired or fired the product or organization. How did they use the product? What did they expect from using the product? How did the product fall short? How did they decide to ‘hire’ a different product?
These interviews will also allow us to prioritize the customers desired outcomes based on how well the outcomes are served by existing products and the importance of the outcome to the customer. Highly important outcomes that are underserved represent the biggest opportunities to create a valuable, successful product, organization or system.
Once we have a breakdown of prioritized outcomes, we can start building our personas. As I mentioned earlier, Alan Cooper did a lot of great work refining design personas, so we based our job-based personas on his work… with a few adjustments.
Problems job-based personas solve
Standard Cooper-style personas have a number of issues we try to solve with jobs-based personas. We include the majority of the content that is generally included in standard Cooper-style personas, but the primary categorization of personas is based on a job, instead of a role. There are a few other additions we wanted to include as well.
- Jobs over roles: One of the biggest issues product designers have with Cooper-style personas is that they’re often role-based. (e.g. lawyer, nurse, teacher.) Roles don’t always use products the same way; they often want very different jobs from using a product. Additionally, roles change all the time; names, responsibilities, operations, technologies used, etc. Jobs, on the other hand, are defined as a specific way of using a product. They’re also stable; rarely changing over time.
- The gender issue: We use a job-based target audience at the very top of the job-based persona. This represents a market segment and is (almost) always gender-neutral. Even though the persona may be gender-specific, the product design team can learn about the market segment (e.g. Online shoppers sending money securely.) without needing to adopt the perspective of a particular gender. Conversely, the persona can be gender-specific; which can help the product design team when developing empathy for the ‘target’ customer.
- Job breakdown: Even within organizations that use JTBD, understanding the hierarchy of jobs>tasks>outcomes can be challenging. In our job-based personas, we break down the jobs, tasks and outcomes. Jobs rarely change, tasks change more often, and outcomes change more often. Thus, personas should be re-visited (at least) annually.
- Understanding tasks: Tasks (or scenarios) are necessary for useful personas; a job-to-be-done consists of a number of tasks (or scenarios or steps) which are useful to understand in detail. Therefore, including them in the persona; the entire design team can familiarize themselves with the most important tasks users need to complete in order to complete the job-to-be-done.
- Understanding desired outcomes: Where tasks are functional, outcomes can either be functional or emotional, and represent what users expect by using the product to get the job done. Understanding what users expect will help the entire product design team build-in features/content that will deliver on those user expectations.
Jobs to be done can be used for a number of different things; selecting the right market, product planning and strategy, product design, and optimizing the customer experience. Hostile Sheep generally uses JTBD for product design, thus job-based personas are extremely helpful for our process; as well as being helpful for our clients continuous improvement efforts and our clients external vendors who also work on their products. The clients we’ve introduced to job-based personas don’t use a 100% JTBD design process; but they still find value using job-based personas. Job-based personas are an easy way to introduce JTBD to an organization. We’ve witnessed a shift in thinking when we’ve implemented job-based personas.
So, I hope you consider using job-based personas yourself. If you don’t have personas yet, this is a great framework to build your own. If you already have personas, have a look at the job-based personas and you’ll find a lot of similarities to your own personas. Augmenting existing personas, to be job-based, is an easy exercise and can have a meaningful impact to your design process. And remember, personas (and design artifacts in general) are deeply unique to each individual organization and team. Think of our job-based personas as a set of guidelines; not rules. Add stuff that your organization or team needs; remove stuff they don’t.
Above all; use your personas. Experiment with them. Learn about them. Add, change and evolve your personas regularly. Because, even though the jobs won’t change, the people who do the jobs will. Some of the goals or desired outcomes may change. Even the tasks may change as technology or mindsets evolve. So, we always recommend assigning a persona owner (usually the product manager) who is authorized to change personas as needed.
