Personas for Design, Development, & Growth

What are Personas?

A persona is a humanized view of a customer or user. Generally, they have a photo and a short description that you might use to, say, introduce them as a friend or a work colleague, depending on what you’re designing or building.

Here’s a quick (partial) example:
If a given persona helps you make better decisions, identify better ideas to test, for example, then it’s a good persona- and the reverse is true, too. That’s the good news. The bad news is that there’s no single formula which will always help you do better work. I mean, there are, but those formulas are overpromising. That said, there are a few fundamentals that will help you get off to a good start.

A Few Persona Fundamentals

I generally think personas should at least have these four elements:

1. A Name
   They have a name- I like the convention ‘[first name] the [role]’, so ‘Andrea the Auditor’ or ‘Dave the Dispatcher’.
2. A Screener
   Always start with a screening question you can use to distinguish subjects vs. non-subject: if you walked up to someone on the street (or water cooler), how would you tell if they are or are not this persona. Even if you’re not about to interview any, this will help make sure your persona is specific enough to be useful.  For example, in the case of ‘Andrea the Auditor’ the screener might be ‘How many accounting audits have you completed in the last three months?’. 
   
3. A Description
   This general description introduces the persona and answers questions like ‘Who are they?’ and ‘What makes them tick?’. The ‘Day in the Life’ tool (see below under- “How..?”) is a good way to step through this. Photos are super helpful since, you know, a picture is worth a thousand words.
4. A Perspective
   I like the use the popular ‘Think See Feel Do’ points to help refine and focus the perspective we suppose the persona has in a way that’s more operational.

If you want to check out more fully articulated examples, feel free to skip down the Example A (Startup) and Example B (Enterprise IT) below.

Why create Personas?

Famed chemist Louis Pasteur said “Chance favors the prepared mind.” I think the way that applies with personas is the fact that we always have more ideas for things we want to build and even more ideas for experiments we’d like to run than we can execute. We have to carefully, specifically consider what we want to learn and the outcomes we want to realize before we start creating output that may be economically and/or scientifically irrelevant.

That proposition is a cornerstone of Hypothesis-Driven Development where we treat personas themselves as a kind of hypothesis- a ‘Persona Hypothesis’. The diagram below shows a product pipeline that iteratively goes from idea to release:

The first steps on a new iteration, going from idea to design, is described in the pipeline as Continuous Design. Unpacking Continuous Design further, a conventional (and useful) framework is the ‘double diamond’ which decouples problem (or ‘job) from solution:

The idea is, if you don’t know specifically who you’re designing for (which persona), anything you accomplish is mostly good luck. A hypothesis-driven approach means that when you’re testing demand, you’ve narrowed your focus to some specific segment/persona. You have a specific idea around who and what you think your proposition addresses. In terms of testing a proposition, you could think of it like this:

How do you know if this is what you need? Well, if you’ve tested or rolled out a solution, users aren’t taking to it as you would like, and you’re not sure what to do next, it may be time to unpack personas and make sure you’re testing demand/motivation relative to a specific ‘Right Problem’ hypothesis.

A Simplified Example

Let’s warm up with a simplified (fun) example from my sometimes collaborator, Laura Klein– a job board to employ your pet. It’s funny because…it is, and it’s useful in considering how we can discard ideas that aren’t meant to be with a minimum of waste. Naturally, we don’t consider our own ideas to be this silly- but maybe we’re not always right about that? I’ve had worse.

Back to our notes on why personas help us, if we’re taking a hypothesis-driven approach what’s the first thing we’d do with this idea? We’d formulate a persona and a job-to-be done-

Persona: Patricia the Pet Owner
JTBD: Creating Income from a Pet

Is this JTBD truly important to Patricia? We need only ask her a few non-leading questions like:

1. What made you decide to buy your pet?
2. What are the top five hardest thing about owning a pet?

If we don’t hear anything about finding her pet a job (and we won’t- except for maybe a few token crazies), then we can infer this JTBD isn’t important to our persona, discard this idea, and move on to our next idea. This is important. As you move through the Continuous Design process, you cost escalates and your options narrow as you converge to a specific design. And this does not even consider the more dramatical escalation in cost and focusing of options as you move to application development and release. The reason Continuous Design is sequenced this way is to give all ideas a fair shake while minimizing waste in order to maximize the team’s target outcome.

A More Nuanced Example

If Jobs for Pets was simple and clearly existential to the venture, this next one is more nuanced and more tactical, though nevertheless important. At one of my last companies, Leonid Systems, we built enterprise software for communications operators- companies like Verizon, Comcast, or Telefonica. One of our products, Loki Portals, was an integration-friendly self-service portal for their cloud telephony customers. For example, you could use it to go in and change the buttons on your desk phone, if you have/had one of those.

Anyway, part of the onboarding process for this product was for our customer (the comm’s operator) to use our software development toolkit (SDK) to customize the portal to fit with the rest of the self-service portal/web application. Simple enough, right? Just have our dev’s make some notes for their dev’s?

Well, it turns out we hadn’t really done our homework on that particular persona- Frida the Front End Dev, we’ll call her. In a couple of cases, the tools that our developers used and standardized on in our SDK weren’t commonplace with a lot of ‘Frida’s’. Onboarding was worryingly slow on a couple of accounts and when our customer success folks looked into it, we found we were making it hard for those customer dev’s to get started and they had a lot on their to-do list in addition to our little web app. So it was very much in our best interests to kind of ‘go where they were’ and dev tools, which we did and unblocked those accounts.

A Multi-Persona ‘Orrery”

