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.

http://www.buyerpersona.com/2008/03/personas-genera.html#comment-107073756

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.

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.)

Angela

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.

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.