What Would Karl Do? Or How to Get Real Value From Personas (Part 1)

Understanding Personas as a key tool for aligning teams and driving customer and market focussed initiatives.

So, I’m going to wade into a bit of a minefield with this (and the next) post, but hopefully, by the end, we’ll have diffused the mines and cleared a safe path forward.

People either love, hate or don’t understand personas. I think the latter two are somewhat related. I want to try and clarify personas for readers and show how they can be of real value to you, your products, your company and your customers themselves.

And please don’t forget the feedback link at the bottom. Would love to hear your thoughts on the article.

What Problems Need To Be Solved?

Before talking about personas, let’s look at the problem(s) that exist that need some tools and concepts to address.

Companies, particularly in the B2B technology space, build, market and sell complex applications for a wide variety of tasks, processes and users. The challenge they face is understanding and staying aligned on who their customers, buyers and users are though that process.

i.e. How well do you understand who you’re building for (users and buyers), who you’re marketing to (prospects, buyers, influencers) and who you’re selling to (buyers, decision makers, influencers)?

And how aligned are internal teams on their mental models of these different groups? i.e. when each team thinks about the “buyer”, do they all have a common context so their actions and decisions are aligned?

In many companies, this is not the case, and the result of this misalignment is unnecessary friction, additional expense and lost opportunity.

As a starting point, let’s look at the term “user”. What exactly is a “user”?

The term “user” is a lazy term for any/all people who use a product (or service). Does the term “user” mean anything exactly or help anyone understand who they are? This is a disservice to the people who will actually use and benefit from the product.

The word “user” should be banned from product vocabularies as it adds no value to discourse and is easily replaced by more specific and useful terms.

For example, an HR application would need to provide functionality that addresses the needs of several different types of “users”:

  • Individual Contributor (Employee)
  • Managers
  • Executives
  • HR Managers
  • HR Executives
  • HR Application Administrators

and possibly others.

There is no generic “user” here. Each of these groups will view the HR application differently, needing different capabilities at different times. e.g. all employees need to book holiday time, but only some need to manage performance reviews, and still fewer need to do organizational planning.

Additionally, all individual contributors are not alike, all executives are not alike, and all companies are not alike. And thus, even within user types, there may be variations and differing needs based on role, employee location, company size, company location etc.

And for the people on the product team building this HR application (or marketing or sales team etc.) there may be different understandings of what these roles are, what they do, what needs they have, what priorities they have, who outcomes they want etc.

So how can these teams get a common, clear and accurate understanding of what each group (or subgroup) of users expects and needs, and over the course of the development, marketing and sales process maintain common context in our discussions and decisions?

When one member of the team talks about the “HR Manager”, does the rest of the team have the same mental model of that HR Manger?

Additionally, how accurate is that mental model? If the entire team has an inaccurate or vague understanding, what benefit is that?

And yes, ongoing learning, validation and feedback with real people (“users”) is critical, and there is no substitute for that; but every decision, interaction and choice made cannot wait for that kind of feedback. Teams need to start and be able to move forward together, with a clear understanding of who they are building for or marketing/selling to.

And thus, the concept of personas comes into play.

What is a Persona?

A Persona is an aggregated and curated description (an archetype) of people who perform a role or job in a company or organization. E.g. an analyst, administrator, human resources manager etc. Personas provide the team with that needed common mental model of who they are focusing their efforts on.

  • A persona helps personify the role and the important characteristics of that role to the members of the team. The persona creates a realistic and rich picture of people in that role.
  • A persona enables teams to empathize with the actual people in the roles described by the persona. Empathy is a critical part of product design, marketing and sales.
  • A persona should be focused on people who have similar responsibilities, challenges and goals (a segment) that align with the kinds of people you (or your company) are interested in understanding better and targeting via design, product, marketing, sales etc.
  • A persona enables a common understanding of that role so that product (or other) teams can work in alignment and with clarity about who their target user, buyer, influencer or person of interest is.
  • A persona is based on research with actual people in those roles. It is fact based, not conjecture or hypothesis based.
  • A persona provides as much information as needed in the forms that are needed so all team members can internalize the role and describe and use it appropriately when needed.
  • A persona helps team members answer questions and make decisions that arise about the role in the course of product development (or other tasks) without having to always go back and directly ask people in those roles.

In short, a Persona should help the team answer questions like:

What would [the persona] do [in this situation]?

Or

How would [the persona] answer [this question]?

Or

Why would [the persona] need [to do this]?

What isn’t a Persona?

To get over any misconceptions of personas, the following is a list of what a persona is not. I’ve run across these (and other) misconceptions in my work over the years.

  1. A persona is NOT an average person or a specific person in that role. It is a detailed archetype representing the specific type of person that you are interested in..
  2. A persona is NOT a description of EVERYONE in that role. A single persona cannot describe multiple people in the role from those who are new to those who are very experienced etc.
  3. A persona is NOT a set of characteristics and attributes or bullet points about a role.
  4. A persona is NOT defined by a generic or standard template that can be used for any role
  5. A persona is NOT a static definition. It should be updated periodically to reflect new information and insights and to further enrich the understanding of that role for the team.

