Sumo Logic is an industry leading cloud based log management tool. It's a swiss army knife for developers and ops personnel to monitor and troubleshoot their applications.
Organizations use Sumo Logic to monitor their applications and troubleshoot outages, security intrusions etc. Our users run queries to analyze their logs, analyze their metrics data, and visualize it all in dashboards.
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.
I teamed up with another product designer to conduct research, analyze the data, and visualize the results.
In the pre-persona era, 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 Product Management, Engineering, and Customer Success teams 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?".
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:
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
Since we were limited on direct customer interviews, we had to rely on other sources of customer feedback.
We used affinity diagramming to discover patterns in this data.
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.
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:
I explored several options to visualize these personas and their key behaviors. The final personas:
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:
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:
The product development team uses these 2 insights to drive product decisions focused on improving our NPS.
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."