Persona Non Grata

OK, contrary to popular theory, the Cranky Product Manager is not dead.  She blames her lack of blog posts on the holiday madness, especially her miserable attempt to play Santa for her infant. And then, just as the holidays wrapped up and the last thank you note was written, the Cranky Product Manager was held against her will in a smoke-filled hotel for a entire week, forced to give product training to a bunch of hungover sales droids. And then attend their booze-drenched, endless awards ceremony.

Anyway, back to blogular business. 

These days, seems like most in the product management blogouniverse think user personas are the shizz, the best thing going since the invention of the triple shot grande skim latte.

Never able to resist development fads, everyone at DysfunctoSoft is getting on this persona bandwagon.  Example:

VINEETA
Vineeta is 33 years old and an entry-level IT manager at a mid-sized insurance company located on the Philadelphia Main Line. She manages a claims payment application for the auto insurance division. The application was developed before she was born. After a messy breakup with her fiancee one year ago, Vineeta moved back in with her parents. Her bedroom is now the same one she grew up in, and there's still a poster of Green Day on the wall.  Vineeta is an Aries and enjoys long romantic walks on the beach. She has a 7-year old cat named Whiskers, whom the ex-fiancee detested.

Well, gee. How nice.  What a nice, although potentially fragile, person that Vineeta seems to be. The Cranky PM sure hopes that DysfunctoSoft builds her some nice software.....

hmm.  yep.

OK, the Cranky Product Manager HAS to say it.  SO WHAT?  WHO FREAKIN' CARES about Vineeta's hobbies or pets or love life? Seriously, what do these colorful details have to do with how Vineeta uses DysfunctoCrank 7.5?   

Why are all the personas the Cranky PM sees littered with this type of crap detail instead of the facts that REALLY matter? Such as: How much time does Vineeta spend working with the application? What level of technical expertise does she have? What types of tasks does she usually do in the app?  What circumstances would make her depart from the usual routine, etc...?

ARGH.  Cranky Alert! Cranky Alert!  Shelter in place, please!

Comments

[P. Alves]

THANK YOU for that!
I'm a product manager/business analyst and always have found it very weird to have consultants come with profiles including the type of car the person drives, the number of children they had... I always wondered if I was missing something.

"Why are all the personas the Cranky PM sees littered with this type of crap detail instead of the facts that REALLY matter? Such as: How much time does Vineeta spend working with the application? (...) "

EXACTLY! I don't care if the person is distracted by her 17 cats or her only child - just let me know that she has short attention span, if that impacts our interaction model ;-).

[Steve Portigal]

http://www.portigal.com/blog/ask-for-our-latest-article-persona-non-grata/

I just published a column (with the same name, btw) about personas in the most recent issue of ACM Interactions.

[nope]

My experience sharing "user personas" with the design and development teams is that I find myself arguing about the persona instead of looking at the requirements. And I'm arguing with long-haired, bare-footed trolls who haven't left their cubicles to sniff a rose in possibly years. They have no idea what a persona is because that would imply an understanding of "personality", which they don't have. My philosophy: keep it simple. Tell the trolls what to build and end the meeting.

[Gopal Shenoy]

I understand with the folks here that use cases are much more useful for developers in figuring out how to solve the customer's problem. Things such as how often they use the product (infrequently or all day long) is important when it comes to designing the usability of the product. I have never used personas in my career, but I have been involved in design of very successful products by being in constant touch with customers and trying to immerse in the business life of the customer. I have attended training on persons through Pragmatic and Cooper, but have not found it to be as effective as talking to real people about what they are trying to accomplish with your product.

I have always believed personas come into play when positioning the product or developing marketing communications. Someone mentioned that this is useful for sales, have you ever met a sales guy who only sells to the target market - sales will try to sell anything to anyone who has money !!

[Gopal Shenoy]

