Personas of interest

Christopher Cummings brings up an always-interesting topic: why people don't use personas as much, or as well, as they might. While persona certainly has a specific meaning in Agile, the same kind of deliverable—a profile of an archetypal user or stakeholder—exists in marketing and sales, too. It may go by different names, and people may develop and use these personas with more or less rigor.

Cummings cites three main pitfalls with personas:

  • Dealing with objections about their usefulness. This seems to be the easiest object to handle. Even if someone doesn't officially build personas, they still develop a mental sketch of the average user. You might not like the conceit of writing a fictional profile, but that's just a question of style.
  • Picking the wrong personas. People can get a bit sloppy about which persona they choose for a particular user story, use case, or requirements doc. For example, reporting features in a CRM system are really for sales managers more than account managers or telesales representatives, so choose wisely when you prioritize and design those reports.
  • Dressing a feature in a persona costume. Naturally, product people like to talk about products, so it's hard for them to stay in persona-mode for too long. Unfortunately, the

The other pitfall I raise may be just an amplification of the "wrong persona" problem, but it's an important one:  When do you stop identifying ever finer distinctions  within roles?

For example, is the role developer enough, or should you make a distinction between development manager and engineer who's an individual contributor? Or should you go further, and define some very senior individual contributor role, such as architect, that's different from the rank-and-file developer?

It's a tough question to answer, since it depends  both on the role and the question you're posing. I've been surprised, for example, to see how different enterprise architects and application developers can be, when citing the sources of information they use to answer technology purchase and adoption questions. Therefore, from a marketing perspective, you need two different strategies to reach these different roles. (A quick, obvious example: Application developers really don't like calls from salespeople.)

In other contexts, these distinctions might lack a real difference. Would you design an IDE differently for rank-and-file developers versus enterprise architects? There might be some differences, particularly when it came to project management details. (Developers might be interested strictly in items related to their own to-do lists, while architects might want a broader view of the project.) However, the degree to which you tailor the product to fit these roles might be far smaller than the amount of custom-tailored marketing you need to do.

Which leads to another potential risk, duplication of effort in persona development. Just because a product manager didn't find justification for major differences in product design doesn't mean that the research into these roles is useless for product marketers. If I were a product marketer and someone were to tell me, "We didn't find any reason to change the product, but here's a lot of information about application developers and enterprise architects that might be useful to you," I'd be glad for the help. Not only would my colleague have saved me a lot of basic research work, but I might spot some marketing-related details in the information already provided.

Persona development requires a lot of patience to tease out the relevant details. However, the work is definitely worthwhile, since it can prevent a lot of costly mistakes. And really, there's no alternative, other than extremely unproductive arguments between people who have not spent time researching John Q. User, which one of them has the better understanding of this archetype.

[Cross-posted at The Heretech.]