SIEM Sales Engineer Top 5 Trial Tips

In my role as an SE there are many challenges during the sales cycle that need to be addressed and I have had my share of dents and bruises because I didn’t adhere to any part of the 5 tips I’ve detailed below. These are my top 5 tips that have been instrumental in making trials run smoothly:

Scoping: Winston Churchill once said “Let our advance worrying become advance thinking and planning”. Too often in my early days as an SE would I anticipate all that could go wrong on a trial because I didn’t have enough experience with what could go “right”. Once you have a few successful trials under your belt you begin to see the trends and tasks that are most effective.
One of the best tools in preparation for any product trial is the Proof of Concept (POC) scoping call. Arrange a quick conference call with your prospect and ask them to extend the meeting to all of the various technology and security stake-holders in their organization. During the call, establish the duration, shipping addresses for equipment, contacts, event sources,  success criteria, use cases, custom content, etc. My company has actually devised a POC scoping document that must be filled out before any equipment gets shipped to the prospect and anyone books their travel.
Finally, you have to accommodate for scope creep and the best way to do this is to limit the scope up front. You will have a lot on your plate, especially if it’s only a 5 day POC. Then, while you are on site during the trial you are going to create excitement about your product (if everything goes as planned).

Come Prepared: Not only does this include printing out the POC scoping document, configuration guides and address/contact for the site, but this also includes any work you can get done prior to the trial. Some such tasks are; map out each of the use cases and how you plan on satisfying the criteria; If there are custom rules, reports and dashboards, use demo events to pre-create this on your laptop to minimize how much effort you’ll spend on developing this in front of the customer (risking how complex the product is to use).
There are many other preparation steps including: building the necessary integration into unsupported event sources and; scheduling other teams for a WebEx session during the POC to speak about product roadmaps, customer support, customer success, advanced use cases, to name a few.

Ask For Help: This point lends itself to the “preparation” phase, whereby you may discover during the scoping exercise that there is a difficult event source to connect to or use cases that you don’t have the first clue on how to address. Reach out to the SE thread by email or call other SEs direct who may be senior and may have encountered this complexity in the past. At the very least, request assistance from the product support team and perhaps schedule either onsite or remote assistance during the POC so that the issues can be addressed with some extra hand-holding. In some instances, speaking with the prospect and suggesting alternatives may be the answer. This job is about being abreast of all sorts of technology and you must be humble and resourceful to be successful.

Be a Consultant: We are not just representing the product sales team in our roll. We are teachers, mentors, architects, IT specialists, project managers, to name a few of the required roles during a POC. We must advocate the value proposition as well as provide guidance of how our system is going to retrofit into an existing enterprise environment. Schedule planning sessions with the architecture, security planning and compliance teams during the POC to whiteboard the proposed design and capture as much data as possible. Share planning questionnaires, proposed diagrams, key differentiators, use case matrixes, product installation documents and anything else you feel would benefit the prospect in determining that you are an authority on Log Management and SIEM technology. We are the authority on SIEM and we are not just there to let the prospect put our feet to the fire and satisfy use cases – we are their to inform them on making the right decision.

Share the Wealth: The final point here is one of the most overlooked aspects amongst SEs and is instrumental in your development. Great responsibility comes with being a specialist in your profession. Whether you’ve created custom content or worked day and night fixing a problem, you need to share this with other SEs. Beyond the obvious point of helping your colleagues be successful is the paradox “you can’t keep it unless you give it away”. What this means is that some of the most complex concepts need to be articulated for you, yourself, to truly understand how they work. When sharing content or templates you’ve created it forces you to figure out how to deliver your ideas in a way that can be easily digested by your peers. The more you do it, the more you will master your profession.

    These tips are by no means the silver bullet for being successful during trials but they have worked for me and as you can tell, the center around being prepared and having all of the facts.

    Good luck and happy selling!

    Gary Freeman


    Getting them to drink the Kool-aid…

    I have to say that one of the most incredible feelings is walking away from a demo or presentation knowing that the audience got what our product does and how flexible it is to deploy. I just get a rush when technical folks start drinking the kool-aid and ask questions or regurgitate our product’ terminology. Even better is one of your prospects has done their homework and starts advocating the benefits or the value proposition to their own colleagues!

    I work with a product that is a niche product that is both software and hardware and has many flexible options. The sky’s the limit and when a serious prospect starts formulating how our solution will retro-fit their environment and helps you map out the architecture before the meeting is finished, you know there’s no denying the fact they are onboard and ready to get their hands dirty with your product.

    In one such engagement recently, I walked into the room, one immediate credibility with the tech team as had been on the other side of the table with the same pains before doing a Sales Engineering role. I opted not to do “death-by-PowerPoint” and went straight to the white board and started mapping out their requirements and architecture while explaining the product and features at each tier of the design. Customers respond well to a reference architecture as it provides a mapping to their existing infrastructure and allows them to absorb your infiltration of product knowledge in digestible chunks.

    Some of the things I do to engage them are:

    • Ask them tons of questions about thier pain and what they are doing to deal with the problems today
    • Let them come up to the whiteboard and draw their architecture
    • Build trust with the technical folks but also try to deliver the techno babble to the middle ground (there are always non-tech people present who’ll get bored if you don’t engage them)
    • Offer to give them whitepapers, admin guides, specs, etc – techies love to read!
    • Let them take you off script and drive the demo (show them what they want to see)
    • Manage difficult questions by qualifying the purpose for knowing the answer

    Being an SE lets me sell, train, demostrate, propose, design and essentially talk people into buying a solution to suit their needs, but the job is so much easier when I’ve established a repore with the right people.