How to do discovery

Discovery

The discovery mindset

Discovery isn’t walking through every SucuriLabs feature. It’s having real conversations to figure out if we can solve a problem for someone. Learn how they investigate email threats today, what’s difficult, and who would want to bring us in.

This is a guide, not a script. Everyone has their own style. The point is to help you ask the right questions, not give you lines to recite on every call.

Core principles:

Curiosity over pitching – be genuinely interested in their problems.
Find the pain – people buy solutions to problems, not features.
Identify champions – find someone who wants to solve the problem and can help others at the company understand why it matters.

Discovery isn’t one-sided questioning – it’s give and take. You learn something, you show something, you ask questions, repeat. Focus on what matters to them instead of everything SucuriLabs can do.

Why discovery matters

One team might spend hours piecing together evidence from suspicious emails. Another might struggle to decide what action to take or check what happened afterwards. We need to understand which problem we’re discussing before we show them the product.

Good discovery lets us:

Give a demo that actually matters – nobody wants to sit through features they’ll never use.
Connect their problem to the product – show how the evidence, review decision, or remediation action helps with the work they described.
Skip the irrelevant stuff – their time is valuable, and a generic sales call isn’t.
Help them make a decision – understand the requirements and concerns early, so a demo or pilot answers the questions they actually have.

Timeline

We don’t need to cram every question into the first call. Keep learning during the demo, pilot discussions, and follow-up. Write down what you learn so we don’t ask them to explain the same thing twice.

Other channels

Our outbound starts with manual LinkedIn outreach. Calls, demos, and follow-up conversations are all opportunities to understand the problem better.

Agree on how and when to follow up, and keep the conversation notes and next steps in TwentyCRM. The founders handle discovery and follow-up, just as they handle outbound sales.

Before your first call

Prep work

Discovery includes preparation. Before a call, find out enough to have a useful conversation. Start with why we contacted them and what made them agree to speak with us.

Examples:

Read who we build for and check the ICP fit score. A good score doesn’t tell us whether they have a problem they want to solve.
Check TwentyCRM for previous conversations, company information, and anything we’ve already learned. Our company enrichment is updated weekly.
Read their LinkedIn profile. Understand their role and whether they handle email investigations themselves.
Visit the company website. Learn what the company does and look for relevant context, such as a growing IT team or a Microsoft 365 migration.
Use AI to help with research if it’s useful, but check the sources. Don’t treat a guess about their setup or an incident as a fact.

Asking questions

Discovery is about understanding the real problem through natural conversation. Be genuinely curious about their situation, not an interviewer trying to get through a checklist.

Question principles:

Use “what” and “how” to signal curiosity rather than judgment.
Try “tell me…” or “walk me through…” to get beyond yes/no answers.
Ask how they handle the work today and where it gets difficult.
Ask about impact naturally as the conversation flows.
Listen to the answer before deciding what to ask next.

Understanding customer goals

Ask what they’re trying to accomplish. “What would you like to change about how you handle suspicious emails?” is more useful than “Would you like more automation?”

For example, if their IT team loses hours switching between tools to investigate reported emails, show an investigation from the verdict through the evidence and review decision. Ask which checks this would replace and what’s still missing. You’re showing how SucuriLabs could help with their work, not just what the buttons do.

Goal-discovery questions:

“What’s the biggest thing your security or IT team is trying to improve?”
“What takes the most time when someone reports a suspicious email?”
“What would a better investigation process look like for your team?”
“Is anything changing in your email setup or team that we should know about?”

When to use these:

In prep – research the company and form a hypothesis, then confirm it on the call.
During discovery – weave questions into the conversation naturally.
At the end of a call – ask, “Before we wrap, is anything changing that we should take into account?”
During follow-up or a pilot – ask what they’ve learned and whether the original problem is still the one worth solving.

Important: This only works if you’re genuinely curious. Forced interest is gross and salesy. Use what they tell you to shape the conversation, not to pretend you care before giving the same pitch anyway.

Showing SucuriLabs

The demo

A demo should show how SucuriLabs handles the problem they described. Work through a relevant incident, explain the evidence, and show what someone can do next. Technical people will learn more from that than from a feature list.

A demo is also a good place to keep doing discovery. Pause and ask how each part compares with what they do today.

Principles:

Show the work, not just the claims.
Use the demo as a conversation starter rather than a monologue.
It’s okay to say “I don’t know”. Write down the question and follow up with an answer. If you try to fake it, you’ll lose credibility.
Notice confusion, hesitation, and questions. Ask whether the explanation makes sense instead of assuming it does.
Adapt to what matters to them. Skip the parts that don’t.

Examples:

Detection reasons: Show the verdict and the signals behind it in the triage overview. Ask: “What evidence do you need before you can decide whether a message is malicious? What does your current tool show you?”
Sender identity: Show the sender assessment and authentication results in identity analysis. Ask: “How do you check whether a message really came from the person or company it claims to? Which parts are manual?”
Attachments: Show file details and hashes in the attachments section. Ask: “Where do you go to investigate an attachment today? What information is hard to find?”
Review and response: Show how to review a verdict, choose an available action, and check the remediation history. Ask: “How do you quarantine or restore a message? How do you keep track of who did what?”
Message access: Show the access-request process when message content is restricted. Ask: “How do you control access to message content during an investigation?”
Prevention modes: Explain detection-only and active prevention. Ask: “Do you want to review detections first, or automatically block malicious content? What would you need to see before changing that setting?”

