What can you (SE’s) stop doing in the new year?


If you’ve seen one too many posts on resolutions for the coming year like I have, I’m sure the last thing you want to see is another list of things to add to your growing stack of todo’s. So I wanted to take the opposite frame and list out some things you can safely stop doing to gain some much needed time back to focus on things you want to start doing.

In no particular order:

  • No first discussion calls – Stop attending calls where it’s the first interaction your sales team has had with a prospect. If your rep or inside guy hasn’t spent at least 20 minutes gathering basic qualification information, don’t get on the phone
  • No RFP responses! – UNLESS you helped create it with the prospect in the first place
  • No support calls – Spending time on support calls with existing customers is not the best use of your time
  • No unqualified demos – If the prospect won’t agree to a brief needs analysis call prior, they are sent to your weekly webinar and not a 1:1 demo. Don’t have one? Create it.
  • Stop writing redundant emails – Take the time to create exceptional email templates
  • Stop responding to after-hours emails – Unless a customer’s systems are down, it can wait until morning
  • No agenda, no meeting – If that internal meeting has no detailed agenda which involves you personally, skip it. Some companies like Apple, Google, and Visa have mandated this company-wide
  • No defined budget, no POC – Unless there is a specific budget amount the prospect has assigned to your project and you know what it is, do not proceed with a POC
  • No buying criteria, no POC – If the prospect won’t work with you to define their buying criteria, do not proceed with a POC
  • Forget the roadmap – Stop worrying about where your product is going outside of some high level objectives. Instead, use roadmap questions as an opportunity to bring product managers in to qualified opportunities

While there are exceptions to any rule, the benefit of this type of review is to see how far you can push these principles in your own situation to free up time for more productive activities.

As an aside, this will be one of the last posts on The Sales Engineer. There are many developments afoot, so look forward to an announcement next month on newer and bigger things. I wish everyone a very happy and prosperous FY17!


Creating Situational Awareness in the Technical Sales Process

I recently came across this blog from Gartner Group’s Hank Barnes on the subject of creating situational awareness inside the sales organization. This plainly has a direct corollary inside the SE organization so I thought it would be good to think about how we could apply that to our own deals.

In order to keep this a manageable amount of information, I decided to list out the top three questions to ask yourself for each step in the technical sales cycle.


  • What are the top three most important data points you need to qualify a customer? Some customers may be very open and willing to describe all aspects of their pain points and buying process, others will hold that information very close to the vest. Try having a question or two at the front end of your 1st meeting to determine how much information you can obtain. Something like “Can you tell me about how you’ve been accomplishing xyz today?” If you get a great response, perhaps you continue with a few more well rehearsed questions.
  • How can I incorporate qualifying questions into my pitch? If and when you meet the brick wall, go into your material, but have strategic checkpoints during your pitch where you may be able to pull out some related qualification material. For example, if you’re talking about network architecture or sizing, a question about how many potential users they would have seems like a very appropriate question to ask, and one that would likely be answered in that context.
  • What are the top three red flags that you could help uncover during your first meeting? Is there a specific use case you’re weak at or is a key buying center not represented? Figure out what these are ahead of time and make sure you’re seeking these out immediately.


  • Would slideware or a whiteboard be more effective? Most customers do not mind slideware as long as it’s interesting. Others are put off by the very nature of slide- based presentation. Think about asking the question before you delve into presentation: “I have some slides that are already complete that I can put up to talk through, or we could take a bit longer and do a whiteboard session that would be more specific to your organization, do you have a preference?”
  • Who in this meeting am I addressing the most? The least? Asked another way, you’re simply prioritizing attendees and the specific content likely to be most important to them.
  • What objections do I need to spend time addressing right now and which ones should be dealt with offline? There are likely certain aspects to your product that come up repeatably as objections. Determine which ones are most important to your prospect and which ones are tangential that can be safely taken offline.


  • What are the three most interesting elements to this prospect I need to ensure are included? Make sure you’re showing the most relevant aspect up front (ala Great Demo!)
  • Do you have the minimum necessary information required to provide a customized demo? If not, make sure you ask those final questions up front before you begin.
  • What are you closing for? Sometimes multiple demonstrations are required. Oftentimes the POC is the next logical step. In others, a reference sale may be appropriate. Understand what you’re closing for so that 1) you cover just enough ground to set yourself up nicely, and 2) you incorporate your close as part of demo meeting.

