© 2025 Alexandra Zhao
00
Background
01
Consumer Persona Reconstruct
02
Making the Case
03
Methodology Design
04
Research Execution
05
Synthesizing the Data
06
Key Findings
07
Impact
08
Reflection
I proposed a hybrid persona framework, grounded in:
The new approach focused less on who users are, and more on what they’re trying to achieve—a better fit for product design and messaging.
(A preview of the new persona format was shared with stakeholders to illustrate the value and usability of the updated approach.)
(The JTBD Data Model shows a process of how new market behavior is created. In this case, it shows how a JTBD is created and how it results in someone hiring solution(s) for it.)
Rather than updating old personas, I started from scratch. The new set would:
With strong cross-functional alignment, I dedicated 90% of my time to this foundational initiative while continuing to oversee enterprise research efforts.
TL;DR
It’s less about Who they are, and more about how they interact with our product and what they are trying to achieve and most importantly, why does it matter to them.
Each session combined open-ended narrative exploration with a few quantitative prompts to assess:
The core focus was to understand the goals users were trying to achieve, their perceived constraints, and how they navigated their digital lives.
A total of 46 sessions were transcribed, coded, and analyzed across four key dimensions:
Instead of fitting users into pre-defined archetypes, I took a bottom-up clustering approach to identify groups with shared patterns.
I experimented with different grouping methods—starting with goals, then behaviors, and vice versa—to stress-test the consistency of those patterns.
To supplement the qualitative clusters, I explored basic clustering algorithms using the small-scale quantitative data collected (e.g. vulnerability scores, confidence levels, security vs privacy priorities). Unsurprisingly, the sample size was too small to yield statistically significant clusters, but the data still served as a helpful validation layer to reinforce and challenge the qualitative segmentation.
(snapshot of early analysis: color-coded themes, initial categorization and frequency counts.)
The final result was a set of five personas, each anchored by:
Where relevant, I included overlapping buyer behaviors to support marketing and support team alignment, while ensuring the personas remained focused on in-product user needs.
89% of participants prioritized identity theft protection as a top need.
Privacy vulnerability was significantly higher than security vulnerability:
44% felt fairly or completely vulnerable about privacy risks (vs. 13% for security).
Confidence in managing privacy was markedly lower than security:
Only 31% felt fairly or completely confident in managing privacy risks, compared to 65% for security.
Note: “Casey, the Casual Utilitarian” was removed from the final set. His behaviors and goals overlapped significantly with other personas and didn’t offer unique design implications. Meeting the needs of the four remaining personas would effectively satisfy over 90% of Casey’s needs, making his inclusion strategically redundant.
The existing persona, though still directionally valid, was developed by a former researcher years ago before many of us joined the team. There’s a lack of internal education.
At the time, our core corporate product revamp project was the top priority and a new team had formed to rebuild the console from the ground up. My team was fully allocated on that task.
Recruiting IT admins with security responsibilities—our core audience—was notoriously difficult. A full-scale persona study wasn’t realistic within the timeline.
After completing the update for our corporate persona (Masab), it became clear that we also needed to address the Managed Service Provider (MSP) segment.
For context:
Nebula is our platform for direct business customers, where IT admins manage endpoints within their own organization.
OneView is our platform for MSPs, who manage security across multiple client organizations using separate Nebula instances.
While both products serve IT admins, the company context differs significantly. With direct customers, the persona must reflect both the admin and their business environment. With MSPs, that complexity increases—MSPs are managing multiple businesses, often with varying security postures, compliance needs, and operational models.
That said, when it comes to individual product use—monitoring threats, deploying policies, responding to alerts—an IT admin is still an IT admin. Masab remained valid for understanding their day-to-day goals and behaviors
Instead of creating an entirely new persona, I chose to supplement Masab with additional insights specific to MSP companies.
Historically, MSPs had been treated as an add-on to broader product development. As a result, our internal understanding of their business structures, roles, and constraints was limited. I saw this as an opportunity to close that gap.
I conducted 12 in-depth interviews with small to mid-sized MSPs. The goal was to better understand:
We also updated the firmographic section of Masab to include MSP-specific company traits—building on the same persona framework for consistency.
The study surfaced new insights about MSPs—many of which had been previously anecdotal or misunderstood. Based on the research, I grouped our target MSPs into three operational categories, each defined by their goals, size, and structural strengths/limitations.
Finally, I created a lightweight MSP supplement persona to pair with Masab—focused not on the individual admin, but on business-level considerations unique to the MSP context. This helped product teams make more informed decisions around licensing models, multi-tenant controls, and report generation features specific to OneView.
© 2025 Alexandra Zhao
I proposed a hybrid persona framework, grounded in:
The new approach focused less on who users are, and more on what they’re trying to achieve—a better fit for product design and messaging.
(A preview of the new persona format was shared with stakeholders to illustrate the value and usability of the updated approach.)
(The JTBD Data Model shows a process of how new market behavior is created. In this case, it shows how a JTBD is created and how it results in someone hiring solution(s) for it.)
Rather than updating old personas, I started from scratch. The new set would:
With strong cross-functional alignment, I dedicated 90% of my time to this foundational initiative while continuing to oversee enterprise research efforts.
TL;DR
It’s less about Who they are, and more about how they interact with our product and what they are trying to achieve and most importantly, why does it matter to them.
Each session combined open-ended narrative exploration with a few quantitative prompts to assess:
The core focus was to understand the goals users were trying to achieve, their perceived constraints, and how they navigated their digital lives.
A total of 46 sessions were transcribed, coded, and analyzed across four key dimensions:
Instead of fitting users into pre-defined archetypes, I took a bottom-up clustering approach to identify groups with shared patterns.
I experimented with different grouping methods, starting with goals, then behaviors, and vice versa, to stress-test the consistency of those patterns.
To supplement the qualitative clusters, I explored basic clustering algorithms using the small-scale quantitative data collected (e.g. vulnerability scores, confidence levels, security vs privacy priorities). Unsurprisingly, the sample size was too small to yield statistically significant clusters, but the data still served as a helpful validation layer to reinforce and challenge the qualitative segmentation.
(snapshot of early analysis: color-coded themes, initial categorization and frequency counts.)
The final result was a set of five personas, each anchored by:
Where relevant, I included buyer side behaviors to support our marketing and support team, while keeping the primary focus on in-product user needs.
89% of participants prioritized identity theft protection as a top need.
Privacy vulnerability was significantly higher than security vulnerability:
44% felt fairly or completely vulnerable about privacy risks (vs. 13% for security).
Confidence in managing privacy was markedly lower than security:
Only 31% felt fairly or completely confident in managing privacy risks, compared to 65% for security.
Note: “Casey, the Casual Utilitarian” was removed from the final set. His behaviors and goals overlapped significantly with other personas and didn’t offer unique design implications. Meeting the needs of the four remaining personas would effectively satisfy over 90% of Casey’s needs, making his inclusion strategically redundant.
The existing persona, though still directionally valid, was developed by a former researcher years ago before many of us joined the team. There’s a lack of internal education.
At the time, our core corporate product revamp project was the top priority and a new team had formed to rebuild the console from the ground up. My team was fully allocated on that task.
Recruiting IT admins with security responsibilities—our core audience—was notoriously difficult. A full-scale persona study wasn’t realistic within the timeline.
© 2025 Alexandra Zhao