What’s the deal with Personas?

The CrankyPM recently posted a good little rant on personas. It’s drawn some interesting comments from both sides of the persona camp (PCamp? 🙂 ). BTW, I’m totally jealous as she snagged a great title — Persona non grata — for her post.

I’ve been incubating the following persona related post for a while, and thought now a good time as ever to finish and post it.

There’s been a fair bit of writing related to personas as a tool for better understanding users and their requirements. Adele Revella has The Buyer Persona blog, and Bonnie Rind has her Product Personas blog. And of course, the accredited father of the persona concept for product design is Alan Cooper. Cooper’s firm has a number of persona related articles on their site. Perfecting your Personas by Kim Goodwin provides a good overview for those who are interested in understanding the basics.

She starts:

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype.

This makes complete sense and whether one is explicitly familiar with personas or not, it’s what most Product Managers tend to do, some better than others.

Later Kim writes:

There is seldom a one-to-one correlation between personas and job descriptions. In some cases there will be multiple personas with the same job description; in others, a single persona can represent people with a wide range of jobs.

Thus for a single job — say an administrator — there could be personas representing new administrators who need lots of prompting, and experienced administrators who prefer command lines and know exactly what they need to do. Again, not much to debate here.

Later on Kim writes:

You can also add life to the persona by using environmental details to reinforce important characteristics. For example, if someone tends to be incredibly busy at work, don’t just say he’s incredibly busy; instead, say there’s a sandwich on his desk that he’s been trying to find time to eat for three hours.

Now this is where things get interesting, and this is the issue that Cranky fixates on in her post. And to be honest, it’s really hard to disagree with Cranky. Imagine the look on a bunch of developers faces as you start laying out the persona, describe their environment, their goals, their workflow, and the fact that a sandwich has been sitting on their desk for 3 hours.

Might as well stamp the words — Marketing dweeb — across your forehead and then tell them you’re going to get a soy latte at the brasserie. First of all, I’ve yet to meet a development team that cares about these kinds of details. They don’t want to know that Albert, the community college grad who provides DB2 database administration support likes to watch Ren and Stimpy videos while he waits for nightly database backups to run.

They also don’t want to know that Sachiko, the business analyst, has an MBA from a second-tier Midwestern university, is planning the details of her upcoming marriage, and thus doesn’t have time to conduct proper and formal analyses for the new CRM system that is needed.

These are all completely unnecessary details in the B2B context. For consumer software or products, these details may be very important.

A while back, I worked on a new Administration Console for an enterprise middleware product. The product itself was in widespread use, but there was a real push to make it “enterprise ready”, which meant that things like security and role based permissions were important.

The developers spoke about the target user — “the administrator” — in very vague terms. There was also confusion around the fact that some users of the product could act as both administrators and operators depending on the circumstances.

We needed clarity on this and a way to distinguish who did what, when and why with the product, and who the target would be for the new Administration Console. So, we decided to talk to customers to get some raw data. After a number of customer visits and calls, we determined the following:

  • There were four major “administrator” roles within our customer base
    • Network Administrators
    • Infrastructure Administrators
    • Application Administrators
    • Operations Administrator
  • These four roles were generally consistent across customers, though responsibilities crossed over between roles in different customers
  • Administration teams were structured very differently across organizations
    • Some customers had administration teams with global responsibilities
    • Others had teams with specific geographic focus (e.g. Americas, APAC, EMEA)
    • Others had teams responsible for specific applications

From these and other findings, we came up with specific definitions of the roles. Here’s the definition of the Infrastructure Administrator which we decided was the target user for our Administration Console.

An infrastructure administrator is concerned with a specific set of hardware and software running on that hardware. This set of hardware/software is usually domain specific. I.e. it is associated with a particular enterprise application, such as Siebel, PeopleSoft, an external web application or some other system.
The infrastructure administrator’s job is to ensure that the particular hardware and services, particularly the services, they are responsible for are operating efficiently and that any general maintenance, such as application data backups, server shutdowns etc. are managed in an efficient way.
In the context of our product, an infrastructure administrator is responsible for starting/stopping repositories, configuring servers, performing repository backups etc. In most cases, but particularly with small to medium installations, the infrastructure administrator also handles inter-repository migration of metadata. i.e. they do the deployment from development to test, and test to production.The infrastructure administrator is the primary user of the Administration Console, though from our discussions it is clear that they do not need to use it everyday.

