Who we build for
We define who we build for as the ICP, i.e. the team, and the persona, i.e. the actual people using SucuriLabs.
Our current ICP
AKA our ideal customer profile.
We build for security and IT teams at companies using Microsoft 365.
We want to be the first tool they go to when they need to investigate and stop an email threat.
| Security and IT teams using Microsoft 365 | |
|---|---|
| Description | Companies that depend on email to work with customers, suppliers, and partners. They already have email security, but their security or IT team still spends too much time figuring out whether a message is malicious and what to do about it. |
| Criteria | - Microsoft 365 - Initially, companies with 100+ employees - A small security team, or an IT team that also handles security - Lots of email with people outside the company - Existing email security, but continued manual investigation of phishing, compromised accounts, and impersonation |
| Strong signals | - A recent phishing, business email compromise, or account-compromise incident - Someone regularly investigates reported emails by hand - Investigations involve switching between several tools - Alerts don’t explain why a message was flagged - The team worries about malicious emails that don’t contain an obvious bad link or attachment |
| Why they matter | - They have a problem we can solve: too much time spent piecing together evidence - They investigate attacks themselves and have strong opinions on what they need, which helps us build a better product - If we make their investigations easier, they have a reason to keep using SucuriLabs |
| Examples | A mid-sized company whose IT team handles phishing reports alongside everything else. A company with a dedicated security team that still has to piece together evidence when someone impersonates a supplier. |
Our current persona
Persona is the job title or role of the person actually using SucuriLabs.
SucuriLabs’ initial adoption inside a company should come from a security engineering persona most of the time, because these are the people doing the investigations. This includes security engineers, security analysts, and SOC analysts. In smaller companies, it can also be the IT manager, head of IT, CISO, or CTO who handles security alongside everything else.
They receive phishing reports, check suspicious messages, and decide what to quarantine or restore. They know which evidence is useful and which alerts just create more work. If we make their investigations faster and give them better evidence, the product is useful before we’ve automated the whole thing.
We should go very hard on making sure a security engineer has everything they need to investigate and stop an email threat in SucuriLabs.
That means answering three questions well: Why is this email suspicious? Can I trust who’s sending it? What should I do about it? They should be able to check the evidence and override a verdict, rather than having to take our word for it.
Once we’re in with security engineers, we should make the product useful for the other IT and security people who work with them. An IT security manager or head of IT may spend less time on individual incidents, but still needs to understand what’s happening and manage protection for the company. Some work on setup, reporting, and clear explanations can make SucuriLabs more useful for them too, and we should do that when it’s obvious.
Employees benefit from the product too. They should encounter fewer malicious emails and get clear guidance when something needs their attention, without having to understand how detection works.
The anti-persona: people looking for a general-purpose security product, a spam filter, or tools for security awareness training, invoice approvals, or identity verification. Those are different problems. A finance team benefits when we catch supplier impersonation, but that doesn’t mean we should build their payment workflow. We build for the people investigating and stopping email threats.