What is your product and what does it do?

Lessons I learned trying to make the most of vendor briefings

I’ve always been a sort of ‘cut-to-the-chase’ kind of guy. I’m self-taught when it comes to security and technology. Over the years, I’ve learned how to skim through a book, article or website to extract the important information. Sometimes I’m just trying to figure out how to do something, or I’m looking for an answer to a specific question.

Just tell me what time it is, I don’t need to know how atomic time clock frequency standards work.

Conversely, I also have an appreciation for context and a good story — as long as you eventually get to the point.

Anatomy of a Vendor Briefing

Here’s how the average vendor briefing usually goes.

The WebEx Tax (5min)

Waiting for everyone to join, restarting WebEx or some other screen-sharing app because it’s misbehaving. Chit-chat about weather and where everyone is physically based, or happens to be at the moment. I quickly communicate that attempts to talk sports are wasted on me — I just don’t follow them anymore.

Introductions (5min)

These are important — I want to understand who I’m talking to. I want to know whether or not I can ask technical questions. I want to understand the backgrounds of who is on the phone.

About the company (5min)

How is the company doing? How did it start? Where is it located? How many employees? Is it growing? What about that lawsuit? Who are its customers? What company size/verticals are being targeted?

The Problem Statement (10min+)

This is where about half of vendors start to lose me. Typically, I’m talking to a vendor in a space that I cover closely and have covered for years. I’ve probably written about this space, given talks about it and discussed it at length… well, you get the idea. This is also where platitudes and hyperbole start to roll out. Silver bullets and ‘one weird trick’ to fix security! Most of these meetings are occurring over the phone without video, so the vendor may not hear the sound of my eyeballs violently rolling back.

On the other hand, I do want to hear the problem statement from the vendor, provided it is concise. The problem statement helps me understand how the vendor sees their market and their place in that market. Sure, I understand it, but I want to see it through the vendor’s eyes. In some cases, the problem statement reveals an outdated or artificial view (in my opinion), but in others, it offers insights or perspectives I hadn’t considered before.

Recommendations:

• Ask the analyst a few questions to gauge their familiarity with the state of security in this particular market segment.
• Be concise — briefing an analyst isn’t the same as talking to a sales lead.

The Product (10min+)

This is the most important section, especially in security, where the variety of products and technologies combined with the prevalence of buzzwords can result in some very confusing messaging.

WHAT’S IN THE BOX?!

Recommendations:

• Please start this with an architecture slide. Too often, I find myself wondering throughout this portion what the product actually is. I’m hearing about features and functionality, but I don’t know if it’s SaaS, a hardware appliance I rack in my datacenter, a VM I download and deploy, a managed service… This is important context to have for the rest of the conversation!
• Lay out all your products and services, even if you’re only focusing on one in this call — this also helps to give important context.
• Mention partners and integrations — few security products these days can survive long without integrating into the customer’s existing environment. I want to understand where you overlap, where you replace and where you complement.

Roadmap, competition, future of the market (remainder)

Most of security is a missing feature market, so chances are good that your product may not be long for this world. How are you going to handle that? Especially for startups — if you’re counting on an acquisition exit, how do you ensure you’ll have a seat when the music stops?

The next meeting

If this one went well, I might be interested to see a demo or speak with a customer. Sometimes I want to see a demo because I’m excited or skeptical. Demos are typically easier to keep to 30 minutes because the meeting will be focused just on a screenshare and walk-through of the product.

Other Recommendations

Briefing Length

I find I really need an hour for a briefing. 30 minutes usually ends up feeling rushed.

Analysts are not Sales Leads

When talking to an analyst, your goal isn’t to convince them to buy your product. Instead, you want them to understand your company, products and goals. Make the analyst understand why different customers would want to buy the product and the different approaches that get the customer to sign a PO.

Ideally, you want to make a fan out of an analyst. An analyst that casually or actively mentions your company or product is a huge win. Everyone wants word-of-mouth marketing, but analysts tend to have ‘bigger mouths’ and more influence. Help the analyst understand:

• What you do
• Why you do it
• Your target market
• Market differentiation
• Use cases
• Roadmap and long-term goals

Have a purpose

You sell encryption? That’s great, but how’s it different from the other encryption? Why would I go with yours over another? Do you compete entirely on price and features, or do you have a deeper story and purpose that draw customers in and make them want to be loyal to you?