The developers really understood this description. We had similar ones for the other three types of administrators, and throughout the development of the Administration Console, we regularly referred to these roles, their descriptions and other findings from our research when questions arose as to what should or shouldn’t be part of the console. Notice there is no mention of personalities, habits, level of disorganization on someone’s desk or anything that detracts from the role and it’s focus.

So, what’s deal with Personas? Technically nothing, unless you insist on using them with engineers or other people who just couldn’t give a damn about all that extraneous “marketing fluff”. A big part of Product Management is communication, and speaking in the language of others. If engineers don’t “grok” personas, don’t force them down their throats.



16 responses to “What’s the deal with Personas?

  1. I think that a lot depends on what you want to do with the personas. Marketing and PM may require a more rounded view of the target user whilst developers need a more focused view.

    Personas are important in that they let us understand the limits and constraints our users operate in. For example, I have one PM who has a fully set up Firefox extended browser who has no problem in remembering passwords via an addin and so on. Yet other users forget passwords and this will change their behavior when faced with different functionality.

    PM needs to ensure that the functionality will work for the target user group/personas with their whole operating environment, sandwich breaks and all. IT on the other hand is more interested in focused technical issues once the overall design and usecases have been defined.

    Of course, one has to be careful to not go too far when defining personas – I don’t care about a user’s wedding plans either.

  2. Richard,

    Thanks and while I agree that it depends on what you want to do with them, in my experience in primarily B2B software, the primary consumer of the persona is development and the extraneous details are just irrelevant. There is nothing wrong with the general concept of the persona though so don’t get me wrong, but it’s essentially the value of the back story and environmental details (like the sandwich on the desk) that’s debatable. And IMHO, those are the things that distinguish personae from standard role and responsibility definitions.

    As an aside, I once worked for a voice-applications company. i.e. sophisticated applications accessed through the telephone. The VUI (voice user interface) was of course critical for the success of the applications. The voice team created a number of personae with associated vocal recordings to help illustrate them. While “Mary” was the default voice in the applications, and provided a very clear, friendly yet authoritative voice for the applications, we also had “Zak” who was young, friendly but a bit “irreverent”. There were other personas as well with different profiles, each with a back story to “bring them to life”.

    In the end, no one, except the voice team and some people in marketing really cared. While these personae had a different function than the ones that Cooper espouses, it was another example of the lack of criticality of personae in application design.

  3. I fear that many marketers think that creating personas is a creative writing exercise rather than a market data-based profile. It’s not about what kind of car they drive or if they’re planning a wedding. Instead a persona gives contextual information for development and marketing guidance such as computing skills, experience, and work environment.

    Thanks for an insightful post.

  4. I think you might be a tad hard on people who include “fluff.” Product managers are like comedians or musicians: you have to go with what works with your audience. Some development organizations want just the most immediately relevant facts. Others respond better when the persona seems a bit more human, or when the extra details say something about the subculture in which a target user lives.

    PMs might look as though they’re blowing smoke through some orifice when the persona is complete fiction. Better to pick a real person as a starting point than some Joe Schmoe invented from the ground up.

  5. Steve

    Thanks the response. Most of what Kim Goodwin says in her article makes sense, but the part about the extra details — indicating that an uneaten sandwich is on the desk, vs. stating how busy the person is (btw, who’s not busy these days?), — is the heart of the issue.

    Who benefits from that? Virtually every developer I’ve met finds those types Yes, one can get over creative and that is a no-no. It comes down to a cultural issue really. Some company cultures may find that information useful. Personally, I’ve yet to work in a company that does.


  6. Tom,

    Thanks for the comment and for reading the blog.

    You may be right…that I’m being a bit hard on people who include those extra details. But don’t misinterpret what I wrote. I intentionally put quotes are “marketing fluff” because, from the perspective of engineers, that’s how those extra details are typically received.

    I did focus my response on B2B software. Consumer software will likely be very different. For example, I can certainly see how personal details etc. would be very useful for products like Quicken.

    And agreed, personas (or whatever one wants to call them) must be based on first hand research and observation of real people. It can’t be just made up based on assumptions and conjecture.

    As I mentioned in my response to Steve, the issue is not the concept of the persona itself, but what extra details are actually relevant and useful for the task at hand.


  7. Would it be a good idea to run new features past all of the personas to see how it affects them?

    The Admin Console was very useful for Developers as well as Administrators. For a few things we were even able to get some technical business types to use it.


  8. Kevin,

    Given that the personas are user archetypes, it wouldn’t be possible to run the new features past them. In fact, the reality is that the requirements are drawn by understanding the needs of the the key users. One can certainly validate the findings and derive requirements with some actual customers and then certainly after the designs are complete, things like beta programs etc. are certainly valuable.

    The reality is that in most development cycles, there are only a few opportunities to get customer/external input, and feed that info back into the development cycle.

  9. Hi Saeed:
    I also want to make a distinction between “user” persona development — a practice which captures the essence of targeted users of the product — and “buyer” personas, where the intention is to understand each of the people who influences the buying decision. People who build personas need to remember the goal — to capture the information I acquired about the needs and priorities of a target audience (users or buyers), and then deliver that information to another audience (developers or marketers). When persona developers deliver buyer information to developers, they miss the point and invalidate what could be a really useful tool. Developers want data, sales and marketing people want stories. First rule of communication — think about your audience, please! (which brings me full circle back to personas — have you seen a developer persona)

  10. Hi Saeed,
    I can see that developers and engineers will find it easier to get behind your role definitions compared to personas. They are functional specs. As long as the developers create a system that can provide the functions then it’s ‘job done’.

    I understand what you’re saying about personas. But I think your role definitions allow developers to think in exactly the kind of way that created a need for personas.

    Perhaps there is a fine line between humanising a user archetype and creating a ‘cardboard customer’ that just turns people off.

  11. Hi Saeed,

    Thanks for addressing an interesting persona issue. Persona descriptions are important but they are not the central purpose of persona work. Personas are just the starting point for the truly important heavy lifting that goals, buying scenarios, user scenarios, and use cases provide. When a client asks us something like, “Why do I have to learn about these fake people?” we explain that the personas, as translators of customer research, are the jumping off place for scenarios (and then we might glide more quickly through those persona introduction slides). Personas provide context. How much time and to what depth you focus on that context depends on who the audience is and what your purpose is.

    As Adele Revella and others have pointed out, personas must fit the culture. Even though our business at Goal Centric is to create buyer personas, I’ll be the first to say that personas aren’t everything. A persona is a tool that must serve its users. So, for B2C marketers, include research-based details about the car the buyer persona drives. For B2B developers, emphasize the user persona’s role, tasks, and goals. Then, move your audience on to “the meat” of your persona research and analysis: the scenarios, which should provide that audience with insights and opportunities for marketing, product, and buying process innovations that will please your real customers.

    Having said that, there is value in making your personas memorable or distinguishable from each other with some level of personal detail. And there can be value in introducing the same personas to different audiences within your organization so that executives, marketing, sales, and product people all know they are talking about the same customers, even if developers are focused on what “Jeff” needs to do after hitting Submit, and executives want to know how many times this year “Jeff” is likely to buy the product (“Jeff” would be a consumer who both buys and uses the product). The value of personas is that they can be flexible for each audience and they can hold and communicate researched, relevant, focused information for each audience to keep all departments working in concert. (See Goal Centric’s work on Persona Ecosystems, which address multiple role personas and multiple audiences within a B2B context.)


  12. Angela,

    Thanks for the comment. I agree, personas must fit the company culture. The point I was making was related to the personal details that seem to be so prevalent in the personas I’ve seen. I’ve yet to work in a company that sees those as really useful. I’m not saying they are not, but that I’ve not found people receptive to them.

    I’ve left a comment on Adele’s blog post that referenced this article.


    Here’s a snippet of what I wrote about working with a couple of people from Cooper.

    They had a wall board with pictures of the individual personae (Charles the CEO, Lucy the Business Analyst etc.) along with their descriptions and back stories.

    Many engineers found this whole exercise quite irrelevant. I found a lot of the research very useful, but the outputs too distracting to communicate what needed to be said.

    You mention using persona to communicate across teams. That can be handy but I have to say a couple of things.

    1. I’ve never met a software executive that got down to that level of detail on users, buyers etc.

    2. There needs to be a real cultural buy in across all those teams to invest the time to support the research and then convey it across the company. It may be the right thing to do, but it rarely happens given different goals, alignment, cultures and objectives of those teams.


  13. Pingback: Happy (belated) birthday to us! « On Product Management

  14. Pingback: Product Management » Blog Archive » Personas generate some controversy

  15. Pingback: The User Is Always Right: Making Personas Work For Your Site | Product Management Meets Pop Culture

  16. Pingback: The Problem With Personas | Product Management Meets Pop Culture