When a JTBD involves multiple personas interacting, an ‘orrery’ is useful. The term orrery comes from the scale models of the solar system you may have seen. With personas (and persona hypotheses), this just means something that shows how they interact around a certain JTBD and process.

Back to the Leonid example, we also had a product, Loki Provisioning, that helped standardize and automate the creation of new cloud telephony services. In the before, an End User, say the office manager for an insurance company, orders cloud telephony from one of our customers- specifically from one of their salespeople. That salesperson then sends a bunch of spreadsheets describing what the customer wants to a someone in ‘provisioning’, who then has to do a whole bunch of orchestrated (and error prone) data entry and configuration on various network elements to make all this happen. Often, it breaks and they have to get in touch with the network engineering team to fix it, which generates a lot of downtime and waste, not to mention stress on the part of the staff and annoyance on the part of the customer. This orrery summarizes some of that interaction:

Essentially, our Loki Provisioning product (and the associated onboarding), helped standardize and automate that process:

When should you create Personas?

The most important thing is to begin with an end in mind. If you’re developing a new product and using Hypothesis-Driven Development, this might just be exploring a set of customers for a new idea. Equally valid might be a design challenge from marketing like ‘How might we better understand our customers so we can better focus and measure our next batch of marketing investments?’.

The next most important thing is just to put pen to paper and get started. Don’t overthink it, but do be ready to revise it. That said, here is a view on the way I recommend teams generally approach the use of personas:

As I mentioned, I like to start by drafting from what I know (step 02). There’s a perspective that you should do interviews first to avoid biasing your perspective, but what I find is that: a) if teams don’t draft, they don’t really know what they want to learn when they interview subjects and b) if you’re not ready to revise your draft, you’re probably not going to end up with highly useful personas anyway.

After drafting, you’ll probably have a strong sense of all the things you don’t actually know about this persona and/or suspect you know but haven’t actually observed. This is a great time to continue the process and move to drafting your interview guide (step 03). We’ll step through this in more detail in the section ‘Talking to Customers’, but basically this is a progression of open-ended questions you’ll use when you’re talking to subjects that map to your persona(s). From there, you go talk to subjects (step 05) and iterate on your draft.

There is also the question of whether you want to do Day in the Life. You’ll probably want to decide this in advance since it requires getting photos from your subjects (as always, be sure to get appropriate releases/permissions).

I advise having relevant personas on hand at the beginning of any project. If you don’t have them, block off 30-60 minutes and draft a few as a first step. Good design is about focus, and if you don’t know who you’re building for (or promoting to) it’s impossible to achieve.

Who creates Personas?

In short, anyone who wants. If you don’t already have some substantial narrative about your customer, it can only help. The main thing is to start with some specific intention. For example, if you’re working out who specifically your early market for a new product or feature might be, you could use personas to improve the quality of a discussion about who the customer is and how to connect with them. From there, the other thing that’s important is that the personas are in some kind of working document that everyone is encouraged to augment, edit, or at least suggest changes to. Synchronous web docs like Google Docs or the MSFT equivalent are a good way to go, in practice.

While there’s more about this in the Discovery Handbook, if you’re working with personas you’ll probably want to go out and explore or test them with real subjects. So, even if it’s a one week design sprint by a product team, usually the work of drafting, editing personas and the work of going out and interviewing customers is done by the same folks.

How do you create Personas?

How do I get started?

If you’re dying to get started, here’s a personas template in Google Doc’s- you can copy it to your Google account (File >> Make a Copy) or download it as a Microsoft Word file (File >> Download As). If you want more ideas on how to better create and use personas, come on back anytime.

Note: I recommend drafting your jobs-to-be-done in parallel.

Why draft before you go out and do interviews?

I like to start by drafting, particularly with teams that are new to using personas or personas of the type you’re seeing in the examples. I find that it a) creates clarify and focus around the deliverables for research and b) helps the team (and myself) see how little we really know about the specifics, motivating the research. Much better designers than myself will point out the danger of biasing the team by doing this in advance of talking to subjects. I’ve found the benefits outweigh the costs. You may find otherwise and switching up the order of this process some is no big deal.

What do I say about the persona?

Good personas tell a story. If you watch interviews with innovators like Jack Dorsey (Twitter, Square), you’ll often hear them talk about how they’ve learned to be better storytellers. This isn’t to discount the importance of being rigorous and quantitive- it’s to anchor that rigor in a meaningful starting point and identify the right tools for that starting point.

Avoid bullet points. The ‘plastic persona’ you see is the opposite of what you want. The photo is clipart from the Internet. The description is a set of generic bullet points and they don’t say much of anything about who this person really is or what they want. Get real photos. Create a collage of real stuff. If you’re saying that your target persona Tweets or posts certain types of content online, get examples. If you’re saying that they hate doing paperwork, get samples of the kind of paperwork they have to do. Write full sentences that deliver a narrative. Speaking of pictures, include them, and make sure they’re real, actual people from in the target persona group. 

The ‘organic persona’ is a better start. There’s an actual paragraph of description, and that the photo was taken with an iPhone out in the field, which is where you should be when you’re developing personas. I personally like to give all the personas a first name- ‘Mary the Mom’; ‘Andrew the Accountant’. One of the top failure modes of persona creation is that they have their humanity peeled away or just never acquire it. Giving them a name is a trick that helps humanize them.

How do I get un-stuck?

If you’re having trouble putting pen to paper, think through a day in this persona’s life. What’s the first thing (in your area) they think about after they wake up in the morning? What about before they go to bed? What happens in between? What motivates them? Demotivates them?

All that said- less is more. If this is your first draft, your job is to think about what you know and what you don’t know to focus and motivate you when you go out and talk to a real subjects (customers, users, etc.). Oh- and photos. Find a photo or set of photos you can use. That will really help you keep the persona human.

