Buyer and User Personas are a staple of contemporary SaaS product management and marketing. Personas are tools that simplify complexity for marketers, sales professionals, and developers. There is a lot of advice on the Internet on how to build personas – Google conveniently lists 68,900,000 links to help you. Qualitative in-depth interviews are critical to developing and refining personas. For SaaS companies personas naturally evolve over time. As a product moves through the various stages of the technology adoption life cycle, buyer and user personas evolve. Just as you go to the doctor every year for a physical, or you go to the mechanic when your check engine light comes on, you should refine your personas. Product managers should use qualitative interviews to refine personas.
History of Personas
The concept of using personas for software companies traces its roots to the mid-1980s. Alan Cooper, a noted pioneer software developer and author of Plan*IT (which became SuperProject) and the Ruby programming language which he sold to Bill Gates and was combined with QuickBasic to form the foundation of VisualBasic. Alan described his evolution of the persona concept is a lengthy post entitled “The origin of personas”. Here is an excerpt from that post:
In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of Plan*It to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program.
As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.
In 1995 I was working with the three founders of Sagent Technologies, pioneers in the field of what is now called “Business Intelligence” software. During discussions with them regarding interaction design for their product, I found myself continually engaged in a circular dialogue. I would ask them for a specific example of how someone would use their program. The answer would invariably follow this characteristic pattern: “Well, someone could create a crosstab of sales information…but it could be a chart, or if it were marketing data they could present it as a table. They could do anything!” It was almost impossible for those brilliant, logical programmers to conceive of a single use of their product when it was obviously capable of so many uses. In frustration I demanded to be introduced to their customers.
At the time, the company was new, and the product wasn’t yet released, but the founders had well-established business relationships from three previous companies. Alice Blair, Sagent’s head of product marketing, took me on a tour of a half-dozen or so of their intended clients. One of them was a financial analyst for a large university. One was a marketing analyst for a software firm. Some were computer savvy and some were not. I asked them open-ended questions to learn about their jobs and what they were trying to achieve by studying these large quantities of data. Even though the variation among the users was dramatic, a clear pattern emerged after just a few interviews. The users fell into three distinct groups, clearly differentiated by their goals, tasks, and skill levels. Had I been creating the software myself, I would have role-played those users as I had with Ruby and SuperProject, but in this case I had to describe those user models to the Sagent team. So I created Chuck, Cynthia, and Rob. These three were the first true, Goal-Directed, personas.
Chuck was an analyst who used ready-built templates and reports. Cynthia was an analyst, too, and she used similar ready-built templates. But Cynthia also wrote her own templates, which she gave to Chuck to use. Rob was the IT manager who supported both Rob and Cynthia. He could optimize Cynthia’s templates, but he would never originate or use them.
The origin of personas
Since then the use of the persona concept to describe buyers and users of technology has become commonplace.
Persona Examples
There are two basic types of personas – buyer personas and user personas. Think of a user persona as a composite biography (or series of biographies) you draft based on your market research and experience to describe the relevant characteristics, needs, and goals of the people who will be using your product. The key distinction for our purposes here is that these will be the product’s end-users — but not necessarily the ones deciding to buy it from you.
A buyer persona will be a broader composite biography of your target customer than the bio you draft for your user, because it can include a wide range of influencers and decision makers across your customer’s organization. It’s also important to note that the buyer persona will not necessarily be the person using your products, which means the goals and needs you draft for this persona will likely differ from those of your user persona.
When building personas it is important to differentiate what type of persona you are building and its intended use. There is also a difference for B2C personas and B2B personas. Most personas, however, have similar characteristics:
- Name
- Titles
- Description
- Challenges (are the problems that cause the most trouble in their daily work)
- Aspirations (describe what will improve their performance or benefit the business)
- Abilities (are their technical knowledge and expertise including products used)
- Access (details the most relevant aspect of the persona for marketing activation
Here are three example personas:
B2C Buyer Persona
B2B Buyer Persona
B2B User Persona
Persona Development Process
The best way to develop/refine personas is to conduct qualitative interviews with customers, prospects, and even lost customers. Qualitative research focuses on gathering subjective data like transcripts from in depth interviews, focus groups or video recordings. Qualitative research provides more insight into the research subject’s thinking or behavior, but typically lacks the statistical rigor that quantitative research offers. Quantitative research concentrates on gathering and analyzing large amounts of data via surveys or questionnaires. Analytics data such as user recordings, heat maps, and website analytics are often the most common quantitative analysis techniques.
Qualitative research, like in-depth interviews, are best suited for answering questions that begin with ‘Why?’ Why does this positioning resonate so well with this market sub-segment? Why do users consider this feature set to be innovative while others consider it to be irrelevant? Why do customers not want to buy an upgrade that includes these 10 new features? These are the types of answers that you cannot get from an online survey or a website analytics tool. Quantitative research has a role in the persona development process, but it is limited.
The persona development process typically consists of five major activities:
Conduct Demographic/Psychographic Research
The process should begin with basic demographic and psychographic research. This type of data can lay the foundation for building effective buyer and user personas. Product managers can leverage resources like CRM systems, sales force automation systems, and customer support systems to identify a set of candidate users or buyers. These systems will provide basic information like name, title, and locations. This data can be augmented with data pulled from solutions like LinkedIn, Facebook, and Twitter to identify additional attributes like industry, company size, years of experience, education, certifications, and interests. There are even services like Clearbit that can enrich your basic contact information for you.
Quantitative demographic and psychographic plays a role in persona development, but it is limited. As Mike King noted in Data, Demographics, and User Personas “Ideally, persona demographics should be a composite reflection of what researchers have observed in the interview population, modulated by broad market research.”
Recruit Interview Participants
The next step is to recruit participants for in-depth phone interviews. In depth interviews have significant advantages to Internet surveys. Most interviews take 20 to 30 minutes. While Qualitative Research does not offer the ability to use statistical techniques like Student’s T-Test to determine the statistical significance or margin of error in a survey, there is a relevant branch of statistical analysis known as Grounded Theory. Grounded Theory is a systematic methodology in the social sciences involving the construction of theories through methodical gathering and analysis of data. One aspect of Grounded Theory is the concept of saturation. Saturation of data means that researchers reach a point in their analysis of data that sampling more data will not lead to more information related to their research questions. In conducting Win-Loss Analysis interviews, saturation is often achieved after 15 to 20 interviews. If 15 prospects say “I chose you competitor because their pricing was 40% less than yours” a product manager can reasonably infer that there is a problem with their pricing strategy.
Building personas for vertical industry oriented solutions generally require fewer interview candidates than for horizontal solutions. Manufacturing resource planning solutions for process manufacturing industries like oil and aluminum are fairly similar. Horizontal solutions like General Ledger or Payroll have fundamentally different requirements for retailers like Wal-mart, trucking companies like Swift Transportation, or technology firms like Facebook.
15 interviews will provide you with a solid foundation to build/refine your personas. While recruiting can be hard sometimes, companies often offer small incentives like a $50 VISA gift card.
Conduct Interviews
The next step is to conduct the interviews. Usually, these are conducted by phone and often independent experienced interviewers are used. Web meeting services like GoToMeeting or Zoom are used so that the interviews can be recorded. The interviews usually last about 20 to 30 minutes and consist of a series of open ended questions. Typical questions include:
- Job Role and Title
- Responsibilities
- What a typical day looks like
- Skills and knowledge required for the role
- Biggest challenges
- Reporting and team structure
- Associations and social networks
- Personal demographics
- Education background
- Career path and goals
After the interviews are completed the recordings are transcribed. There are services that can transcribe recordings for you, like Rev.com, for $1/minute.
Analyze Recordings and Build Personas
The next step is to analyze the interview transcripts and build your personas. As Mike King noted:
Personas must be developed and treated with dignity and respect for the people whom they represent. If the designer doesn’t respect his personas, nobody else will either.
Archetypes (specifically in regards to personas) are an aggregate model of significant and meaningful patterns of user behavior. In this manner, persona archetypes help us design for specific types of people with specific goals and motivations.
Stereotypes, by contrast, are a model of biases, assumptions, and generalizations about a particular audience, with no basis in factual data. Due to inadequate research (or empathy and cultural sensitivity), personas run the risk of devolving in to stereotypical caricatures and subsequently, negatively impacting the users of your product.
You probably already have a preferred format for documenting your personas. You should consider revising it based on feedback from the consumers of your personas (marketing, sales, development, etc.) What issues have risen in the past from interpreting the personas? What additional information could have been helpful? A persona is a living document – it should evolve as your market naturally evolves from one stage of the technology adoption life cycle to the next.
Socialize Personas
The last step is to socialize your personas with your target audience. Don’t just send an email with fancy PowerPoint slides, conduct briefings where you explain the nuances of the personas. Leverage quotes from your interviews to drive key points home.
Keep Your Personas Evergreen
It is important to keep your personas fresh. As your market and products mature changes can happen to your buyer and user personas. Qualitative interviews conducted on a regular basis can help your marketing, sales, and development teams to stay current with key trends in your market.
