Personas are Great – For Wasting Time!

I’ve been meaning to write this post for a while. Recently, I saw a couple of blog posts on this topic (here and here) from bloggers I respect a lot. This spurred me to finally get around to writing this post.

This post is about using “personas” as a part of software requirements process. It’s not about marketing, sales or other activities.

At most companies, personnel with the job title of “product managers” or “business analysts” write Requirements Documents. These documents are then used by engineering teams to build and test the software.

There’s a school of thought that says that Personas are a very useful concept as a part of gathering and documenting requirements.

Having been a part of a few teams that tried to use personas in their requirements process – I consider personas mostly a waste of time. Here’s why…

What is “Waste”?

Since I had the temerity (!) to just call working on personas a wasteful activity, let me define “waste” first. Borrowing from the “Lean Production” philosophy popularized by Toyota – I define “waste” as anything that does not add value to the customer (as perceived by the customer).

Okay then, who is the “customer” in the context of this topic? At most companies, the primary “customers” for Requirements Documents are engineering teams. The secondary “customers” are end users and internal stakeholders (such as executives).

Why is Working on “Personas” Wasteful?

Personas are FICTION.

This leads people to make like they’re J. K. Rowling and spend a ton of time writing meaningless fluff – usually 1-2 pages for each “Persona” – complete with a fake name, gender, location, life/work history, and other gobbledygook. Even fake photos. Including pets. No, I’m not kidding!

Furthermore, I’ve seen teams get into endless arguments abount trivial details of personas (like the car they drive, or their photo).

You might not like the conceit of writing a fictional profile, but that’s just a question of style.

Well, I agree with the first part of Tom’s sentence. Most engineering teams I’ve worked with don’t like the “conceit of” reading fiction in requirements documents – documents that guide how they spend the bulk of their valuable time. However, I gotta respectfully disagree with the second part of the sentence – it’s not just a question of style, Personas are always FICTION.

If you’re working with people who have been “duped” by personas in the past, you’re going to have a hard time convincing them of their utility.

Excellent point. Most engineering teams I’ve worked with scoff at the idea of reading fictional profiles, and do not find them valuable. So do other stakeholders – one startup CEO told our PM team “I want to read about real customers, not about fictional non-sense”.

If the “customers” of our requirements documents don’t find “Personas” useful – why should we spend our own valuable time working on them? If customers don’t see value in it, it’s WASTE, as defined above.

I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist. And I definitely don’t think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three).

So Personas are a Waste of Time, Now What?

If personas are a waste of time, what should we do instead?

Use real customers (names, titles, companies) in your requirements documents. Your credibility will go through the roof – in the eyes of your engineering team & executives.

When some level of abstraction is beneficial – just use the “Actor” concept (defined in any good book on use cases such as this one). It is a single-phrase, factual description – such as “HR Manager” or “Employee”. Whereas “Personas” are 1-2 page fictional gobbledygook.

To summarize – if you want to waste time, want your engineers to crack jokes behind your back (since you believe in fictional people ), and your execs to question your productivity – go ahead and waste time working on personas. If you believe in being efficient and only working on activities that add value – just say no to personas.

I'm your author, Michael Shrivathsan, an expert in product management with successful experience at several innovative companies in Silicon Valley, USA over the past two decades. I'm also a USPTO patent recipient. For my day job, I'm the VP of Product Management at Accompa, we make the popular requirements management software used by Product Management, Business Analysis, and related teams.

Topics

Search

Legal Disclaimers

1) Nothing in this blog shall be construed as legal, accounting or other professional advice. In fact, the authors are quite UNprofessional. We're not responsible for bad things that happen if you're dumb enough to follow anything this blog says.
2) Do not read this blog while jumping out of an airplane at 20,000 ft without a parachute. If you do, you will very likely die. We're not responsible for that.
3) Do not read this blog one sentence per day during your lunch break, while eating a quadruple bypass burger. If you do - by the time you finish this blog, you will be a total fatty and may even die. Again, we're not responsible for it.
4) In summary - we're not responsible for anything. We're Americans, baby!