How we stay close to customers to create better user personas at Mixpanel

When you’re deep in product development, it can be surprisingly easy to overlook who you’re making your product for. You may understand the technical nuances of the problems you’re solving or the general trends in your market, but if you can’t truly empathize with the people experiencing those problems, you’ll build a sub-optimal product.

This sounds pretty obvious, but understanding your product’s users is often easier said than done, especially when you’re building for multiple different personas. 

That’s our situation here at Mixpanel. Mixpanel is both a highly technical product and also one that anyone should be able to use. And when you’re building an analytics tool for everyone, persona work is nuanced.

As a Product Lead, I continuously emphasize to our broader team the importance of defining personas so that we’re clear about who we’re targeting when shaping our product or positioning. I’ve found a big piece of getting this right is keeping those of us on the development side as close to our customers as our support or sales teams. Here are a few ways we do it.

In the spring of 2022, I had recently joined Mixpanel and was tasked with solving “our enterprise adoption problem.” One of the first things I did was organize a strategy offsite for several cross-functional leads on my broader team, which included members from customer success, design, engineering, and marketing. I wanted to get the cross-functional team together to dive deep into our enterprise user personas so we could identify opportunities to help make Mixpanel easier to adopt at larger organizations.

The first activity of our offsite was a role-play activity because I wanted folks to develop a deeper empathy for roles that were specifically different from their own. A customer success lead looked into the PM persona, a PM looked into a data engineer persona, and so forth. Then, each person shared what they learned about their assigned persona, answering questions like:

Vocalizing these points helped the team gain perspective and prevented them from assuming that all customers think like them (an easy trap to fall into). This exercise developed our team’s first principles for understanding who we’re solving for. When everyone on the team shares this foundational understanding of our personas, everyone can feel empowered to make decisions without explicit sign-off from myself or leadership, which allows us to move faster.

Other benefits of the exercise:

Mixpanel is a SaaS product. That means another aspect of persona-creation for us is understanding how a persona may influence sales deals. While it’s easy to bucket customers by their segment (like SMB vs. enterprise) or job title (like Product Manager vs. Data Analyst), it’s often more important to understand common relationships between their roles and the influence they play during an initial evaluation or renewal. Understanding how different individuals impact your product’s sales cycle can help you position your product in a way that appeals to the right person at the right time to move deals forward. Understanding deal dynamics is critical if your product requires support from multiple teams and stakeholders to have successful adoption in larger organizations, as in the case of Mixpanel.

The common categories that different people fall into during Mixpanel’s deal cycles are:

By identifying these four categories of influence, we’re able to tailor our messaging and product development in a more targeted manner. For example, if we know an engineering team or data team owns the Mixpanel budget, we know it’s most important to convey how easy it is to implement tracking with Mixpanel. Whereas, if we know a product or marketing executive owns the Mixpanel budget, it’s more important for us to convey how easy it is to create and share reports that show the impact of product usage or marketing ad dollars on business outcomes. 

Anytime you can get closer to a customer, it makes solving their problems much easier. But you don’t have to wait for people to become customers to do that. You also don’t need to rely solely on customer outreach to gain insight into how people use your product. The sales process is a great source of information to scale your team’s knowledge. 

Mixpanel records all customer and sales calls, with consent, and the product team flags certain terms or phrases so that if someone says them on the call, the team will be notified. In a lot of cases, it can be a springboard to a more targeted conversation with the customer or prospect to dive deeper into a pain point.

For example, I saw in one of our customer calls that a data engineer shared a feature request with their account team rep for us to build a SQL interface. The customer wanted to customize transformations of tables prior to Mixpanel ingestion when using our Snowflake Warehouse Connector. I listened to the call and wanted to learn more about the specific use cases that they were looking to solve for, so I set up a follow-up meeting with that data engineer and made sure to bring a couple of engineers from my team. We dove deeper into their request and came up with a product solution that solved for a pain point in their warehouse integration workflow—which also happened to be a pain point that our own internal data teams felt when dogfooding our Warehouse Connectors.

From that call, our engineers were super motivated by being able to see the customer’s problem so clearly and knowing they could do something to solve it. It was a lightbulb moment. Everyone agreed on what they needed to work on, and we solved it quickly. And not only did that call allow our team to build a better user experience for the specific workflow in question, but it further solidified our understanding of the data engineer persona, fueling our first-principles instincts for future prioritization and shaping.

At Mixpanel, we constantly route customer feedback to our product teams. We’ve found that frequently reading through support tickets, in addition to our periodic deep dives on customer calls, helps us get an even fuller picture of current customer wants and needs.

For even more qualitative data here, we use an automated enterprise Slack channel. Interactions from enterprise account customers, such as product feedback, an NPS score, or a deal note, all automatically feed into Slack. All our engineers, designers, and PMs are in the channel and can interact with this feedback in real time. 

This automation takes the initial persona-creation process one step further. Our team can refer back to the personas, understand who is submitting the feedback, and have that more holistically shape their interpretation of the feedback. 

On top of all of that, our product team also harvests comments from beyond our customer and prospect base. I’ll frequently reach out to people on LinkedIn or the dbt Slack Community to ask them about what they’re looking for in tools. If I come across someone who’s written a newsletter or tweeted about a topic relevant to our work, I reach out to them to set up a call.

Our understanding of our user personas gets richer with every new piece of customer or prospect insight we gather—no bit is too small. 

There’s no one-size-fits-all persona, especially when your product speaks to both technical and non-technical roles, as well as a wide range of titles across different organizations. Product teams need to capture the essence of each customer type without assuming that customers’ needs are static and predictable.

Systems and habits that center the customer voice are the best way to create, and maintain, useful customer personas. By instating rituals that promote customer understanding, systems that bring the customer voice into the organization, and feedback loops that allow for dynamic iteration, your personas will better reflect the needs of each customer.

Understanding the customer never ends. I’ve learned that the best way to build products that people love is by constantly listening to and understanding customers’ needs. The more we all know the people we’re building for, the better we can solve their problems and enable progress.