Personas and Jobs To Be Done
Thoughts on the growing divide between jobs to be done and personas
I read more articles over time decrying personas in light of the jobs to be done (JTBD) framework. I generally favor JTBD myself, but I, like others, am not ready to proclaim personas dead yet. Every tool has it’s time and place.
The issue that comes up in articles seems to center on the personas that promote a shallow characterization of customers. This is indeed an issue for the UX and product management world. However, personas come in many flavors and each has strengths and weaknesses. The question is not whether personas are good or bad generally, but whether or not they convey meaning for a specific purpose. The four persona types below each lie along various continuums of time and effort needed to create, depth of insight given, etc.
Proto persona
Proto personas are making inroads given the trend toward lean principles. They’re initially created from best guesses until customer contact provides information on which to revise them. This is acceptable as long as there’s follow through to ensure greater accuracy.
Demographic/marketing persona
These personas are the ones that rile people. They go something like this: Steve the Stereotype has a wife, two young kids, likes to golf, is 35-45, etc. These are acceptable for some marketing and advertising purposes when you’re looking to reach a block of people who share some similarities and, based on that similarity, can be reached in a consistent manner. ESPN reaches sports enthusiasts, for example. I wouldn’t use these for UX or product decisions. These are the types of personas I rail against too.
Design/user persona
Kim Goodwin has a robust, thorough methodology to create design/user personas (that fits within an equally robust and thorough product creation methodology). For me, it’s the gold standard of personas because they’re built upon solid research of real people. I reserve the right to question the addition of personality details, but those can help create empathy which isn’t a bad thing.
Empathy persona
If your intention is to create empathy among staff who don’t or can’t get regular customer contact, an empathy persona can offer a decent alternative. They’re not perfect, but they do provide a reminder that humans are the beneficiaries (or victims) of our product choices.
My preference is to create proto personas, though I would rarely share these with my client. They’re lightweight, quick and nimble which works for the equally lightweight, quick and nimble way our company works. They’re a means to an end in my workflow and needn’t be a milestone deliverable. Create ’em if you need ’em.
In reality, I’m more apt to filter the best from the design/user persona approach using jobs to be done thinking. I believe well crafted personas have a lot in common with JTBD analysis, it’s mainly a difference in focus: “According to Clayton Christensen, the customer is the wrong unit of analysis for innovators to focus on. Instead, focus on the job that customers are trying to get done when they use your product or service.” In effect, JTBD keeps the goals, needs and behavioral aspects of the best personas—the “what” and “why” of understanding customers—and drops most of the “who” information found in demographic data and filler background stories found in demographic/marketing personas. You end up wringing out the personal notes in order to distill and clarify jobs, situational awareness, desired outcome states and the causality, motivation and triggers that tie all these concepts together. In a sense, JTBD cuts to the chase which is useful in an agile workflow. It prioritizes information, focuses effort and clarifies the root issues at hand.
Of course, your mileage may vary.
You can continue to investigate JTBD topics below.