Below is an example from ‘HVAC in a Hurry’, a fictional company I use in my Coursera course. HVAC standard for heating, ventilation, and air conditioning and that’s what the company does: maintains and repairs HVAC’s for businesses. They’re building an app for the field technicians. Here’s the first paragraph the persona ‘Trent the Technician’ (for the full persona, see Reference B):

EXCERPT FROM
PERSONA

How do I make sure my persona is good?

In classes and workshops, I get the questions a lot: ‘How do I know when I’m done? In good shape?”. The long answer is that with a tool like personas, it’s always a work in progress. The short version is that there are a few things you can quickly validate to help make sure you’re on track.

To that end, inspired by Bill Wake’s INVEST acronym for thinking about user stories, I offer you the REACT checklist:

How do I decide which personas to draft?

On specific steps, there are many paths to arrive at quality personas. Here are the general steps I use with students and advisees:

These are the steps for drafting. Following the drafting, you’ll move on to the hugely important task of actually interviewing real subjects and using that insight to revise your personas. We’ll get to that shortly. Next, we’ll step through a popular framework for making sure your personas will be useful for driving action in your particular area.

Focusing Perspective with Think-See-Feel-Do

Once you’ve humanized your persona, you’ll want to operationalize it in your particular area (online banking, dating, shopping for power tools- whatever area you’re working). The Think-See-Feel-Do checklist is a good way to do this. If you’re not sure about one of these items, go ahead and suppose something and write it down, but be sure to make a clear note that it’s something you want to hit on in your interview guide (we’ll get to interview guides below in the section ‘Talking to Customers’).

THINK

This is your persona’s rational point of view in your area. What you really want to drive to here is the tension between how things are now and how the persona would like them to be. Here are a few example questions you might ask to get at this:
Tell me about how you [do whatever it is your product does]?
Tell me about the last time you [did that]? How did you decide to [do whatever it is]? What was it like?
What are the top 5 hardest things about [doing whatever you do]?
If you could change one thing, what would it be? What about two things?

Here’s an example of from Trent the Technician:

EXCERPT FROM
PERSONA/THINK

Notice the tension about Trent’s interaction with dispatch- that is the result of specific answers the subjects supplied to open-ended question like the ones you see above.

SEE

This is a description of how your persona arrived at the point of view you described in Think. What observations and sources of information are relevant in your area? What or who defines success or good practice? Here are a few example questions you might ask a subject to get at this:
Where do you learn what’s new? What others do?
Who do you think is doing it right?
How did you make your last decision?

Here’s an example from Trent the Technician:

EXCERPT FROM
PERSONA/SEE

FEEL

This is the actual, emotional relevance of the personas thoughts and observations in your area of your interest. This is one takes some practice- talking about emotions between strangers isn’t that normal for most people. Also, using ‘feel’ as a synonym for ‘thinks’ doesn’t count!

I find the best way to get at this is to step the subject through a specific example and then ask them how that (the example) made them feel. Here are a few examples:
Tell me about the last time?
What motivates you? What parts of it are most rewarding? Why?

Here’s an example from Trent the Technician:

EXCERPT FROM
PERSONA/FEEL

DO

This one’s important: you need to get at what they actually do in area and how often/how much/with how much money they engage in the activity question. Remember, useful personas should be ‘real’ and this should represent what they do now, not what you wish they would do.

Questions for Trent might be:
How many jobs did you complete last week?
How many required spare parts? How many parts?
How many trips did you have to make to those customers?

Here’s example Do content from Trent:

EXCERPT FROM
PERSONA/DO

Drafting Discovery Questions

You’ll want an interview guide for when you sit down with subjects. For a template with these items, see Interview Guide (HDD Template).

It’s just a guide- not a questionnaire. You should feel free to skip questions you think aren’t going to move the interview forward and to revise the guide itself as you do your research. You’re not trying to create something statistically significant here.

The Screener

Start with a screener. What simple, factual question can you ask a potential subject to be sure they’re relevant? This is more important than it may seem. We have a natural bias to go with subjects that are convenient & comfortable, which can dramatically limit actionable learning. Don’t blame yourself, but do screen yourself!

For example, let’s say we’re interested in jobs-to-be-done around some aspect of network management, with the idea of possibly building an application for network engineers to manage transport elements like routers and switches. We have a persona(s) for the end user that we want to develop and validate. A good screener would be: ‘How many times last week did you log into a switch or router?’.

The Interview Guide

This section describes the creation of a guide for discovery on both your personas and their jobs-to-be-done. While it’s quite practical to handle both at the same time, for focus and organization, I’ve covered jobs-to-be-done in a related guide: Needing with JTBD.

I’ll point out a few key things in the example below. First, you’ll notice some repetition in the questions- often it works well to ask the same question different ways. Second, the questions become somewhat more specific as you progress through the guide. This is super important. The reason is that this is the best way to avoid leading the subject- by starting general and seeing what they say to those general questions first you minimize the extent to which you’re leading the subject. For example, if you ask ‘Is finding pricing and availability for replacements hard?’ and get a ‘yes’, that has a lot less evidentiary value than if you ask ‘What’s the hardest part of being an HVAC tech?’ and hear something about finding out info. on replacement parts.

The example interview guide below is from ‘HVAC In a Hurry’. HVAC in a Hurry is an enterprise that services heating and air conditioning systems for commercial buildings (HVAC stands for ‘heating, ventilation, and air conditioning). They’re building new tools to make their enterprise function better, with an initial focus on their field technicians.

PERSONA HYPOTHESIS

PROBLEM HYPOTHESIS