I’ll deal with a couple of these later in the document, but it’s important to emphasize that a persona is an archetype — a typical example of a certain person (in this context) — and not an average, specific or generic description. The persona must have specificity that helps “make it real” to those consuming it.

Also, once defined, a persona doesn’t remain static. It can (and should) change as you learn more about the role/people, as the role/people change or as the needs of the people who are using personas change.

Why Do People Dislike Personas?

There are many reasons why people don’t value or even like personas. They may not understand them or have had a prior bad experience with them.

This article, Why Personas Fail, does a great job at summarizing the most common issues people have with Personas. The main reasons outlined in the article are:

  • People don’t know what personas are or why they’re useful
  • No buy-in from leadership
  • Personas were created, but not used
  • Personas were created in a silo and imposed on people

I’ll add one more:

  • Personas were not designed to address the needs to the team using them

Let’s look at each of these in more detail.

This is a pretty obvious reason that personas would fail. Educating people about persona and how to use them, IN ADVANCE of creating personas is critical.

Leaders in the teams/orgs that are using personas need to understand them and support their use.

This happens all too often. One of the main reasons is that personas are not internalized by the team members. i.e. they are an abstract notion or document that remain separated from day to day work and decisions.

This also happens quite often and is tied to the previous issue of personas being created but not used. The most common situation I’ve seen is that a UX team does their job, performs detailed user research, creates personas, often shared with a short 1–2 page template, and then presented to the team(s) that should use them. But the broader team doesn’t have a connection with the users the way the UX team does, so they can’t use them effectively.

Personas are not generic descriptions created for general use. Personas are the result of research into specific roles and created to help specific teams do their jobs. A common mistake when creating personas is to go broad (“so we don’t miss anything”) vs. deep. A broad persona is unlikely to be useful for anything but the most general questions/discussions.

There’s a great video by Kim Salazar (author of the article mentioned above) explaining the reasons personas fail.

Why Personas Fail — Kim Salazar

Who Can Benefit From Personas?

When thinking of personas, the most common type that comes to mind are user personas. i.e. descriptions of the target user(s) that product teams build for. These are used mainly by UX and Product teams to better understand the users they are building for.

But personas have much wider value and can (and should) be used across teams in a company. Marketing teams can leverage buyer and influencer personas to design specific marketing programs targeted at them. And sales teams can also leverage those personas when speaking to prospects during the sales cycle to build empathy and understanding with them.

This is how Len Fischer uses personas to build targeted marketing programs at Okta, a provider of identity and access management solutions.

“At Okta, we create personas to help us understand the needs, behaviors, experiences and goals of our current and future customers. Using personas helps us build scalable and efficient demand for our sales team.”

Len Fischer, SVP, Demand Generation at Okta

The personas used by Len’s marketing team at Okta — current and future customers — would be the same people that the sales teams sell to. i.e. there is a clear connection with and understanding of the customer (buyer) across marketing and sales.

What are the main types of Personas?

In the B2B. context, there are 3* major types of personas to consider:

  • User personas
  • Buyer personas
  • Influencer personas

*there may be more

As their names imply, these represent descriptions of the key roles in the marketing, selling and development scenarios the company focuses on.

User personas represent the potential users of the product. Some (simple) products/applications may have only one (or two) main types of users, while more complex applications (like the HR application mentioned earlier) may have many different types of users.

Understanding each of the user types via personas minimizes confusion or crosstalk with teams during meetings, discussions, or even during individual work as many smaller decisions can be made that in total, have a large impact on a product.

Additionally, the user that is understood during product development should align with the user that is marketed to once the product is released.

Does it make sense for Product and Marketing to have different conceptions of the target customers? No. And yet this is a common problem that occurs in many technology companies.

Buyer personas help companies (esp. B2B vendors) understand the characteristics, goals, challenges etc. of their buyers. A buyer is typically the decision maker in the buying process; often an executive or department head or other person with ultimate signing authority.

They may or may not be in the same department as the end-users. e.g. a CIO signing off on an analytics product).

A company selling multiple products may have a unique buyer persona for each product.

e.g. if one of their products targets IT and another targets a business group (like a Marketing department), then clearly the buyers for each will be different and so the personas will be as well.

B2B buying decisions often include influencers. These are not buyers or users, but are people who have significant input into the buying process and can (in some cases) block a purchase decision.

For example, many companies now have a security audit of products they purchase. These audits are often done by the customer’s security teams. Vendors need to address the requirements that security teams have. Understanding the needs and objectives of security teams and the individuals who will perform these audits (security analysts?) in both the evaluation/sales process as well as through product functionality is a key to success.

Part 2

In part 2 , I dig into further details on:

  • Determining what information should be in a persona?
  • How to decide which personas you need
  • How to create compelling and effective personas (5 step process)
  • And you’ll get to meet Karl, one of the most successful personas I worked on, and understand why he was successful.

A little feedback please

If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take you 30 seconds at the most, but will really be valuable to me. Thanks in advance.

===> Click here. <===

Here are a few good articles on Personas to give other perspectives on the topic.

The first one is by my friend James Costa.

Product Consultant. Contact me for help in building great products, processes and people. http://www.transformationlabs.io