And those are still best served by someone who focuses on analyzing those attributes instead of dumping them into a spreadsheet with equal weighting and consideration.

If agile teams or SaaS mindsets call this product analysis, business analysis, or whatever the term du jour may be for the role, that person is still practicing best practices of a product manager.

What I am finding is that the bigger, more apparent difference is in regards to outbound marketing approach, sales support, campaigns, etc. as opposed to R&D and engineering-facing activities.

@Arty (#2)
If you are, as you said, “not in a position to profile real people” - my question is this: How can you build “personas”? I’m afraid you’ll fall into the trap of spending a lot of time on fictional stuff.

@Bob (#4)
Interesting thoughts. If I read correctly, it seems to me that you’re recommending fiction - embellished by some real examples of customers. If so, IMHO that approach has far more negatives than positives - and I’ll consider it “waste”. But if you’ve found them effective and efficient, then that’s great - I respect that.

@Mike (#8)
For multiple types of users, I’d use the “Actor” concept I described towards the end of the post.

It’s up to the Product Manager to pull this information together. Far too often I’ve seen products built, not necessarily for the wrong persona but that have missed some key aspect of the persona - such as computer skill level. Personas are meant to capture these details so that when the user uses your product they are productive with it and don’t waste time struggling with the product that is meant to be used by a person who knows everything about computers… now that’s a real waste for your customer!

Last point I want to make is that, as many in the comments have stated, personas consist of factual information gathered through conversations with customers. You have to get out and interview them and ask the tough questions … including age, it might affect how the UI gets built. My experience is that once you have interviewed 4 customers you begin to see patterns emerge, continue your interviews to validate and refine these emerging patterns.

What I find a real waste … the time and effort wasted thinking of items not relevant to your product.

Further, vs. using the title of a business customer, it’s helpful to use personas to separate out who is and is *not* a customer. “Not every e.g. software engineer will want this product, we are selling this product to all the people like Joe, not the ones like Rick.”

I just saved about 5 minutes by not having to not re-explain which persona was which and why my product is valuable to certain people. If every time I mention a persona I save 5 minutes and I spent an hour creating it, it only takes 12 mentions for me to make up for lost time. Plus if I give the persona their own web page linked to the requirements doc, it’s really easy for people to look up the target customer profile and not have to come to me asking about the customer.

Some aspects of the persona aren’t at all relevant to developers — like how this type of persona looks for a solution like ours. But marketing really needs this information to avoid wasteful “checklist marketing”) that the buyer finds useless.

Similarly, development needs a lot of details about how this type of user will interact with the product, and marketing couldn’t care less about this information.

So its very useful to develop “user personas” that communicate only what developers need, and “buyer personas” to reflect the information that marketing needs.

This, along with all of the other comments about basing personas on real customer interactions, result in personas that are incredibly useful.