You may notice that the two parts of the interview guide overlap. That’s OK- particularly if you observe that you’re getting new and different responses between the different forms of the question. Subjects will remember things they wanted to tell you over the course of the interview and they will never understand all the questions exactly the way you intended (that’s just the limitations of human communication).

Deepening Personas through ‘Day in the Life’

‘Day in the Life’ is a technique for adding depth to personas. The basic idea is to sketch out, well, a day in the life of your persona. If you’re going to use the persona a lot and you feel confident it’s one you want to build out, this may be a good additional investment. If you’re not sure and this is your first go with personas, I would probably defer it. If you really need it, you’ll make time to come back to it.

Here’s a tutorial on how to get started: Personas Day in the Life Tutorial.

Warming Things Up with a Day in the Life Exercise

If you do Day in the Life and your research protocol allows for photos, a great exercise is the Day in the Life exercise. The format is that the moderator shows photos and/or scrapbook elements (emails, texts, Tweets, notes) that showcase a persona over the course of their day. The moderator then asks a series of questions about the persona.

There’s no right answer, but there is a right process and that’s making sure you’ve inferred your answers based on what you saw. The target outcome is that the participants are more comfortable and more fluent with the concept of personas as a way to answer questions and ultimately make decisions.

For more, check out: Workshop: Day in the Life.

Finding Subjects

So far, we’ve talked about how to draft/prototype your personas, and that will help your focus in this next step. Because recruiting and interviewing subjects is expensive, it helps to already know what you want your persona to look like. You’ll be more effective recruiting subjects and interviewing them.

If you’re feeling like your draft is ‘pretty close’, try pushing your reset button. Treat your personas like the hypothesis they will always remain. Be ready to revise. People are complicated, and so the persona is always a major simplification. The question is whether that simplification proves useful for helping you make stuff and sell stuff. If I had to pick one variable to use in predicting the strength/usefulness of a team’s personas, it would be how often they edit them.

How do I find subjects to interview?

The first and most important step is good preparation. I’ve seen lots of energy, time, money, and morale wasted when teams blindly start talking to subjects because they’re told that’s what they should do. The subjects do have your answers, but that’s like saying ‘Go West’. Even if that’s the right direction, if you don’t know where you’re headed, you’ll probably end up as bear food. There are a lot of people you could potentially talk to and a lot of things you could ask them- infinitely more than you have resources for.

The good news is that if you’ve basically followed the tutorial up to this point, you’re in good shape. You’ve brainstormed personas, prioritized them, reality tested them by thinking of real people, done some initial drafting, and created a screener. If you’ve done all that, you’re ready to recruit subjects!

There are a few ways to get subjects. If you’re long on cash, you can get an agency to do it for you. If you’re not, then get creative. If you’re going to make stuff and sell stuff to these people, you should have a good idea of where to find them and how to communicate with them. If you don’t have such an idea, then now is probably a good time to start exploring. What I don’t recommend is getting subjects on CraigsList, etc. Many of those subjects are likely to be ‘pro’s’ or otherwise unlike your target population. Yes, you can screen them to a certain degree with a questionnaire, but that won’t fix the selection bias.

Should you compensate them? Yes, in some fashion. They’re generously giving up their time for your venture. If you’re a startup you probably can’t afford to compensate them at market rates. You should nevertheless present them some token of your appreciation (Starbucks gift card, etc.), acknowledging that it’s just a token and that you’ve appreciated their generosity with their time. Not only is it appropriate and polite, but it will make it much more likely that they help you find other subjects.

When you approach subjects, you don’t need to tell them about what you’re doing, but also don’t be weird or oblique. Instead of telling them about your solution (which they don’t really care about), tell them you’re interested in learning more about the problem area you think is relevant to them (which hopefully they do care about). Framing this in terms of research is accurate and will help put your subjects at ease:

Finally, if you’re planning a design sprint or otherwise want a certain number of subjects by a certain time, plan to approach a lot of potential subjects. The yield from approach to actual interview is usually relatively low.

Let’s suppose you can make contact with 12 people/hour. That’s one every 5 minutes. Let’s say 1/3 of those respond and pass your screener- that’s probably high and will vary a lot with how specific your screener is relative your contact environment.. That’s 4 subjects. Let’s say 50% of those ‘close’ for some kind of session; that’s 2. So about 30 minutes a subject. This will vary a lot with situation but you can tune your funnel as you proceed. It will be slower in the very beginning and you can probably increase your efficiency as you get more comfortable.

Interviewing Subjects

First off, have an interview guide. This will help you budget your time for subjects that are big talkers and work to good answers from subjects that are small talkers. It’s not a questionairre. Feel free to change it as you learn what works and don’t worry about getting structured data you can compare between subjects. For more on creating an interview guide (including a Google Doc’s template), see the personas section of the Customer Discovery Handbook.

Don’t lead the subject. Don’t ask them leading questions, and, in particular, don’t ask the subjects whether or not they want your hypothetical project. They’ll always say ‘yes’ in order to be done with the question and avoid a sales pitch from you.

Move from general questions to more specific ones. If you get a specific answer to a general question, that has much higher evidentiary value than a specific answer to a specific question. Let’s say you’re interviewing an HR manager for an app that helps them better screen candidates for engineering jobs. If you ask ‘Is screening engineering candidates hard?’, he or she will probably just say ‘yes’. However, if you ask ‘What are the top 5 hardest things about your role in recruiting engineers?’ and he or she says ‘Screening the candidates is hard’, that actually tells you the area you’re looking at is on their A-list.

Never, ever, ever, pitch subjects your product, or even advocate a particular point of view. Your job is to learn something from the subject that will allow you to scale an offering to 100 then 1,000, then 10,000, etc. customers. It’s not to sell them something (or worse yet have them tell you what you want to hear).

