All projects: Gel, Jobs, Gootodo, Games, Uncle Mark, Goovite, Blog, Bit Literacy
Tips on product management and research
Aug 24, 2007
Three years ago I wrote You DO Talk to Customers, Don't You?, in which I stated what I thought was the obvious: customer experience work requires working with customers. But this idea is still not practiced widely enough.
A friend sent me this roundup of a recent entrepreneur conference at Stanford, where PayPal founder Max Levchin offered some tips:
Product management, he says, is 85% user interface and 15% channeling the user.
For user interface, Levchin told the audience to measure how their visitors interact with the sites. Slide.com tracks mouse clicks, mouse overs, abandonment rates, the funnel, and more. Levchin and his team mine the data for intelligence that helps guide future iterations of the site.
For channeling the user, Levchin says founders must step inside the minds of their target customers. In Levchin’s case, he says he must imagine himself as a 15-year-old girl with attention deficit disorder who’s looking for digital bling to dress up her MySpace or Zanga web page, while at the same time she’s chewing gum, talking on the phone, instant messaging with five friends, listening to music, and twirling her fingers through her hair.
Levchin cautioned his techie audience to keep their customers in mind and not go overboard with technology for technology’s sake. He pointed to the early social networking site, Friendster, which lost critical momentum when it ran into scaling problems because of a “cool” feature that calculated friend trees, and caused page load times of up to a minute. MySpace.com, by contrast, was successful because it cared less about technology and more about the user experience.
Levchin is right to tell people to study both data and users. However, in terms of "channeling the user," while he's on the right track, he's still missing the key step - and a LOT of developers miss this step.
Rather than "channel" the user, i.e. think of what these theoretical people might theoretically want, it's better to actually sit with actual people to see what they actually want. Of course it takes more time and energy to do that, so lots of developers (and even UX practitioners) prefer instead to invent "personas" of theoretical people, and then make strategic decisions based on what those theoretical people might want.
Yes, personas are helpful for some uses. But the primary way of understanding a customer's experience with a site, tool, or business must be with an actual customer, not an imaginary figment.
See also: You DO Talk to Customers, Don't You? (September 22, 2004)
Superb comments, as usual. I do have one small quibble, though. Personas, when done correctly, are actually helpful summaries of all the research you've done with actual customers (contextually in their homes even). In other words, if you're finding yourself talking about "invented personas," then you're not really in the persona world, where every detail about the persona is grounded in researched information. Chances are if you're talking about invented personas, you're moving from marketing profiles to imagined users, and, as you say, that's not quite there -- almost, but not quite! And, to add on to what you're saying, you're also nicely making the case for continual usability testing during the development (functional through coding) cycle of what you're working on, continually making sure you're real-world folks are still matching the personas you've created to organize your work. (Personas of course are only one outcome of analyzing the data your real-world-user contacts provides. The designer's expertise, the project's scope, and the rest of the data analysis all play a part, too. But nothing should be done without meeting your real users. I wholeheartedly agree!)
I have two additonal thoughts. First is that listening to customers should be baked into the process of innovation. Second, listening to customers not only takes energy and time, it also costs money. Firms must take the time to quantify the value of listening to customers to insure adequate investment is made in listening to customers.
While I find talking to consumers invaluable, I still think that a well-shaped persona (based on that research) is critical in terms of knowing who you're talking to. As a writer by training, I know it's much more effective to visualize a single person that you're writing to than to focus on, as a whole, the 12 individual consumers you sat down with previously.
I agree with your take on personas. I am working on project after project where "personas" are created based on assumptions, market research and 3rd party research but no primary research. Not to mention project after project with no usability testing. Apparently there isn't enough time or money. It seems a lot of folks talk about user-centered design but very few actually do it.
I've worked with companies that have spent buckets of money for consulting firms to develop these "personas." As a marketing professional I find them useless and as a person I find them insulting. People are far too complex to fit into neat little categories. Instead, why not focus on universal needs and how your product can meet those needs? And yes, use those buckets of money to talk to your customers first-hand to find out how you can make things better.
Mythical people spend mythical money.
Of course, the answer is "It depends."
First, it's important to distinguish between personas done right and personas done wrong. If a company is creating personas instead of talking to customers, then IMO they aren't really creating personas. There is no reasonable definition of "persona" that does not include the need to base a persona on gobs of quality customer interaction. In other words, a good persona is not a substitute for customer interaction, it's one of the outputs of customer interaction.
Even when done right, personas can still be a poor ROI. The key, I believe, is where your product fits on the 80/20 rule. Some products try to please the 80% at the expense of the 20%, basically by trying to maximize market share by pleasing the customers that are the most similar. Personas are great in that situation. Other products try to please the 20% by focusing on what makes them different, basically by trying to maximize profit by delivering something the "good enough" products can't. For these products, personas are of dubious value because it is the differences between the customers that are interesting, not the similarities.
Here's the full text of a post from the blog of Craig Newmark from craiglist.
"Like I tell people everyday, I do serious customer service at craigslist, everyday, and by "everyday" I mean every day.
My exit strategy for customer service is death; that is, I'm only be doing customer service as long as I live. After that, probably over.
I keep saying this repeatedly, not sure how the rumor started otherwise."
Says it all, doesn't it?
http://www.cnewmark.com/2007/08/im-not-going-an.html
Hrmn, personas - well....
While I agree that ficticious persons may be a good vessel for summarizing something you found out through careful research, I have a certain dislike for personas for a reason I may be alone with:
- in my opinion, personas are inexplicably used to disguise the fact that you're actually using your creative imagination.
It seems like it's OK to imagine what might be important on any project, as long as you claim it's a "persona", rather than you, actually doing some kind of (hopefully) intelligent thinking on the subject matter at hand...
Now, I believe in creative courage - which means that you do your homework, be it talking to customers (which is indeed important), or observing real-life users without their knowledge (such as people-watching, f.ex.), basically gathering intel in whatever way you can, and THEN.... you make your own (hopefully) intelligent, creative decisions based on all of this intel and more, your own experience, increment tests, etc.
It's a risky business, I know, because everyone can be wrong, even creative professionals - but it's a cop-out to try and deflect the blame to ficticious users, isn't it?
I also think it's important to know if we're talking about user experience or customer experience - but perhaps that's another discussion...
I think that the debate over whether you use data or not is missing the point (and I know for sure that I'm going to get blasted for this...but I still stand by it based on pretty extensive experience.) Why do I say this? Because sure, you should use data to create personas. And of course they don't replace real interactions with real people. But that's not the point. The point is that personas are about getting focus internally more than they are about anything else. Shared focus begets great products that make sense end to end. Without shared focus, I don't care which tools you use--the product won't be as good as it could be. And if this shared focus is on actual customer goals, you're golden. This is why personas created by agencies don't work--it's the process that creates shared focus, NOT the documents.
The best way to explain is my version of the 80/20 rule. I think there is a major 80/20 rule when it comes to creating personas, which is very helpful when it comes to the 'cost' of doing personas. And that is that 80% of the benefit of personas comes from collaboratively creating them using the internal assumptions or embedded knowledge of a team. Assumptions that you can't see can and will hurt your project. The far-and-away-most-helpful-and- practical value of personas, in my experience, is in bringing agreement and focus (and keeping them) in a team. So even if I work with a client to create ad-hoc personas in a couple of hours-- personas based on goals, not demographics or psychographics or whatever--then I do it, and it always helps. I talk more about this in my 'cow analogy' posting on my blog, if you are interested.
As summed up by other contributors, the value of personas has been lost in that it is no longer recognised - if indeed it ever was - that they must be based on data collected from real users in a given domain, and not dreamt up in conference rooms, which is all too often the case.
I'm a UX researcher and I dislike personas more than just about any other UX "method" because they are abused in this manner. Persona research should be primary research, if done at all, and it should be appreciated that understanding the users in a domain may take a very long time, and more time than most projects allow. I shudder when someone suggests I create personas for a project, because it will mean that I will be distracted from the design issues that will continue while I am off trying to find any data on which to build the personas, when other methods would be much more beneficial to the design questions.
I also think persona creation is more often than not "busy work" in which touchy-feely "researchers" who don't like data have a chance to get creative, get out the coloured pencils and invent fictitious characters with occupations, pets, favourite celebrities, locations, and hobbies and interests that have absolutely *nothing* to do with the domain itself. They are doing a great selling job with those polished-looking characters, but if there's no data behind them, forget it.
I've seen bad and good examples of personas. In the best cases, the personas are specific, based on actual discussions with users, and plentiful enough to account for a variety of user types. They are not a substitute for user research; they are user research, and they act as an organic way for us to 'have the user in the room' when we're writing and designing. I've found personas particularly helpful when you are designing for a variety of different user types; they help you find common and disparate threads among these users.
Ultimately, you have to go back and test your work. If the personas were good, you should face less revisions than if they were poor.
Personas are one tool among many; anyone who relies on them exclusively does so unwisely. Finally, they are not right for every project.
As with most things, all Personas are not created equal. There are 4 classes of Personas, and your beef is mainly with Class 4, which I understand. But each class can be used for a different reason, and we can't throw the baby out with the bathwater...
Class 1: Segmentation Personas. These are personas whose data start with a market segmentation, ideally one that identifies the most lucrative target market. Most marketing segmentation schemes are derived from qualitative (focus group) and quantitative (survey) data, but to be useful for personas, they usually require a bit of follow-up research that focuses on behavior and in-context product use (e.g. Ethnographic research). These are the most resource-intensive ways of creating personas, but they are much more reliable.
Class 2: New Research Personas. Here, you don’t have a segmentation model to go on, and even if you have existing research, it is clear you need to do some follow-up research to really understand your audience in order to create the personas. You can do this new research qualitatively, though it is good to have quantitative research (surveys and data mining) to help you size certain attributes you will highlight in the personas. You might draw on existing research, if it is appropriate.
Class 3: Existing Research Personas. Here, the personas are based on existing research that is relevant and appropriate for the target audience. You don’t do any further research to create the personas, though the danger here is using data from a study that had a different sampling profile.
Class 4: Assumption Personas. In this case, the team has decided to lay all their assumptions on the table regarding who the target audience is, which may be informed by research they have consumed at some point, but which was not aimed at this meeting this business objective. The benefit here is that everyone gets on the same page (as with all classes), but the danger is that you may not really have real truth behind the personas. That said, Assumption Personas are still surprisingly effective at getting teams to work well together.