I understand with the folks here that use cases are much more useful for developers in figuring out how to solve the customer's problem. Things such as how often they use the product (infrequently or all day long) is important when it comes to designing the usability of the product. I have never used personas in my career, but I have been involved in design of very successful products by being in constant touch with customers and trying to immerse in the business life of the customer. I have attended training on persons through Pragmatic and Cooper, but have not found it to be as effective as talking to real people about what they are trying to accomplish with your product.

I have always believed personas come into play when positioning the product or developing marketing communications. Someone mentioned that this is useful for sales, have you ever met a sales guy who only sells to the target market - sales will try to sell anything to anyone who has money !!

[bob corrigan]

I agree, we're not far from agreeing, and the important distinction is something you mention - the use case - which is derived from and in some cases animated by the persona.

From a developers perspective, for whom an objective description of needs is of primary importance, the use case is key. For the marketer, for whom a subjective assessment of current emotional/intellectual states is of primary (or at least major importance), the persona is key.

My take-away from this (very enlightening) exchange is that both the persona and the use case are important, albeit to different people, and that I feel strongly that they should align. I'm also going to test whether or not developers enjoy reading the personal just so long as they have the use case to go along with it.

Thanks!

[Ron Kaplan]

Bob,

We are not far from agreeing. What is not logical is the leap of faith that some make about personas and "knowing" the customer. I question the efficacy of persona as a means to producing technical requirements. One can develop the best products in the world without personas. Personas are incongruent to their definition if one concentrates on problem solving. Once you start talking about the "real" issues, the personas fade away and now you have use-cases. If you are working with use-cases and produce technical requirements, you are no longer working with personas.

I agree that personas are best when left in the professional hands of product marketers and sales folks. They truly benefit.

Thank you.

[bob corrigan]

Ron, you made an important statement when you said "personas don't get you any closer to solving the problems customer need solved in detail."

They do, by making everyone involved in the creation of that solution intimately and consistently aware of who they are creating for.

The best developers I've ever met are keenly interested in knowing more about who they are writing their code for. Whether they get this knowledge through persona descriptions or face-to-face meetings with current and potential customers doesn't matter, as long as they have it. Both accomplish the same goal.

In the end, we all want to feel like we're creating products that make a difference - not just throwing another packet of complied code off the end of the assembly line.

There's a reason that the marketing and sales people want to know more about their buyer - it helps them sell. They are more successful when they get to sell products that were written with the same buyer in mind. Isn't that axiomatic?

[Ron Kaplan]

I'm with CPM. This persona thing is highly overblown. It is interesting for product marketing people, but as for the technical requirements, it gets very fuzzy for me. I attempted to make the persona "leap" on more than one occasion. Unfortunately or fortunately, it was not worth the effort. Lots of busy work with little attention paid to problem solving for the customer.

We just need to define the customer, solve problems worth solving and listen to all stakeholders. I over simply? Maybe, but personas don't get you any closer to solving the problems customer need solved in detail.

If I were managing the promotion of my product/service (advertisements and such) or Sales, then personas would be very helpful, but to say that personas help developers? This is a highly dubious claim.

[bob corrigan]

The reason it is important to write personas that are more. . . shall we say. . . personal, is that programmers need to be reminded of who they are writing their software for: real people. Yes, the persona above gets a little fanciful, but if you leave personal information out of a persona, you're losing the opportunity to put a strong human face on what would otherwise be a dry list of "needs".

I'll also posit that the degree to which you need to get personal with your persona descriptions depends to a great extent on who will be using your product. Consumer-centric software needs more. Command-line driven server software needs less.

You are, of course, also writing use cases to go along with your personas.

[Don MacLennan]

Agreed, absolutely. Personas are invaluable when they focus on what matters: the buying and usage criteria that determine customer success. Is there room for "personal" information in a business user persona? Hell, yes. I sure want to know how an employee is measured (read: gets bonuses) by her boss and how my offering could postively affect that.