That said, most subjects will not understand your approach or objective and that will make them uncomfortable. Being forthright with them about what you’re doing is key. Explain to them what you want to learn. That is your objective (not selling). For example, telling an HR manager ‘We’re trying to learn about what’s it’s like for HR managers to recruit technical talent.’ or telling a nurse ‘We’re trying to learn about what it’s like for an oncology nurse to file paperwork.’ is fine and useful.

Recording the session will make them uneasy at first, but most subjects will forget about it in 5 minutes or so. (If you do record them, be sure to abide by applicable laws and regulations.) That said, you’ll likely find you have little time to review these transcripts. Most important is to make notes as you go along and to sit down immediately after the interview and make notes on what you learned, ideas that came to mind.

Avoid interrupting the subject (this will dam up the natural flow of information) but balance that with the time you both have available and the topical coverage you want.

Freely update your interview guide as you learn what’s working. Don’t worry about it making the interviews non-comparable: your goal is not statistical significance. The reason I use a Google Doc for a template is that it eases ad hoc collaboration between team members.

Finally, make sure you evaluate what, if any, paperwork you need. I don’t offer legal advice on this site, but there are some good resources available online.

What do I do with the interviews?

Take great notes and write down your insights right away. The reason why taking great notes is so important is that things you hear from a subject that might seem unimportant to you now might turn out to be very important in 30, 90, 120 days as your point of view evolves.

It’s important to write down your insights because a) you’ll have them b) you’ll think they’re obvious and you’ll totally remember them and then c) you won’t (unless you write them down).

How many subjects is enough? When am I done?

I get this question a lot and while there is an answer, it isn’t exactly in the form of a fixed number of subjects. You’re looking for a convergence of results vs. a fixed sample size. The research you’re doing is qualitative and the variation you’re likely to encounter is probably so layered that your output won’t be subject to the law of large numbers, etc. Have you ever tried the online learning platform Khan Academy? Rather than giving you a quiz with a fixed number of questions, if you get three right in a row, you pass. That’s what you’re looking for with your personas.

What does it really mean to be done? If you reference the process we started with here, the target outcome is that you have a persona or personas that’s able to answer important questions for you. They’re not a fixed form asset like a barrel or a hammer. While they will improve as you exercise them, the real trick is to define the questions you want answered and make sure the personas are doing that for you (see previous section Using Personas for examples of such questions).

Revising & Iterating

At the risk of over communicating this, I’ll just say here that when I see a team that’s using personas effectively, I (so far) have always seen that team doing a lot of iteration and revision. They’re usually managing their personas with Google Docs (or in some cases the MSFT equivalent).

Regarding this step specifically: Make time to sit down and revise your personas right after you finish your interviews- ideally you’re interleaving this activity for maximum focus on the final deliverable.

Personas are the innovators spreadsheet. Everything changes constantly, and the successful innovators uses their personas (and JTBD/jobs-to-be-done, etc.) to keep track.

Editing/Scrubbing per Research Protocol

Make sure you’ve scrubbed out personal/identifying information that’s not part of your research protocol (not consistent with the release you’re using with subjects, etc.).

The Job-to-be-Done (JTBD): A Personas Best Friend

A JTBD is a general statement of something a persona wants to do. The following diagram summarizes this framework:
The purpose of a JTBD s is to discover what really matters to your customer in the terms they use to think about their ‘problem’ (or need, task, job, desire, habit … however they might refer to it) vs. the terms you use to think about your solution. For obvious reasons, looking at things this way is more innovation-friendly.

For the most part, I recommend drafting and researching your jobs-to-be-done in parallel with your personas and you’ll hear them referenced frequently in the material that follows. For purposes of decomposition and just generally not making this piece too long, I’ve moved the more detailed material on JTBD to a related page: Needfinding with JTBD.

How do you use personas to create or improve a product/offering?

Let’s say there are these five fundamental jobs in the business of making stuff (in digital):

Here are a few questions you can expect your personas to help you answer (from the bottom job moving up to the top):

PROPOSITION DESIGN

What jobs (problems, desires, etc.) are at the top of this personas list?

Which of the above has the greatest tension between how things are vs. how the personas would like them to be?

How will we make the customer aware of our new [product, feature]?

How might we test whether they actually care about our proposition (ideally before we go make stuff)?

How often would we expect them to use our new [product, feature]?

What metrics would constitute success?

What will we do if we see that the proposition isn’t resonating with them?

PRODUCT/SYSTEM SUPPORT
How much explanation is required for our user to be successful with our [product, feature]?

How will we guide them to the above? How will we know if it’s working?

How do we instrument the right observations into our support process so we’re making the product easier?

PRODUCT DESIGN
Who is our user?

Based on products they actually use, what interface patterns and comparables would be most relevant to the interface we want to build?

How will they encounter this (product, feature)? How often will they use it? When? Before and after what?

What screeners should we use in finding subjects for usability testing?

SOFTWARE DEVELOPMENT
What happy paths and headline modalities should we prioritize in our test plan (or CI suite)?

I don’t understand this design. How did we learn/decide that’s a good thing for the user? How will we know if it is?

How do you use personas to improve your work on marketing and growth?

For this one, I thought I’d organize the questions you can answer with your personas around the Growth Hacking Canvas– it covers some of the big bases within an integrated marketing program:

Here are a few questions you can expect your personas to help you answer around the job of selling stuff:

PERSONAS & SEGMENTS
Who are our personas? What makes them tick?

What do think think, see, feel, and do in our area of interest? (didn’t have to dig too deep for those!)

