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).
Tom Grant says in his post:
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.
Chris Cummings says in his blog post:
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.
Furthermore, I believe working on personas leads to a false sense of customer insight. I like this quote from Jason Fried, founder of 37signals:
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.