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.

Saeed