Proof of Concepts

  • What other solutions are going to POC? Competitive angles can be used throughout the sales process of course, but at this stage it is imperative you factor this into planning. This influences the testing below.
  • What are the pertinent use cases for my prospects business pain point? Rarely does a prospect really need all that product does (or every feature within it). For each POC at least have a mental list of what is needed to cover. Leave out everything else to avoid scope creep.
  • What test cases accurately demonstrate the use cases? An important component of every POC is figuring out how you recommend a prospect test out a particular use case. I say recommend because a prospect may have their own plan, which is fine, but you should always try to influence this. It will save both of you a lot of time and effort.

Are there others you’d recommend for this list? Comments here.

500 Connections and a Picture, period.

used-car-salesmanI came across this article a few weeks back and it got me thinking about how SEs leverage (or don’t leverage) social media. I’m pretty sure that just about every SE in the world uses LinkedIn, even if it’s just to find out a bit of background about a company before a meeting.

But I know from experience that there is a significant portion–maybe 20% or more–that don’t actively manage their own profiles. The minimum bar for all the reasons mentioned in Keenan’s post are: actively connecting to people, keeping your job history up-to-date, and (yes) a picture.

If you are a librarian or an accountant for example, I don’t see you needing to spend as much effort building an online presence. But, to be frank, if your resume comes across my desk for an SE (read: sales) position, and you don’t have a picture and have only 80 connections, what am I supposed to think about your abilities to represent our company in the best possible light?

And I would argue the above criteria are the absolute minimum bar. As presales we have several possibilities to help build credibility in the minds of both potential employers and our customers:

  • Writing on sales-related topics
  • Writing on technical-related topics
  • Sharing industry news and events
  • Contributing to group discussions
  • Re-sharing company announcements (do this sparingly and only on valuable content)
  • Filling out your accomplishments (certs, technical competencies, courses you’ve completed, etc.)

I generally don’t need a reminder to do this as I’m frequently on LinkedIn and other services for daily business, but if you have a hard time incorporating these into your schedule, put something on your calendar like Friday early afternoon when you typically have office time to spend 20 minutes contributing content.

Some groups to help get you started:

  • Sales Engineering Professionals – https://www.linkedin.com/groups?gid=160398&goback=&trk=prof-groups-membership-name
  • Engineers in Sales – https://www.linkedin.com/groups?gid=2331982
  • Sales Best Practices – https://www.linkedin.com/groups?gid=35771
  • Presales Professionals – https://www.linkedin.com/groups?gid=64542
  • SE Certification – https://www.linkedin.com/groups?gid=3296013
  • Technical Sales Group – https://www.linkedin.com/groups?gid=81075

Comments here.

Just, Why… People?

cartoon5929Have you ever had that annoying conversation with someone where it took you having to ask several questions before you could get a simple explanation as to “why”? Those who are around young kids a lot are usually on the other end of that conversation with a seemingly endless stream of “why’s” when trying to communicate. As SE’s our primary job function is to communicate information to others. We all tend to be pretty good at telling customers the who, when, what, how of the problem or solution, but far fewer of us are adept at the why portion. And as you probably already intuitively know, the why is often the most interesting element of communication.

Let’s look at three examples to understand to see what I mean.

Why do I need this solution?

A common trap for seasoned SEs is that they understand the problem so well that they instinctively think the customer understands the problem as well as they do. So they “don’t waste the customers time” and instead jump into the product. The customer, happy to just get to the technical “meat” of the meeting, responds favorably, and no one thinks to probe deeper to really uncover all of the use cases and intricacies of the customer’s business processes and situation.

The problem isn’t that customers are unwilling to have a discussion around the business problem, it’s that you (or rep) aren’t challenging the customer’s assumptions. And if you aren’t challenging assumptions, they really aren’t learning anything about their business or trade. And when that happens, your only value is your knowledge about the product. Instead, your job is to know much more about your niche than your customer, and thus you should be in a position to coach. This should be self evident in the fact that you work on solving this one problem all day long over and over with other customers. There is no way your customer will be able to match that depth nor should they. Tell them why your other customers found your solution so uniquely compelling.