VALUE PROPOSITIONS
What jobs (be those problems, desires, habits) are important to our customers?

What alternatives do they have today? What do they like vs. not like about those?

What are we specifically doing that’s better? Why do they prefer our proposition?

BRAND EXPERIENCES
How does the customer (or user) encounter our brand? What are the touch points?

NOTE: I particularly recommend paying attention to touch points outside the ‘happy path’- support, etc.

How are we doing on those? What are they like for the customer?

BRANDING
What do our customers actually think about/associate with our brand?

What do they think about our competitive alternatives?

LEXICON
What words and phrases does our customer actually use to talk about our area?

(Are we using those phrases? Are we ranking for them in Google?)

ORGANIC CHANNELS
Where do our personas go to find information and talk about our topic of interest?

ASSETS, ACTIVITIES, PAID CHANNELS, & PROMO INFRASTRUCTURE
These don’t typically have obvious, direct relationships to personas, so I’ll skip them. (Please comment below if you disagree!)

For more on this, check out: The Growth Hacking Canvas.

How do you use personas to help improve your practice of agile?

Agile describes a set of ideas on how teams can produce better product working together in small batches with inputs that are highly descriptive but not overly prescriptive. The inputs and focal point about what to build are user stories and they have this format:
As a [persona],
I want to [do something]
so that I can [derive a benefit]

You can see where personas slot into those inputs. Like writing anything else, you want to make sure you understand your subject and have some compelling ideas about them. Quality personas are key to providing the kind of smart, discussable, actionable, testable inputs that make agile function well.

This is kind of a subset of #1/making better product, but I wanted to call special attention it since this activity is so ubiquitous. For more on user stories, see: Your Best Agile User Story.

When I see a high-functioning team that’s killing it on innovation with agile, I see an interdisciplinary team. There are a minimum of hand-off’s and maximum of meaningful collaboration. Personas play a central role, anchoring the team’s point of view on what they’re making and how they’re selling it:
A high-functioning team is constantly
a) using personas to create better, more testable ideas and then
b) encapsulating what they learn from testing those ideas back into their personas.

But I didn’t put this section here to sell you on personas. While personas are generally useful, your immediate purposes do matter- there’s no such thing as a single, ‘great’ persona that will automatically work well for everything.

Given this, it is useful to begin with an end in mind when you start drafting your personas, a set of questions you want to be able to answer with your personas. This doesn’t mean the personas won’t be useful for other work- it just means you’ll be best off focusing them on helping you with the job you have now.

How do you use personas to improve your practice of Lean Startup?

In lean, we look at how to avoid waste by focusing on facts and validated learning, creating ‘pull’ for better solutions and processes instead of ‘pushing’ them from the top down. The Lean Startup movement is specifically focused on the need to be highly empirical and work in small batches with explicit success criteria to avoid wasting time & money on something no one wants.

Talk to any practicing scientist about how to achieve a valuable experimental result, and I’d be surprised if they don’t mention starting with a strong hypothesis. Drafting personas and conducting customer discovery interviews help you identify ideas that are validated to matter to customers. This in turns help you start your experiments with stronger hypotheses. That will make your practice of Lean Startup run much better.

For more on Lean Startup, see: Your Lean Startup.

How do you know if a persona is good and useful?

What is a (useful) persona?

The best way to think about a persona is as a kind of approach. I realize you were probably expecting something more prescriptive, but bear with me (or don’t- I mean, it is up to you).

I see teams all the time that trying to create the perfect, shiny persona so they can call it’ done’. There’s an instinct for good workmanship there that’s admirable, but the reality is that the questions you’ll need to answer with personas are constantly evolving and so should your understanding of your personas. I’ll take a Google Doc that the team can edit over a shiny wall poster any day.

A high functioning team or user of a persona will use them constantly and formally as well as informally. For example, let’s say your a product gal (or guy) in a hallway conversation with an account manager. They tell you they were just at a customer site and realized it would be really cool if the customer could just [do some new thing that you don’t entirely understand].  Product gal doesn’t say yes or no, but rather asks for more background about who this persona is and what they’re trying to do, so they can think about both the relevance of this information as well as how they might approach a solution. Bravo product gal (or guy)!

What isn’t a (useful) persona?

In college marketing classes and/or watching 80’s movies (I’ve seen both so I’m a major expert), we learn that the way you describe a market is something like ‘males 25-35 with incomes over $30,000/year’. But who is that guy/gal? How would you figure out what innovative new product or feature he or she might like? The reality is that those profiles aren’t very discussable, actionable or testable. Encouraged in part by the kind of research corporations buy and the way they’re used to purchasing traditional media, they perpetuate useless arguments inside conference rooms and encourage bland products and bland marketing that nobody particularly likes.

In the design world, we make observations about the individual and then look at how we can expand those into creative solutions. Personas are how much of that observation and insight is encapsulated to make it vivid, testable, and durable for work you do weeks, months, or years after you create the persona.

Just to be clear, this doesn’t mean personas are the opposite of data. I teach at UVA Darden and some of this most exciting work we’re doing is on helping students synthesize better insights using both the ‘small data’ of personas and the big data that’s amenable to machine intelligence. As any practicing scientist will tell you, the best way to get a useful experimental result is to go in with a strong hypothesis. Personas are a way of developing better hypotheses.

Final note: If you’re a fan of Clayton Christiansen’s work on jobs-to-be-done, you may remember that in some of his talks (in particular with the the milkshake example) he talks about how personas make a mess of marketing. I would say that’s more applicable to this bland/generic take on personas. The methods you’ll learn about here and in the piece on Jobs-to-be-Done, which are are consistent with design thinking and this more observational approach to understanding the customer.

