Defining Personas

Defining archetypal Sumo Logic users to drive product strategy, align cross functional teams, and ship successful features.

My Role

Co designer. Sumo Logic

Result overview

Product Management, Engineering, and Customer Success have adopted these personas in day to day conversations. When talking about bugs or new features, they frame it as - "Is this for a Melinda or an Andre? How exactly is it helping them? How will this help them give us a better NPS?".

Before we had these personas, Product Management focused on solving individual customer needs, or needs of the most frustrated set of customers. These Personas have helped them get a deeper understanding of our customers and target them more precisely to improve our NPS scores.

The Challenge

Sumo Logic customers vary from 15 person agile startups to 500+ established software organizations. Our users have strong opinions and give us constant feedback via the support portal, feature request portal, and NPS surveys.

Addressing this feedback got tricky because engineering, customer success, and product management were not aligned on the core customer pain points. Each group formed their own perception of customer pains based on the feedback they were receiving.

Our VP of User Experience took the initiative to define Personas in an effort to align the Product Development team. This helped the team use a unified language to identify and describe product strategy.

Process

Defining what we wanted to learn

We wanted to take a step back from our user's frustrations and understand how Sumo Logic fits into our their product development cycle.

We created a list of key questions to answer:

1. Who are the primary users of Sumo Logic in a development team?
2. When in the product lifecycle are they using it?
3. What are key goals they are trying to meet with Sumo Logic?
4. Where does Sumo Logic fall short in helping them achieve their goals?
5. Where does Sumo Logic excel?
6. What are some other tools they use in their day to day work?

Interviewing users

We created a script for interviewing customers based on our key questions. We had an ambitious plan to interview customers across the country, different industries, and organization sizes. Due to budget constraints, we narrowed our list down to 2 representative customers

• An 80 person strong dev team at a startup with a siloed dev ops team
• A collaborative 15 dev team functioning as a startup within a large organization

Consolidating feedback

Since we were limited on direct customer interviews, we had to rely on other sources of customer feedback.

1. NPS comments and follow up emails
   • I collated comments and emails where users mentioned use cases Sumo Logic excelled or failed at, what they would like to improve in Sumo Logic, and other tools they preferred over Sumo Logic.
2. User testing ice breaker questions
   • We had been conducting user research on our features for almost a year now. We revisited our notes and collated details around
     • Our user's job titles and tasks
     • Their key workflows in Sumo Logic
     • How other users in their organization used Sumo Logic

Analyzing the data

We used affinity diagramming to discover patterns in this data.

Throwing all the feedback on the wall

Grouping the feedback into themes

From an initial reading of the data, we realized that our users often fell on opposite sides of several dimensions. We made an initial pass at these dimensions and validated the data against it.

Dimensions that emerged from the themes

We kept rearranging the post it notes till we reached a meaningful set of groupings. Some interesting insights that emerged out of these groupings were:

1. It did not make sense for the personas to have a fixed job title like developer or SRE. In many organizations, large and small, the line between these roles is getting blurry.
2. Users who did not like Sumo Logic were logging in infrequently primarily because our app was not a part of their core tasks. The difficult query language only exacerbated the problem of infrequent logins.
3. Users who loved Sumo Logic loved the power of the tool. However, they were incentivized to master the query language given that Sumo Logic fit into their core job tasks.
4. There was a superficial Sumo Logic user who relied on core users to provide them interesting data to look at in the product.

Crafting the personas

I explored several options to visualize these personas and their key behaviors. The final personas:

Melinda

Andre

Kathy

Comparing Andre and Melinda

Result

Impact on NPS

We were able to theorize that our low NPS scores could be attributed to the fact that Andre's far outnumber Melinda's in our customer organizations, and that Andre's give us a much lower rating than Melinda's. They rate us lower because:

• They mainly use the product when troubleshooting a problem. When they are fighting a fire, the want to find the needle in the haystack asap, without having to learn a complex language to find that data.
• In product collaboration is broken. It is hard for Andre's to find content created by the Melinda's quickly. They have to rely on internal wikis, Evernote, Google Docs etc. to keep track of essential queries and dashboards that they can access quickly.

Melinda's on the other hand are responsible for keeping their service running and hence, invest in learning Sumo Logic so they can monitor their services better. Once they discover the power of Sumo Logic, they love it.

This led us to proposing that there are 2 key methods to improve our NPS:

• Help Andre's get started with Sumo Logic faster
• Help Melinda's help Andre's get started faster by letting her create content for him and helping her deal with the complexity for him

The product development team uses these 2 insights to drive product decisions focused on improving our NPS.

Putting Personas to use

Throughout this process, we were constantly gathering feedback on personas from our internal stakeholders from PM, Engeering, and Customer Success. Our story of Andre, Melinda, and Kathy resonated deeply with everyone. They could see how we derived these personas, empathized with the customer stories that backed up these personas, and were on board with their evolution.

We realized the personas were succesful when all these functional groups were using our persona names to talk about use cases, customer pain points, and features. For example, some engineers started identifying as Andre or Melinda. Customer Success started categorizing some customers in the NPS feedback as Andres or Melindas. Product Management started rephrasing their features from the perspective of Melindas or Andres.

For example, there was a big intitative to fix content sharing in Sumo Logic. The existing model did not allow users to share with individual users, or team, or with any ability to edit items. It was a none or everyone model of sharing that was highly restrictive.

Initial PM requirements around this feature focused on individual customer complaints. The user stories reflected the key stories of users at this organizations. When we rolled out Personas, it was much easier for them to reframe the problem from the perspective of Andre's and Melinda's. They could use the personas to target our NPS scores better.

The value proposition shifted from "let's work on this feature because it is one of the most complained feature" to "how can we help Melinda share useful content with Andre so he can derive value from Sumo Logic immediately."