Let’s face it, user personas have gotten a bad rap over the years. Countless companies spend time and money investing in building a set of personas, but end up with nothing more than posters in a hallway ignored by most of the organization.
As a result, many modern product teams have decided to abandon personas altogether and adopt practices like user scenarios, user stories, or the “Jobs to be Done” framework instead.
Here at Amplitude, we still believe in personas. Here’s why.
Building personas is still an effective way to build empathy. As we grow, our user base becomes increasingly diverse. Is our understanding of our users and potential users still up to date? Building personas requires our team to “get out of the building” and talk to our customers.
Personas provide a common language across multiple teams. It’s hard to discuss how a product feature should work for a type of user if team members have different interpretations of who the user is. We’ve noticed that in product development meetings, teams would often describe segments of our users as “product managers”, “power users”, or even specific users of our product that some people knew but others didn’t. But what exactly defines a user as a product manager or power user? Personas paint a clear picture of who our users are and how they are differentiated from one another.
Personas have been instrumental in helping us build a better product.
Personas have been instrumental in helping us build a better product, so much so we wanted to share our learnings on how to build personas that stick (and not just to a wall)…
How we created our user personas
To create our , we followed a three-stage process of research, synthesis, and profile building. I hope this example gives you inspiration and perhaps a template for creating yours. Let’s dive into each step.
1. Lots and lots of research
When the design team first set out to build personas, we aimed to interview as many people with various jobs and titles as possible—essentially for user personas. To achieve this, we focused on the following two things:
First, the product designers partnered with the product team to distribute the research work. This way, we could double the number of interviews. Also, by giving our product managers ownership in the personas project early on, it helped ensure that the product team will be using personas once they’re created.
Second, we got creative with recruiting participants. Since talking to existing users wasn’t likely to yield new insights, we mainly targeted people that were not our customers. We took advantage of our personal network in addition to cold emailing participants.
We even went so far as to launch a Linkedin ad targeting product-related roles! Ultimately, we ended up interviewing over 30 people, including product managers, product analysts, directors of product, data scientists, administrators and so on.
To find the right interviewees for our persona research, we launched a Linkedin ad targeting product people.
As a result, not only did we gain a deeper understanding of our target user group (product managers) but also discovered lots of other people that are involved or influenced by product analytics, such as analytics tools administrators, engineers, product analysts, and product executives.
2. Synthezise the findings
To synthesize research findings, we booked a working offsite with the product and design teams so that we could tackle the most critical step of persona building together and free of distractions.
Design team offsite dedicated to user persona work.
We started by having each team member present the most interesting nuggets from each conversation in order to get the entire team on the same page. Afterward, we broke into groups to come up with our own sets of personas. Brainstorming in small teams allowed us to work closely with each other as well as compare different ways of thinking across teams. Finally, each team presented their own set of personas as well as the reasoning behind the groupings.
This method proved particularly fruitful for us. One of the teams was looking for a way to map every research participant onto a simple chart and came up with the following quadrants:
Our core user personas mapped into 2×2 quadrants
In the chart, the x-axis depicts the level of the person’s overall analytics skills. It includes their knowledge of analytics tools (Amplitude, Tableau, SQL, etc.) as well as how comfortable they are doing any analytics work on their own. The y-axis represents motivation: how motivated is the user in learning new analytical methods as well as creating a data-driven culture in their organization? We mapped four groups of users with very distinct motivations, aspirations, and behaviors.
The quadrant even provided a framework to take our analysis to the next level. We loved this way of thinking about our users. We could now map distinct behaviors and characteristics all in one place. It sparked us to think about how can we move users from consumer to advocate.
3. Build the profiles and validate
The design team then continued to iterate on the personas. We ended up with a total nine personas. Why nine? We wanted enough personas to capture all the important nuances in each user group but not too many to overwhelm.
In the end, we created nine user personas in two groups: Core Users and Enablers.
As you can see, we identified five secondary personas in addition to the four core ones. These five personas are not our typical users, but they are important to identify because they highly influence if the core users are going to be successful with Amplitude. We call them Enablers.
For example, without Data Governors and Instrumentors keeping Amplitude data clean, none of the users can uncover reliable insights from their analysis. We grouped the nine personas into two different groups to provide additional context around the personas and also make it easier for people to remember.
To validate that the personas represent real users well, we hosted many listening tours with our Sales Engineering and Customer Success teams (who are continually talking to prospects and customers). These sessions confirmed that the set of personas we created align with their understanding of our real users.
Side note: Choosing names for personas
Names matter. Personas are not going stick if the names to describe them aren’t right. We wanted the names to capture the unique characteristics of the persona without a need for additional information.
An example of naming a persona
While disussing a name for what ultimately became the Advocate persona, we considered the name Champion. It checked the boxes of being self explanatory and easy to remember but fell short in one crucial area: it was already in use.
We realized that our sales and success team already use Champion heavily to describe certain customers. If we introduced a user persona Champion, we would be shooting ourselves in the foot and creating confusion. So we decided against it and went with Advocate.
The time and energy spent agonizing over personas names paid off when we started hearing folks reference the names in meetings.
Now the real work begins…
No matter how accurate and robust your personas are, they’re if no one in your organization actually uses them.
What you do after you’ve finalized your personas is perhaps even more critical than the work of building them.
In our case, we continued to host listening tours and present relevant subsets of personas to additional teams in the company. During these presentations, we explained why we built personas and how we came up with these groupings.
At a company all-hands meeting, we gave a deep dive into the process and results to promote the project. We’ve even added personas into our new-hire onboarding training to make sure everyone in the company is familiar with them.
How personas impact product strategy
Perhaps the most significant impact of personas is in how they inform our product strategy. Because the personas gave us a birds-eye view of our user base, our product team identified three strategic personas that we wanted to focus on for the year. For each of these three personas, we formed a dedicated team (pod) to solve the unique problems each persona encounters.
Conclusion
We’ve found the personas exercise to be valuable for building empathy and guiding our product strategy. Hopefully, I’ve gotten you to rethink personas and start your own project!
What’s your experience with personas? Let us know.