Testing Your Personas

First and foremost, it’s great to have a near term task in mind to test and apply your personas- see how they help, see how they’re relevant. They won’t be perfect, but more so than anything else this will help you focus future work on the personas.

Generally speaking, you’re never ‘done’, but the following are good preliminary indicators that for any given project it’s time to move on to the next step.

Checklist: Persona Hypothesis

Checklist: Problem Hypothesis

Your Persona as Hypothesis

You may have heard of ‘lean’, possibly through the popularity of the Lean Startup movement. The basic idea is to avoid waste and learn from direct observation, be that with customers or internal users. Lean pairs well with design thinking and the use of personas as a way to organize and focus your learning, and as a safeguard against design practices becoming arbitrary (yes, it happens).

Pairing personas with lean means organizing your major ideas into testable formulations, figuring out efficient ways to test them, testing, and then executing your next steps based your results: was your idea a) validated b) invalidated or c) the experiment was inconclusive.

In the first case you have confidence to act on the idea and scale it; with a ‘b’ or ‘c’ result it’s time to reformulate and retest. When I work with teams, we ultimately organize the output of our personas and work around design thinking into these 4 key hypothesis areas:

The sections that follow ideas on how you might apply personas in four key areas of customer discovery.

For a deeper dive on this, including templates for customer discovery, please see: The Customer Discovery Handbook.

	Persona Hypothesis	Do you know who the customer (or user) really is? What makes them tick? We’ve kind of been there done that on this one!
	JTBD Hypothesis	Have you identified specific jobs, needs the persona actually has? Are those important? What alternatives are they using now? Same here!
	Value Hypothesis	For your key jobs-to-be-done, is your value proposition better enough than the alternatives?  This is where it gets kind of interesting: having strong personas and jobs-to-be-done is pretty important to focusing and getting actionable results from your Lean Startup type experiments.
	Usability Hypothesis	Is the product easy to use? Are users using it in the way you intended? What does that mean? Obviously, before you build product you hopefully have strong personas and JTBD. Additionally, when testing usability and deciding on UI paradigms, it’s useful to have a user in mind.
	Growth Hypothesis	Do you have a profitable recipe to acquire and retain customers? How can you make that even better? Scale it? Personas are a great way to blend and amplify interdisciplinary work across product and promotion.

For tutorials and templates on doing usability testing, please see: The Customer Discovery Handbook.

What other practices make personas work better?

Storyboarding

Storyboarding is a great way to test and operationalize your understanding of a persona or personas.

My favorite framework for thinking about the customer lifecycle is “AIDA” (attention, interest, desire, action). I also like to add an “OR” (onboarding, retention) since these are so important to many of the products I deal with today.

Fun fact: this framework is ancient by the standards of today’s business press- it was introduced by marketers in the 19th century (yes, the 1800’s). AIDA(OR) is one of my favorite storyboarding topics simply because lots of product teams I meet with haven’t thought through the whole acquisition process in vivid, actionable, testable terms. Here’s a simple 6-panel storyboard where we hypothesize about Helen the HR Manager’s customer journey. Here it is with a little more detail:

NOTES	BOARD
ATTENTION: Helen the HR Manager sees a post from her friend (former co-worker) on LinkedIn that she likes something called ‘Enable Quiz’ for screening engineering candidates.
INTEREST: That problem’s on her mind and it catches her notice. The site’s splash page clearly explains what it’s about: effectively, automatically screening technical talent. No assembly required.
DESIRE: Helen’s tired of not being able to improve their success rate on hires and having to clean up the emotional, financial, and logistical mess when a hire doesn’t work out. It’s never going to be 100% but it should be better than it is. Also, Helen has her annual review in three months and she’d love to add ‘implemented new screening system for engineering candidates’ to her list of accomplishments for the year.
ACTION: She checks in with Frank since he has to buy in and give her inputs to tune the quizzes for their positions. Conveniently, the Enable Quiz site has a page for hiring managers that she forwards to him. But he doesn’t read it, she catches him in the hallway, and he says fine, especially if they can try it first and it’s only $2/candidate.
ONBOARDING: She puts in a credit card and they’re rolling with a free trial for 10 candidates. The site’s built-in wizard helps Helen draft quiz content for their open positions and submit it to Frank for review/update. She ends up dragging Frank into her office to finish up but overall the process is pretty painless. They try it out with their first candidate the next day and the results are good.
RETENTION: Screening candidates using Enable Quiz becomes a habit and they’re using on average 20-40 quizzes/month. Helen has herself posted about it on LinkedIn after becoming a fan. They’re thinking about implementing skills audit for their existing staff.

For more on storyboarding (including templates and online tools you can use to get started), please see: Storyboarding Tutorial.

Example A: Personas & Jobs-to-be-Done from Enable Quiz (Startup)

Helen the HR Manager

Helen’s been on the job in HR for 10+ years. She knows the routine but she’s never gotten particularly comfortable with the technical topics her managers cover. She’d like to know more, but a lot of her day is taken up with fairly standard issues like benefits management, vetting employee situations, and setting up infrastructure for new hires. She feels a little stuck in the admin area- facilities, accounting, etc. She’s like to engage more in the other functional areas of the business. Helen’s job in terms of hiring is to help the functional manager write the job description, identify channels for recruitment, and perform initial candidate screening.

She doesn’t have deep knowledge about software development, so she’s getting the functional manager to give them the detail they need on job descriptions to screen for specific qualifications. That helps but it’s kind of arbitrary. The system for getting the list is unstructured and highly imperfect. From her point of view, a more systematic ready-to-go system for screening candidates and passing validated screening information to the functional manager would be great. Bad hires are Helen’s least favorite part of the job- it’s a really unfortunate thing for the hire as well as the company. Unfortunately, she has little visibility into whether a hire will work out.

She does the screening and passes the recruit for the functional managers for further screening. Having a more systematic view of why hires don’t work would be highly desirable but she hasn’t gotten a lot of traction with the functional managers on doing those post-mortems. The HR department may or may not be involved in ongoing skills management for existing employees. However, it will almost always be involved in employee assessment for anything financial, such as raises or bonuses. If the functional managers use a quiz to determine a raise or bonus (particularly if the HR manager initially created the quiz as an objective criteria), Helen’s likely to be involved in the administration and/or review of the results. Helen likely pays the bills for Enable Quiz, especially in a larger company.

Frank the Functional Manager

Frank’s been a technical manager for the last 8 years. He started out as an individual contributor in development, then running a technical operations group and after that a product development team. He’s got the team down to a predictable rhythm but he still spends most of his time interfacing with other departments that need things from his group. He’s learned that recruiting is one of his most important success factors, but still spends far less time on it than he’d like. chronically under invest their time in recruiting.

In terms of hiring, his job is to write up a job description for HR, coaching them on how to screen candidates. Screening candidates, even just the resumes, takes up a lot of his time and it often ends up meaning that he delays interviewing candidates for a week or two longer than he’d like. Something that would give him a structured, comparable criteria for looking at new hires would be helpful. Bad hires happen. Some are surprises, some just don’t fit in with the team. Frank admits the surprises shouldn’t happen- he and his team should have the ability to screen new hires to make sure they have the right skill sets. Anything that could prevent that would be of interest to Frank. Frank would like to get a more systematic view of where his team is at on key skill sets.

He has a general sense but he has too many people to know where everyone is on everything. Plus, there are new technologies out there where Frank isn’t that well up to speed. There may be some hidden gems and opportunities out there. Anything that would help Frank get a sense of where everyone is would be welcome.

Chris the Candidate

Chris has been on the workforce for seven years in a variety of roles. He wants to be challenged and work with smart people. He gets the basic idea on the key topics but, hey, we all fudge a little, don’t we? As an engineer, most jobs come relatively easy given the shortage of supply. Paradoxically, the harder he has to work to land a position, the better he regards the company and the position he’s won.

Since the interview candidate is sort of an involuntary one-time user, detailed JTBD aren’t really a clean fit. Nevertheless, we took a shot to see how it would look.

Steve the Staff Member

Steve’s been on the job as a consulting engineer for two years. Most of the time he’s head down working on customer deliverables. He’s been doing a solid job but is curious about what it would take to broaden his horizons some. He also doesn’t see anything wrong with a little friendly competition- it keeps the job more interesting. He came to the company through a technical recruiter and she has been in touch about other opportunities. Steve likes what he’s doing and his team, but he does need to feel like he’s growing to stick around.

Notes Interview Guides

The two sections that follow describe the interview guides for the HR manager and the functional managers they collaborate with when making a new hire. The functional manager is the person who will manage the new hire and created the job description for the team member they need. The HR manager collaborates with them by sourcing candidates, doing initial screening, and helping with the final decision.

Interview guides are not the same thing as questionnaires. The goal here isn’t to create statistically valid or even specifically comparable data. The idea is to get at what’s truly important to the subject, why, and how they actually behave. As an interviewer, you have to apply judgement toward getting the right information from your subject and managing the time and energy both you and the subject have available. Sometimes this means asking the same basic question a few different ways over the course of the interview, and sometimes it means skipping whole sections of your interview guide in order to focus on a thread of conversation that particularly useful.

HR Manager- Interview Guide

SCREENING QUESTION
How many open positions have you filled in the last three months? [Should be >1 if extenuating circumstances but probably >5]

PERSONA HYPOTHESIS

PROBLEM HYPOTHESIS

Functional Manager- Interview Guide

SCREENING QUESTION
As a manager, how many new hires have you made in the last six months? [Should be >1]

PERSONA HYPOTHESIS

PROBLEM HYPOTHESIS

Example B: Personas & Jobs-to-be-Done from HVAC in a Hurry (IT Project)

Trent the Technician

Screening Question: How many HVAC repairs did you complete last week? [threshold: >3]

Trent’s been an HVAC technician for 7 years; 4 years of that at HinH. After a couple of years off, Trent enrolled in a 2 year program on the advice of a close friend who was doing the same. Getting his first job wasn’t as easy as everyone said- and the money was terrible. But now he’s a senior technician at HinH and the money’s pretty good.

He’s always had a knack for fixing things, probably owing to his concentration, curiosity, and tenacity. He’s never been much for debating or arguing. He likes figuring things out and even more than that he loves coming through for people. More than his billings on a job, that’s what really makes it or breaks it for him- whether the customer is happy and better off or whether they’re confused and frustrated.

His day starts as late as it can- he prefers to sleep in but usually has to get to the office early. He prepares for his jobs and then hits the road as quickly as he can to avoid traffic. If he’s lucky, he has the parts he needs for the job and doesn’t have to deal with the logistics of getting them. If he’s not, there’s a lot of time on the phone and sometimes back and forth, and not all of it is billable.

He knows dispatch does the best they can, but sometimes he feels like he’s zig-zagging all over town and spending most of his time in traffic, which doesn’t pay- as a senior technician he’s mainly paid on his billable hours. Sometimes that gets pretty frustrating.

He tends to use his own mobile phone at work for email, text, and looking for documents online. The company provides a tablet-based device, but it’s kind of hard to use and he just refers to it for dispatch and a few other things.

JTBD for Trent: