Personas are Great - For Wasting Time!
By Michael Shrivathsan on Oct 15, 2009 in Product Management, Requirements Management Basics, User Experience
I’ve been meaning to write this post for a while. Recently, I saw a couple of blog posts on this topic (here and here) from bloggers I respect a lot. This spurred me to finally get around to writing this post.
This post is about using “personas” as a part of software requirements process. It’s not about marketing, sales or other activities.
At most companies, personnel with the job title of “product managers” or “business analysts” write Requirements Documents. These documents are then used by engineering teams to build and test the software.
There’s a school of thought that says that Personas are a very useful concept as a part of gathering and documenting requirements.
Having been a part of a few teams that tried to use personas in their requirements process - I consider personas mostly a waste of time. Here’s why…
What is “Waste”?
Since I had the temerity (!) to just call working on personas a wasteful activity, let me define “waste” first. Borrowing from the “Lean Production” philosophy popularized by Toyota - I define “waste” as anything that does not add value to the customer (as perceived by the customer).
Okay then, who is the “customer” in the context of this topic? At most companies, the primary “customers” for Requirements Documents are engineering teams. The secondary “customers” are end users and internal stakeholders (such as executives).
Why is Working on “Personas” Wasteful?
Personas are FICTION.
This leads people to make like they’re J. K. Rowling and spend a ton of time writing meaningless fluff - usually 1-2 pages for each “Persona” - complete with a fake name, gender, location, life/work history, and other gobbledygook. Even fake photos. Including pets. No, I’m not kidding! 
Furthermore, I’ve seen teams get into endless arguments abount trivial details of personas (like the car they drive, or their photo).
Tom Grant says in his post:
You might not like the conceit of writing a fictional profile, but that’s just a question of style.
Well, I agree with the first part of Tom’s sentence. Most engineering teams I’ve worked with don’t like the “conceit of” reading fiction in requirements documents - documents that guide how they spend the bulk of their valuable time. However, I gotta respectfully disagree with the second part of the sentence - it’s not just a question of style, Personas are always FICTION.
Chris Cummings says in his blog post:
If you’re working with people who have been “duped” by personas in the past, you’re going to have a hard time convincing them of their utility.
Excellent point. Most engineering teams I’ve worked with scoff at the idea of reading fictional profiles, and do not find them valuable. So do other stakeholders - one startup CEO told our PM team “I want to read about real customers, not about fictional non-sense”.
If the “customers” of our requirements documents don’t find “Personas” useful - why should we spend our own valuable time working on them? If customers don’t see value in it, it’s WASTE, as defined above.
Furthermore, I believe working on personas leads to a false sense of customer insight. I like this quote from Jason Fried, founder of 37signals:
I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist. And I definitely don’t think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three).
So Personas are a Waste of Time, Now What?
If personas are a waste of time, what should we do instead?
- Use real customers (names, titles, companies) in your requirements documents. Your credibility will go through the roof - in the eyes of your engineering team & executives.
- When some level of abstraction is beneficial - just use the “Actor” concept (defined in any good book on use cases such as this one). It is a single-phrase, factual description - such as “HR Manager” or “Employee”. Whereas “Personas” are 1-2 page fictional gobbledygook.
To summarize - if you want to waste time, want your engineers to crack jokes behind your back (since you believe in fictional people 
), and your execs to question your productivity - go ahead and waste time working on personas. If you believe in being efficient and only working on actiivities that add value - just say no to personas.
What do you think - am I muy loco for being so anti-persona? Let me know your thoughts - click here to post your comment…
1. Len | Oct 15, 2009 | Reply
Sound like you argue with the techniques that you have seen used, not the personae themselves. I find personae to be very valuable, but I don’t create them like you describe. Rather than creating fictions, I build them as a biography of an actual customer that I know fairly well. In that sense, I think that we agree. I do fill in some fictional details where it might be awkward to ask a customer directly (age is a good example) and I stay away from trivia (i.e., pets). I will use a photo of the customer if I have one, and I don’t go beyond a page. I will also emphasize characteristics of the customer that are both relevant to the product and common with other customers–in that sense it is not a pure customer profile. I guess that I feel that I am doing what you suggest, but it is just the name that we disagree on.
2. ArtyFish | Oct 15, 2009 | Reply
Interesting post which makes a lot of sense when creating technical requirements.
For clarity, and as I am currently considering offering to create personas for an MRD, do you consider a “non-fluffy” set of buyer and user personas a waste of time in that context? If so, given that I am not in a position to profile “real” people, what do you suggest as an alternative?
3. Steve Johnson | Oct 15, 2009 | Reply
Real buyers and users may be preferable to personas but may not be 100% representative. Personas give us an ideal buyer and user. While I do advocate the use of personas, I also agree with you completely about the personal gobbledygook that I often find there. Who cares if she’s planning for her wedding or repaying student loans? Personas are a stand-in for the ideal buyer and user. Provide necessary context and stop. You’re right: it’s not a creative writing exercise but an exercise in communication.
And you’re also right: personas must be grounded in the market. They cannot replace personal experience with real people.
4. Bob Corrigan | Oct 15, 2009 | Reply
You’re looking at the problem in both a wrong and right way.
Wrong in that there is value in the “uber-persona” document, and right in that it is not entirely useful. Let Me Explain.
It is valuable for the product manager who has never written a persona document before. Going overboard and describing their preferred thread-count for sheets, favorite make-out tune and most annoying allergy is an exercise designed to force a product manager to think about the buyer in an intimate way and document it.
Once you’ve “oriented” the product manager to be buyer-focused, it’s less useful to treat the persona design process as you’ve described. Knowing who you are building for - and being able to communicate that to the people who do the building - is always an essential part of the craft. The goal is to do it effectively, whatever that happens to be.
Unfortunately, I also disagree with your “use real customers” statement. One of the great dangers of product manager is to build products for a market of “one” - the vocal buyer or thought-leader can influence a development process to go in the direction that is most useful to them, but not you.
So here is my recommendation:
1. Put every PM through an exercise of developing a detailed persona document, and make them test it on a real person or two or ten. It is a useful training exercise to help focus the PM on “building products for real people”.
2. When describing personas, follow the “who, where, problem/goal, need” format. Describing people in terms of the challenges they face and outcomes they wish to achieve is very credible, and combines the best of persona definition with problem description.
3. When communicating with developers and marketers about personas, remember to bring data about how many of these people there are out there - what % of your users are persona x - and garnish these discussions with examples of real customers. “Orville at MegaCorp is an example of the designer persona, and here is how his particular problem compares to the design”.
Enjoy,
bob
5. ArtyFish | Oct 15, 2009 | Reply
Bob,
Great insight, thanks!
-T
6. Ken Allred | Oct 15, 2009 | Reply
I recently went through the exercise of creating Buyer Personas, which are also User Personas for our organization. We have three primary buyers for our products.
I did it for a couple of reasons:
1. In my conversations with our sales team it was obvious that there were things they didn’t understand about our buyers and users.
2. In my conversations with our development team, I would get questions like “You’re sure this feature is going to be valuable to our customers?”
I had never done them before, and when I did research on them I came to some of the same conclusions that Michael does in his post (great post, btw). If I had included the Gobbledygook he describes in our personas I would have lost a lot of credibility with my teams.
The way I built our personas was to start from scratch, eliminate all my assumptions about our buyers and users and the problems we solve for them and start talking to customers and non-customers.
I didn’t even attempt to build the personas until I had talked to at least 10 customers and 10 non-customers for each persona.
I can tell you that these have become incredible tools for us in ways that I didn’t expect.
My advice based on my experience–do them! But don’t build a persona until you’ve talked to real-world buyers and users and follow Michael’s direction and don’t waste time on gobbledygook!
-Ken
7. Jennifer D. | Oct 15, 2009 | Reply
I agree and disagree with many points in this post, as the others before me appear to do as well.
Good personas do exists, and do add value. Personas are not and should not be an exercise in creative writing. Personas are not and should not be based on fictional people.
Good personas are based on a compilation of market feedback. You should not be “making” the information up. It’s about gaining enough understandinf of your market needs and thehn finding a way to communicate these needs, and the market problems, in a way that is useful. While I have found that including an image is helpful, to make the compilation of facts gathered more “real and personal,” if your development teams will snicker at this - don’t.
What matters is the content, based on real facts and data of real people in your market who you are trying to help solve real problems. Anything else is fictional and a “waste.’ But done right, the communication vehical of personas can add much value to teams that do not interact with the market and do not understand what the “real” problems are that exist.
The alternative? Development teams snicker behind your back, build the next great bread slicer and then wonder why you never told them that the market was interested in a bread toaster. They didn’t understand. Personas put all teams on one page in their understanding and direction.
8. Mike Boudreaux | Oct 15, 2009 | Reply
It seems like you’re taking an extreme case of misguided use and generalizing that all use of personas is a waste of time. I agree with much of what you wrote in the context in which you wrote it, but it does not apply to the user personas that I’ve worked with.
In my experience, user personas are most useful for usability designers. If your designers aren’t keyed into the concept of user personas, then you might be wasting your time as a product manager. Like you say, they won’t understand why you’re talking about fictional characters, and they aren’t likely to take the personas seriously as part of the design process. This might be where PM leadership skills have some value, if you really think that they’re needed. If you don’t see the value and neither do your designers or developers then I agree it is a complete waste of time.
However, if you don’t use personas then how do you refer to the user of your products? Do you just call them “the user?” If so, what if there are many different types of users? How do you differentiate so that you meet their needs? If you’re only targeting your product for use by a single type of user then this is great. If you’re targeting your product for many different types of users in different scenarios then you run the risk of your product being difficult for all users.
I’ve found user personas very helpful to explain to developers that “this feature is to help User X do Y” when I’m explaining the objective for a project. Having a one-page description of User X’s tasks and responsibilities can help to understand how this need fits into their typical activities. It can also provide some insight into the skill set of the typical user. I wouldn’t typically include user personas in market requirements though. If you’re doing this, then you’re likely starting to design the product yourself.
9. Stewart Rogers | Oct 15, 2009 | Reply
I have to comment too. Everyone else seems to have covered the main points.
Product managers who don’t understand and document their personas will ultimately fail.
As someone who has used a product built for the wrong persona and someone who has gone back and forth endlessly with QA trying to get them to test for the right persona, I believe in the value of personas.
I certainly sounds like you have had some bad experiences with personas. Although it seems it may have been caused by the fact that it was rooted in a creative exercise without any evidence. Is it any wonder Engineering was mocking? Ken’s advice is spot-on… “I didn’t even attempt to build the personas until I had talked to at least 10 customers and 10 non-customers for each persona.” You can’t build software to all 20 users, but you can identify common traits in their work scenarios and problems and build solutions that meet their needs.
The creative aspect comes into play by trying to make them feel real, but as Jennifer said “good personas are based on a compilation of market feedback.” and they should represent a typical buyer and/or user. As a side tip, building to job titles (i.e. HR Manager) is a recipe for disaster.
I must admit, although I appreciate your opinion here, you are very much in the minority here. I have spoken to thousands of product managers and they all seem to understand the value of personas.
My advice, try not to let previous bad experiences discourage and use the feedback to write better, more valuable personas. There is no questioning they bring focus and insight to the process.
10. ArtyFish | Oct 15, 2009 | Reply
Mike,
You say “I wouldn’t typically include user personas in market requirements though.”
Forgive my niaivety, but where do they belong? Presumably not in the Functional Spec?
-T
11. Peter | Oct 15, 2009 | Reply
It “can” work and be valuable. If you come up with a list of personas just to have a list, you might as well recycle the paper it was printed on. I remember in a past life, a company I worked with had 5 personas which fit on a single piece of paper. They didn’t need the paper because everyone (and I mean everyone) had them memorized. In planning meetings people would ask “what would Linda think, how would Linda use this”, eventually I figured out that Linda was their 1st persona and, their worst customer:) Throw away the binder and pickup the phone to call some customers, you’ll have personas before you know it!
12. Adele Revella | Oct 15, 2009 | Reply
Lots of great comments already posted here. Let me just add one additional point that relates to your definition of “waste”. Many people fail to create useful personas because they build a single persona document and then hope that document will be useful to the entire company — development, sales and marketing.
Some aspects of the persona aren’t at all relevant to developers — like how this type of persona looks for a solution like ours. But marketing really needs this information to avoid wasteful “checklist marketing”) that the buyer finds useless.
Similarly, development needs a lot of details about how this type of user will interact with the product, and marketing couldn’t care less about this information.
So its very useful to develop “user personas” that communicate only what developers need, and “buyer personas” to reflect the information that marketing needs.
This, along with all of the other comments about basing personas on real customer interactions, result in personas that are incredibly useful.
13. Marc J. Miller | Oct 15, 2009 | Reply
When I write personas I usually get comments that it’s helpful. Finally they get an idea of who the customer is, and who the engineers are building for. I’ve saved tons of time by being able to then reference those personas in meetings.
Further, vs. using the title of a business customer, it’s helpful to use personas to separate out who is and is *not* a customer. “Not every e.g. software engineer will want this product, we are selling this product to all the people like Joe, not the ones like Rick.”
I just saved about 5 minutes by not having to not re-explain which persona was which and why my product is valuable to certain people. If every time I mention a persona I save 5 minutes and I spent an hour creating it, it only takes 12 mentions for me to make up for lost time. Plus if I give the persona their own web page linked to the requirements doc, it’s really easy for people to look up the target customer profile and not have to come to me asking about the customer.
14. Peter Hanschke | Oct 17, 2009 | Reply
Lot’s of really good points made here. Having used personas for the past 15 years or so, I believe in them. I’ve never created a persona that has a picture in it or the dog’s name or anything that is not germane to the product I was working on. In other words I only articulated the information that helped our teams understand who we are building for. Let’s face it, if the product you build is for developers then they are potential users; if your product is not for developers, then none of your developers have a clue who they are building for.
It’s up to the Product Manager to pull this information together. Far too often I’ve seen products built, not necessarily for the wrong persona but that have missed some key aspect of the persona - such as computer skill level. Personas are meant to capture these details so that when the user uses your product they are productive with it and don’t waste time struggling with the product that is meant to be used by a person who knows everything about computers… now that’s a real waste for your customer!
Last point I want to make is that, as many in the comments have stated, personas consist of factual information gathered through conversations with customers. You have to get out and interview them and ask the tough questions … including age, it might affect how the UI gets built. My experience is that once you have interviewed 4 customers you begin to see patterns emerge, continue your interviews to validate and refine these emerging patterns.
What I find a real waste … the time and effort wasted thinking of items not relevant to your product.
15. Michael Shrivathsan | Oct 19, 2009 | Reply
@Len (#1)
You’re correct, it sounds like it’s just the name we disagree on. But to me, the word “personas” usually has a certain meaning and is unfortunately associated with the negatives I’ve outlined.
@Arty (#2)
If you are, as you said, “not in a position to profile real people” - my question is this: How can you build “personas”? I’m afraid you’ll fall into the trap of spending a lot of time on fictional stuff.
@Bob (#4)
Interesting thoughts. If I read correctly, it seems to me that you’re recommending fiction - embellished by some real examples of customers. If so, IMHO that approach has far more negatives than positives - and I’ll consider it “waste”. But if you’ve found them effective and efficient, then that’s great - I respect that.
@Mike (#8)
For multiple types of users, I’d use the “Actor” concept I described towards the end of the post.