Why doesn’t the product do xyz?

I always love the opportunity to bring product management into my meetings. I always learn something new I didn’t know. Most people believe their greatest power lies in their intimate product knowledge or in their control over the roadmap.

I disagree.

The two things they can do better than I can do as an SE is demonstrate a knowledge of the market as a whole. They work daily to out-strategize the competition. And because of this knowledge, they are in the best position out of anyone to understand why a product functions the way it does, or why a particular trade-off was made. So whereas I might have to tap dance around why we don’t support that database version, they can tell the customer the reason we don’t support it is because they decided to prioritize this big feature that these large customers of ours were really pushing for which should help other customers as well. Customers get angry when your company makes seemingly stupid technology decisions. When you have someone that can illuminate the bigger picture on which that decision was made, the customer usually comes to the same conclusion as the product manager, realizes it was a smart move, which actually increases the confidence the customer has in our team and solution. Your job as an SE is to pick up as many of these anecdotes as possible and have them ready around your product rough spots.

Why am I experiencing this issue?

This question has caused me some grief as I’ve been working with startups for quite some time. Where I get into trouble is when I’m going through a POC and I encounter a bug–especially if it is clearly something that should have been caught in QA. Sometimes I will get a support answer back akin to “we are aware of the issue and it will be fixed in the next release”. If you would pass along an answer like that to a customer, then please let me know if you’re looking for a job and I’ll connect you with my competition.

If you’re a customer and you hear something like that, wouldn’t you think something like:

  • They must not have very good QA
  • They must not have any customers using this thing
  • I’m testing their beta code for them

So when I get an answer like that from support, I tend to drive them crazy getting to the why: Oh, so this customer is getting a conflict with this driver that is really old and only present in a minute portion of our install base and we caught it while beta testing with one of our large customers and we just posted it to knowledge base yesterday? That’s what I can communicate to my customer to ensure they maintain confidence in our release process.

I’m sure there are many more variations on this theme and I am just scratching the surface. The takeaway here is to act like seasoned parents do and provide the “why” before the child (or customer =) has the chance to ask.

Comments here.

Don’t Be This Guy


Click for larger image

While I have gone through a fairly rigorous set of writing/grammar classes in the past, I don’t consider myself a grammar nazi. Those who live in glass houses and all…

But there is a definite time and place to ensure that your communications (both verbal and non) are crisp and as perfected as possible. When I was just getting started in my professional career I would sluff off comments that a slide or email communication had some spelling or grammar errors. After all, when I sat through presentations they didn’t bother me at all.

As you meet with more and more customers you will eventually come to realize that there are those that 1) notice, and 2) care a lot about these things. Even folks like myself that are pretty lax start to raise an eyebrow if there are more than a couple errors in a slide deck.

And there is one group/situation in particular that should be hyper sensitive to accurate communications: managers and those helping screen applicants for job hires.

Enter: This Guy


Normally I don’t like to pick on individuals for posts, but if there was EVER a time to use proper language, it would be from someone asking for a job contact. Recruiters/HR are paid to find reasons not to send your resume along. Don’t make it easy for them!

What we should all take from examples like this is that people perceive us by the words we use and how we use them. Take the time to scrub your presentations, or better yet have a fresh set of eyes do it. Take the time to reread that important email a few times to make sure it’s perfect. Take the time to rehearse the beginning and ending of that important presentation. And, most importantly, be extra diligent when communicating with anyone who may have a say on whether you’re hired.

Comments here.

Death By Committee

committee-meetingMaybe it’s just me, but it seems like more and more product/buying decisions are being delegated to large cross functional groups or formal committee’s. Now, this is likely due to procurement changes that have been implemented post recession. But selling to groups presents a unique challenge to sales teams and SEs that require special considerations. I personally dislike this scenario, but here we are.

I dislike the scenario because I believe that relying on a committee is an overly conservative approach that, in aggregate, greatly slows innovation in all departments–but decidedly so in R&D and IT organizations. From an SE perspective, it makes the job of determining the highest priority business problems and technical drivers difficult, as opinions within the group will vary greatly.

When you have a key decision maker or technical evaluator, you can focus–laserlike–on only the important use cases. Conversely, every member of a committee will have their pet criteria, and ignoring any of them may loose you votes, even if they don’t align to the broader organizational goals.

To net this out: You always had groups involved in the buying decision, but now each of those members has a direct vote.

This makes it critical that we’re on our game in terms of our fundamental ability to navigate these political waters. In a recent discussion with some reps, here is what we came up with for some good tactics to implement. These can be used on every opp, but are especially valuable when you’re selling into a Fortune 500, Govt, or committee-based buying center:- In every meeting, especially those with many participants, take the time to get everone’s name, organizational affilitation, and role

  • If you know a meeting will be large ahead of time, schedule in 10 minutes to make sure both sides understand proper introductions are part of the agenda. If you don’t, you risk alienating participants
  • Follow up after the fact with each committee member to “make sure you had a chance to answer all of their questions and understand his/her particular criteria–given the short amount of time on the initial call”. Your goal is to treat this person with the same attention as the committee chair or reporting director. Too often, certain group members are ignored by Sales because they didn’t speak up much in the meeting to command their attention. It would be our mistake to assume these members didn’t have something unique they brought to the equation.
  • Learn who each committee member will leverage or consult in formulating their opinion. Often, it will be 1-2 folks who aren’t on the committee themselves
  • Determine the pecking order of the committee. You can’t spend equal time with everybody, so make sure you are directing your communication efforts to those in the best position to act on them. I’m not a fan of playing politics because of its propensity to backfire, but not understanding political realities is also equally detrimental
  • Arm your supporters with inside information. Use private information such as non-published technical collateral, competitive writeups, and most importantly insider industry data affecting your market. Coach your supporters on how to get the most out of this. Example, if a top notch think tank publishes insights on your market that puts you in a favorable light, that committee member should be distributing that to the whole group as though they found it. Essentially you’re helping them build credibility for their opinions they can tap later

You and your rep should each be aware of these factors and tactics and discuss the game plan to execute. As the SE, you should be focused on understanding the specific committee members who the others will likely turn to for technical validation or leadership. You should also be making the followup calls to those members as well as the confidants the members will turn to for validation. You should also be sending (or suggesting) that specific collateral and resources get sent to specific individuals as you uncover more information about the committee dynamics.

SE Managers: Consult with marketing so that the whole sales team is receiving (and can contribute to) a running list of indistry validation articles that they can send out to prospects as needed. Unless you’re at a bigger firm with depth in technical product marketing, SEs will need to pitch in and help curate this content.

Other suggestions? Comment here.

Why Google Sucks

googleWhen I first got started in this business you really had to know your stuff cold. That meant that you couldn’t rely on every possible answer to a technical question being just a Google search away. I was, just like our customers, forced to memorize a lot of pedantic technical data.

I recognize this has a sort of “get off my lawn” sort of overtone. But you know what, I’m really glad in a way. Today, it’s all too easy to rely on the Internet Crutch to answer our questions on demand. Temptation is everywhere, and for up-and-comers to high technology this represents a real problem.

This problem is especially pronounced for SEs. You only get a few hall passes per meeting where you can answer “I don’t know, let me get back to you on that” before your credibility is damaged. There is palpable pressure to know it all without coming across as a know-it-all. I think I can help you with the first part.

I recently found myself involved in a similar version of this conversation with a colleague for the nth time. It seems to come up A LOT. Every time I find myself making a similar recommendation, and goes something like:

“There’s a book I read a while ago–actually a gift from a family member–that had a really great impact on my ability to remember and recall all sorts of information I find important, especially names, acronyms, and technical data.”

At this point folks get pretty interested, mainly because I think it’s a very universal skill we all wish we were better at. The book is Moonwalking with Einstein: The Art and Science of Remembering Everything. It recounts the author’s journey from covering the World memory Championship as a journalist through his experiences becoming a participant.

It is beyond this article to cover all of the techniques discussed, but suffice it to say it spawned my reading of several other books on memory development. The key takeaway: Memorization is skill like anything else, nothing more–the implication being that anyone can learn to have a fantastic memory. It may not help you remember where you parked your car at the airport, but if you want to learn the name of all the countries of the world or remember those OSI layers, this is the place to start.

So the next time you catch a colleague trying to justify why they didn’t memorize something (instead preferring to “Google-it” as needed), please send this link, they’ll be glad you did.

Comments here.