Buzzwords

Don’t use them unless it’s efficient to do so. For example, if your product is EDR, just say you play in the EDR space. If it’s EDR plus some innovation, don’t avoid the EDR term because you don’t want to be ‘pigeonholed’ with your competitors. It just ends up being confusing.

I remember the first time I talked to FireEye. And the second. And the third. Each time, the sales person described the product (the NX appliance was the only product at this time), and it came off sounding like an IDS/IPS. They ensured me that it wasn’t an IDS/IPS and proceeded to use the same words to describe it again. It wasn’t until I got an engineer on the phone for that fourth call that I was finally able to understand what the product did.

Call a spade a spade — not a next-gen superior triangular manual digging tool. You can even call it an awesome spade if you think it’s awesome, just use words a normal person would understand.

Clarify B2B relationships

DON’T use the terms integrate, partner and alliance interchangeably. They have different meanings.

Integration: “We did some work, they didn’t have to do anything. In fact, we didn’t even really talk to them — we’re just ingesting their API/feed.”

Partnership: “We got together, talked about it, and each of us built pieces that work together in some way.”

Alliance: “We got together and built something entirely new”

Additional DOs and DON’Ts

Do

• Go over the agenda for the call and set expectations right at the start. If I’m expecting a demo and there’s no one on the call that can give a demo, I’m going to be disappointed.
• Use specific examples or anonymous customer examples
• Walk through demos
• Give me access to the product, if this can be done easily
• Give your pitch to an engineer/product manager to ensure you’re explaining it correctly — nothing’s worse than being contradicted by an engineer during a briefing. We’re going to second guess everything else you’ve said.
• Suppress toaster popups during a screenshare. Or don’t. Sometimes the content of your IMs and Emails is VERY revealing. More revealing than your General Councel would be comfortable with.
• Share your presentations beforehand. I can ask better questions if I know what we’re going to cover. Also, because WebEx WILL fail you.
• Learn how to use the screenshare app and/or Powerpoint before the call. I’m frequently amazed at how many people don’t know how to get Powerpoint full-screen.
• Go over product naming/branding — I’m also amazed at the number of vendors that never even tell you what product they’re talking about and don’t reference it in the slides.
• Tell me how it is priced, sold and licensed.
• Tell me cool customer stories

Don’t

• Rely on an engineer to explain things — if the marketing/sales guy can’t explain it or doesn’t understand it, you’re not ready to brief an analyst.
• BAD: “I’ll have to check with one of our engineers on that”
• WORSE: The engineer is on the call and confuses the situation more.
• Badmouth competitors — there’s just no excuse for that. If you think you do something better or have an advantage, fine — tell me that. But don’t start telling me how much more effective your product is unless you’ve got some data from a study that I can review. And no, a Ponemon PDF is not “data from a study”.
• Make fun of other products — I’ve found this usually backfires. In almost every case I’ve seen a vendor do this, the flaw they’re pointing out exists in their own product as well.
• Example: a security awareness vendor was campaigning a piece on “AV’s Dirty Little Secret”, which turned out to be that AV wasn’t 100% effective. No shit! What’s the effectiveness of security awareness tools again?
• Make me fill out a form on your website to get basic details about your products. Often, to fill gaps in the briefing, I’ll go to the website to fill in the details. Maybe I forgot to ask what platforms the product is compatible with, or when the company was founded. Please don’t make it hard to find this information. If you put me in a position where I have to endure sales calls in exchange for basic information, I will hate you.
• Expect me to be impressed about your lightweight agent, CISO dashboard or the founder’s time in Unit 8200.

Suggestions for the Analyst

• Explain how your firm works — if briefings rarely result in coverage, let them know ASAP, because that’s typically not the norm (or so I’ve been told). What interactions are paid vs free? How are meetings scheduled?
• Manage expectations before the call — what are you looking to get out of it? That will impact who the vendor needs to schedule for the call, what materials need to be prepped or how long the call needs to be.
• Stop the presenter if they’re going into stuff that isn’t a good use of your time. Redirect the conversation down a more productive path.
• Stop the presenter if you don’t understand something. Don’t just nod and let them continue. Don’t be afraid of feeling dumb. When I started as an analyst, I had never heard “north-south” or “east-west” used to refer to network traffic flow before. Just a few months ago, I found the definition for “east-west” was contentious when I thought it was more straight-forward.