Other questions you could ask while demoing:

“Who else would find this useful?”
“How does this compare to how you’re handling this today?”
“Which part would save you the most work?”
“What’s missing for you to use this in an investigation?”

Qualifying

Use the same qualification rules as outbound sales: fit, a real problem, and an agreed next step.

Qualifiers:

Fit: The company and person match who we build for. Confirm their Microsoft 365 setup and the work they handle.
A real problem: They describe a specific investigation or response problem SucuriLabs can solve and agree it’s worth exploring.
An agreed next step: They’re willing to do something concrete, such as a demo with their team or a discussion about a paid pilot.

Disqualifiers:

Outside our current ICP: Our hard exclusions include companies that don’t use Microsoft 365, public-sector companies, banks, and prospects using personal email addresses. See the fit score.
No problem we can solve: They need something the product doesn’t do, or they’re happy with how they handle email threats today.
Requirements we can’t meet: Understand the requirement and check what we support before making a promise. If it’s essential and we can’t meet it, say so.

A good fit isn’t automatically ready to buy. Ask about timing, budget, and who needs to be involved, but don’t use a fixed revenue or timeline cutoff. If the timing isn’t right, agree on whether and when to follow up. If they’re not interested, leave it there.

For a pilot, find out who can connect Microsoft 365, grant the required permissions, and choose the accounts to monitor. Pilot scope, goals, duration, price, and setup requirements are agreed case by case.

If someone needs help using SucuriLabs, help them with that question. Don’t turn a support conversation into a sales pitch.

Identifying your champion

Champions aren’t just people you’re friendly with. They’re people who want to solve the problem and will make the case for SucuriLabs when we’re not in the room. They can help us understand how the company evaluates tools, who needs to be involved, and what a useful pilot would show.

Examples

Questions to identify champions:

“Who else is affected by this problem?”
“How do you typically evaluate new tools at [company]?”
“What would need to happen for this to get approved?”
“Who would be most interested in solving this?”

Characteristics to listen for:

They describe the problem and why fixing it matters to their team.
They ask detailed questions about investigations, response, or setup.
They explain who needs to approve an evaluation or purchase.
They bring the relevant people into the conversation.
They can describe what they’d need to see in a pilot.

Look for actions as well as enthusiasm. Someone who likes the demo but won’t take a next step isn’t necessarily a champion.

Follow-up questions for champions:

“What’s your role in making this decision?”
“How have you handled similar evaluations in the past?”
“What concerns might others have about adding a tool like this?”
“Besides you, who else needs to be involved?”
“What questions should I be asking that I haven’t asked yet?”
“What would your team need to see to decide whether this helps?”
“How can I help you explain the problem and the proposed pilot internally?”

You can start identifying potential champions early, but building the relationship takes more than one call.

Discovery call structure

For a combined discovery and demo call, use the outline below as a rough guide. If the first call is only discovery, book the demo as the next step when there’s a fit. Don’t rush the conversation to get to a feature tour.

1. Opening and understanding the situation

Goal: Understand why they took the call, how they work today, and what they’d like to improve.

Potential questions to flow between:

“What made you decide to take the call after I reached out on LinkedIn?”
“What are you using for email security today, and how’s it working?”
“Walk me through the last suspicious email your team investigated.”
“Who handles those reports, and which parts take the most time?”
“What information is hardest to find before you can decide what to do?”
“How does your team typically evaluate new tools?”
“Is there anyone else who should be part of these conversations?“

2. SucuriLabs demo

Goal: Show how SucuriLabs handles their problem, get feedback, and find out what’s still missing.

Use the demo examples above. Ask how each relevant part compares with their current process. Leave time for their questions, and ask whether what you’ve shown would solve the problem they described.

3. Closing and next steps

Goal: Confirm whether we’re a fit and agree on a useful next step.

If we’re not a fit, say so and explain why. We don’t need to drag out a call that isn’t useful to either of us.
If there’s a real problem and they’re interested, agree on the next step: a demo with their team, an introduction to someone involved in the decision, or a paid-pilot discussion after the demo.
Ask what timing makes sense, who needs to be involved, and how we’ll follow up. Book the next conversation when you can.
For a paid pilot, agree on what they’ll test and what a useful result would look like, along with the scope, duration, price, and setup.
Record the problem, confirmed fit, unanswered questions, and agreed next step in TwentyCRM. Give the next step an owner and a date.

Keep it conversational. If you’re genuinely curious about their situation, this should feel like a useful discussion, not a sales routine.

Summary

Good discovery helps us understand whether SucuriLabs solves a real problem for someone. It lets us:

Keep conversations focused on their work
Show the parts of the product that matter
Be honest about where we’re a fit and where we’re not
Find people who want to solve the problem with us
Agree on a next step that answers a real question

Helpful docs for more learning: