- Forrester Councils
- Councils Overview
- log in
Posted by Tom Grant on October 5, 2009
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:
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.]
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »
Contributed by Mike Gualtieri on Sat, 05/19/2012 - 09:44