August 8, 2014
Heroku has had hellish periods of downtime resulting in Quality-of-Service numbers that staff and customers alike were frustrated with. Hear...
There are a few myths about sales that really stand in the way of developers and entrepreneurs from really being successful in the early stages of their company that I'm here to dismiss.
The first one is that great salespeople are born. I can tell you for starters that is absolutely wrong. The other myth is that one of your first hires needs to be a salesperson because they know what to do and you don't. Also, a big myth. The third myth is that technical people, specifically developers, cannot be sold to. I'm in developer services. I suspect many of you are in developer services. I can also tell you that is also patently untrue.
My goal today is, though there are many parts of a sales process, I'm going to walk you through one of the core parts of everybody's sales ability which is the sales call itself. What do you do when you're talking to a customer? I'll give you a smattering of all the other parts of sales, if time permitting.
So who am I? I'm Alex Salazar. I'm the CEO and one of the co-founders of Stormpath. My background prior to Stormpath was in sales. I was an IBM sales executive for many years. My last role there I carried a 30 million a year quota for large enterprises in New York. In my career I have sold over 200 million dollars worth of software and services.
I'm also a former software developer. In fact, my co-founder and I met when we were the founding engineering team for a SaaS startup back in the day, many moons ago. Prior to that he and I were also students in computer science at Georgia Tech. For posterity, I also have an MBA from Stanford which makes me sound great, but it actually is irrelevant for this presentation.
About Stormpath, like many of you we are a developer services company. We provide a user management and authentication service for developers. We provide password security. We provide authentication. We provide access control via permissions and groups. We also take care of things like LDAP synchronization for larger enterprise-type workloads.
The value prop of our product is the fact that we're like you guys â€” instant-on, scalable, and highly available. And like many of you we are free for developers.
I not only give this to make a plug for my company, but to give you context of what we do because as I take you through the mechanics of a sales call, I'm going to be using our company and what the typical conversations we have with our customers as an example of the things I'm going to cover.
The things we're going to cover today are really taking you through a normal sales call with a customer. I'm going to take you through what the buying steps typically are for a customer and what the compliment sales steps are for most vendors.
When we go into the sales call, I'm going to take you through what preparation for a sales call looks like, how to open a sales call, what do you do when you're in the sales call, and then handling objections because most customers have them and handling them is really where you generate the most value for your customers. Then time permitting, we'll actually try and go through a very interactive session. We'll see if time permits.
First let's talk about the steps that people go through when they buy. If anybody's ever had a really bad experience with a sales guy, maybe you were purchasing a car or you went to go buy a pair of shoes and you just couldn't stand the sales guy you were working with. If you really try and analyze why you didn't like the guy it's almost always because they were trying to sell you at a different stage than you were at.
Think if you were trying to buy a pair of shoes. You didn't even know what pair of shoes you want. The sales guy is trying to get you to buy this pair of shoes. Or you go into a car dealership and you're really just there to test drive to see what you like, and the guy doesn't want you to leave the dealership until you've signed a contract. What's happening there is a mismatch in what you're trying to do and what he's trying to do.
Great sales, where your customer actually enjoys working with you, is when you are aligned.
When they're trying to figure out what their needs are, you're trying to figure out what their needs are. When they're trying to figure out what solutions fit those needs, you're presenting your solution. When they've whittled down to a set of one or two vendors that might be the solution, you're there trying to help them get over the hump and decide to use your product. Once they've decided to use your product at that point is when you start going into heavy negotiation around price and delivery dates and things like that.
If you're not aligned with them, customers find a way of no longer working with you. They might buy the product once or twice, but they might not come back for more.
In developer services one of the things that is really disruptive compared to traditional software vendors is that a lot of this tends to be happening self-service. Developers don't like cold calls. They're not going to take a meeting with you just because you found their email address and sent them an email. They will take a sales call, but only after they've seen the product or maybe only after they've been introduced to you via somebody or they saw a nice blog article.
There is still a sales call aspect to this stuff, especially for larger customers who are unlikely to self-service all the way through to a large transaction. In the developer services world you still can't get away from this stuff. What happens in a sales call? What happens when GE contacts you and they want to have a conversation about your service. First step is, there's preparation. Then you actually have to open the call. And you actually have to understand, do they actually need your product and why? Because if they don't, there's no point in continuing the conversation.
Then assuming that there is enough to continue, there is some sort of proposal. Whether it be to purchase your product or continue the conversation or make an introduction to somebody more important in the organization. Then there's finally, actually closing the call in an appropriate way where everybody knows what's going to happen next and you have the commitment to achieve whatever the next step is and whatever the company's process.
Then throughout every single sales call I've ever been in there are always objections. Customers will bring up all kinds of reasons why your product may not be a fit. It actually is always a good thing when you get objections. In fact, the worse sales call you can be on is one where you don't get any objections because it means the customer is not even taking you seriously.
Objections are a way of a customer prodding to see if they understand what you're doing. How you handle them is really where the difference between a good salesperson and a great salesperson lays.
There's actually a lot of data around that. I think Harvard Business School did a landscape study of different sales reps to see what made great high performing sales reps different from mediocre reps. Across the board the only thing that had any real correlation was their ability to handle objections.
We'll start with preparing for a call. ESPN(dot)com signs up for your service online, and everybody goes crazy in your office. Your marketing person reaches out to ESPN to figure out what they want and trying to get a call to get feedback or something. They respond and say "Yeah, actually we'd love to talk to you." Well, you've got a sales call on your hands.
What I've seen and I've seen this across the board, when I had my own reps at IBM I saw this as well, a lot of people will just go in cold. They'll schedule the meeting. It will be on their calendar. They won't even really stop and think about what's going to happen until they walk into the meeting. Then they walk in and the meeting is a dud.
Preparation is incredibly powerful.
When you're preparing there are a few things you want to do. The first thing is try and understand your customer. Not all customers are going to be big brands that you already know everything about. It might be a company you've never heard of. Go research them. Go on their Website. Figure out what their product is, what's the industry they're in. How do you think you might fit into their product?
Email them beforehand and ask them questions. "I'd love to meet with you tomorrow. Can you please give me a little bit of background on what you're thinking?" The more preparation you have going into that call, the more likely you are to hit on a hot button issue that's going to really drive the engagement with them. The more likely you are to make them feel that you're not wasting their time and the more efficient you're going to be with that call because a customer call is roughly, honestly, only about 20 minutes.
Getting more than 20 minutes of a customer's time is really hard and that's including the banter at the beginning and the end, the questions, the scheduling snafus. If you can't get everything you need in 20 minutes it's actually really hard to get that second meeting because customers don't want their time wasted.
In addition to preparing yourself for this call from a research perspective you also want to figure out what you want out of it. What's the goal of the call? If you're talking to a customer for the very first time, are you going to try and close them on that one call? Really unlikely, especially if you're selling to larger organizations.
The objective might be to get an introduction to the person who actually gets to make the decision as to whether or not your APS service will get used or not. Maybe it's an architect. Maybe it's a product manager. Maybe it's a CEO or CTO. Maybe it's to schedule a time to bring the whole team in for a demo or vice versa, you go there for a demo. Maybe it's just to continue talking because you only scratched the surface of the technical problem that they're having.
Knowing what the set of objectives are is really powerful because it allows you to focus the conversation and keep it from going off on tangents.
To that end try and think through what the tangents are that your customer might jump off on, and have a plan for bringing them back in on the path of what you're trying to achieve based on what you think they're trying to do.
Also, what are the objections they're going to run into? If you've talked to customers more than once you already have a sense for what these objections are going to be. The tried and true objection is, 'It's too expensive.' So have an objection response ready for 'it's too expensive' or anything that's related to your product: "I found a Ruby library that already does this stuff."
Having those kinds of objections already pre-handled in your head will make the call go a lot smoother and will let you get more out of it.
The other thing is now you open the call, so now you're with the customer. Actually, I'll take a break really quick and talk about what happens before the opening of the call. I've seen a lot of professional sales reps, guys who do this for a living, who really believe that they need to build a relationship with the customer. I'm a firm believer of customer relationships, but they think that they're going to build a relationship with a customer at the very beginning of the sales process. I actually think that is disingenuous.
I'm actually not a big believer in the witty banter before the sales call to ask them like what they did for the weekend and did they watch the Niners game. Most professional customers know better. They've dealt with Oracle, they've dealt with HP; they're allergic to that stuff.
I find that just being forthright, being straightforward and getting to the point is really appreciated because everyone's busy and so are you.
And if there is a real business relationship to be had, there will be many opportunities for you to build a relationship with them that are about the Niners game and what they did for the weekend. But it will be a lot more natural once there are now the beginnings of a real relationship.
I'm actually an opponent of opening a call with banter. I prefer to open a call professionally. The way you do that is one, you look professional. Now, what "looking professional" really looks like really depends on who your customer is. Walking into Twitter's offices in a suit and tie is an easy way of getting laughed at and is not going to win you any points. But walking into any office on Wall Street with a T-shirt on with your company logo on it is an easy way of never getting called back.
Being really sensitive to what your customer's business is, what their culture is, what their expectation of a dress code is and trying to mirror that for the purposes of the sales call is really, really powerful.
Off the record ask me a question about this and I'll actually give you a strong example of the way I learned this the hard way.
Also, the sales call is never an absolute thing that happens on its own. There's a lot of conversations beforehand, there are a lot of conversations that happen afterwards. One of the best things you can do to prepare is to present yourself professionally before the sales meeting. When your customer is trying to communicate with you for scheduling or they're asking for docs or they're asking for any kind of particular data, you're responsive.
You're showing that you are a professional organization and they can trust you. When you walk into that call, you're walking in with a good impression, not a bad impression.
Also, state your intentions. You prepped these goals. You know what you want to get out of the call. Tell the customer. "Hey, my goal here is to show you our product and get your feedback and if there's interest I'd love to have a conversation with your broader architecture team or your CTO." Or whoever it is that you want to talk to. Whatever the next step might be, tell the customer.
The important thing here is that your customer might actually correct you. Your customer might be like "Hey, you know what, that sounds great, but in fact the next best step, if this makes sense, is for you to actually talk to this guy instead because that's the guy that matters." There's a lot of value there. Also, your customer will tell you what his goals are. Your customer's goal might be totally different than yours and you need to know that as soon as possible.
They might just want to explore your product because they actually don't have a real project on hand. They're just doing lab work and just trying to see what the landscape out there is. You want to know that before you end this call thinking that Goldman Sachs is now a lead. In fact, it might not be anything. You talked to some random dude and it was nice and all, but you're going to move on. You need to know that as well.
Then you want your customer to know that they're talking to somebody that's worth talking to. Let them know that you're competent. There are many ways that you can articulate competence. Explain to them that you've been in this space for X number of years. You can explain to them that you're one of the founders or whatever is relevant to your particular story and to the customer that you think is going to carry some weight.
It really depends on your role in the organization, your history. But for almost every single person who you're going to put in front of a customer there's almost always something there that gives them some sort of credibility, and make sure that gets highlighted in the opening so there isn't the risk of your customer simply ignoring you offhand.
The meat of the sales call is really identifying need.
You really hit sales nirvana when you are talking to a customer who is still in the process of figuring out what he actually wants. He knows he has a pain, but he's not really sure yet what solutions he really needs to solve that pain. So he's still in that exploratory mode of figuring out what he's looking for. If you can have a conversation with your customer at that stage, something really powerful happens. You can help them shape their vision for a solution based on what you're selling.
That's really powerful if your product is good because then when another vendor, maybe a large incumbent or another startup gets involved in the sales process, because your customer will try and find your competitors if you have any, and they will try to figure out if they're a better solution than you. But if you're there at that early phase, their vision for a solution will look very much like yours.
It's very uncommon that your competitors will be a one-to-one competitor to you. They'll do things that you don't do and they won't do things that you do. If you're the first person in it will help.
This is a really tough one especially for entrepreneurs. I sometimes fall into this trap and I've seen a lot of my friends fall into this trap. There's need and there's active need. Just because your customer says they "need" something doesn't mean they're going to buy it. An active need is that a customer needs it, they know they need it and they're actively looking to solve that pain. Because if they're not actively looking to solve that pain a few important things happen, especially when you're talking to larger customers.
It means there's no budget allocated. The rest of the team doesn't even know that anybody is looking at this stuff. Chances of them being able to organize the architecture team and the dev team and the dev ops team to even care about your product is unlikely. That means the CEO or the CTO, or whoever is the purchasing agent is probably going to be really, really hard to convince.
You don't want to be in a world where you're selling something where your customer isn't actively looking to solve that problem.
Unfortunately, this is really common for most IT products. If you find a customer where the pain isn't active, move on. Go find the guys who have active need because as a vendor it's nearly impossible to actually move your customer from just a normal need or a passive need, as some people call it, to an active need. That's not your job. Maybe marketing if they've had a huge budget can convince the customer that this is a must-have product, but unlikely.
Go find the guys who actually do believe your product is a must-have product and that's why they found you.
Need questions â€” this is where we're going to spend most of our time in the presentation. This is where I'll kind of walk through how Stormpath does its thing. There are three types of questions that we use to identify need. The first one is an open question. What are your highest priorities? What are you trying to achieve? What are you dealing with? Why are we on this sales call? Why did you contact us? Why did you sign up? Why are you making so many API calls?
These are open ended questions and the beauty of them is that you're allowing the customer to give you a free form answer. They're going to give you any answer that they want and it's wide open for what they care about and it's not a leading question. Leading questions are bad for sales people at the very beginning because you're there to try and be a sponge.
We're going to hear certain things in those open questions. They might tell you they've got a speed to market issue or they don't have anybody on staff who knows this stuff. Whatever their pain is you'll be able to pick that out, ideally, if they have an active pain.
Once you pick it out the next step is, you're going to have control questions. This is where you actually use the leading questions. This is where you actually use more specific questions to like, "You're having a problem with up time," or something like that. Who's that impacting? What's the extent of the impact? How much is it costing you, if you have any ability to budget, to kind of monetize or budget this? Why is this something that is high priority for you?
These are the questions that you're going to use to understand the gravity of the pain. Is this pain that actually matters? Is this a pain that you can use as a justification to sell your product to them?
Once you think you know what you're talking about, once you think you understand what the customer is dealing with you then want to confirm it. For most IT products, and especially when you're dealing with developers, the things that they're dealing with are really complicated. Just because you think you understand them, you'd be surprised you probably didn't understand it 100%.
By pushing it back on them and being like, "Hey, what I heard you say is that you've got two applications and you're really having a problem when one customer opens up, they log into this application and they try and go into this application; and you really don't want them to re-authenticate because it makes you look disjoined. That's a big pain because you're seeing drop-off of 10%, and that's really important because your cost of acquisition is X and if you're losing 10% of people over this minor thing, you're losing a wide number of dollars."
That level of confirmation is where you ultimately want to get to. If you are right, the customer will tell you and now you have a very, very strong understanding of the pain that you can then show them in return when you get to the proposal phase to say, "This is why you should buy our product. These are your own words. These are your own rationale for why you need this product." These are the need questions. Now we're actually going to go through it. I'll show you an example of how this works.
Once you get past preparation which for Stormpath preparation is ultimately, what industry are they in? Then based on that I look at the website. Do they already haven a web application? I play with the web app if I can get a handle on it. I try and figure out, where do I think we're going to fit? Why do I think they're bringing us in? Is it because they have multiple applications trying to centralize everything? Is it because they're building one app and they have some prototype code in there that they want to tear out and put something production grade in? I'll do some research.
Then once we go in we open and the opening is almost always the same. We explain who we are: "We're Stormpath. We're a user management API. I'm Alex. I'm one of the co-founders. We've been in security for over 10 years. We have one of the largest open source projects in the industry in the Java world. Based on what we saw in that market we built a product." Right there you know we establish credibility.
Now we go into the "Needs" section. The first question to the customer is, "What are you dealing with? Why did you sign up for Stormpath?" A common answer is, "I've got this application and we've got to build it, but it needs user management and every app needs it and it's a pain. Nobody here really wants to build it. I've got limited engineering resources and I need to get it out really fast."
Great, so there are a few things we hear. One is an issue of speed to market. The other issue is limited resources. The other one is, no one either wants to or knows how to really build the stuff properly. We'll grab the speed to market issue because I think for many developer APIs that's probably a really common theme.
"Okay, great, tell me about this speed to market issue. Why does that matter?"
"Well, I've got my app and the product management team has kind of committed to the business that we're going to get this thing out in three months, but when I look at the user management section it's going to take me at least 100 hours, minimum, to get this thing done right."
"Is that one engineer or is that two engineers?"
"It's 100 hours and probably one, one and a half engineers, if I do it like the bare minimum. But they're also asking for this, this and this."
"That engineer who you're going to work with, has he ever built a user management system before?"
"Yeah, he's built them, and he really doesn't want to build them again. He really hates it and so he really doesn't want to work on it. More importantly I really need that particular guy on this core feature for my product."
"Okay, if you put that guy on there what's going to be the ultimate cost?"
Now, for most development organizations cost questions are a little funky because they don't always know the answers. That's okay, you ultimately want to try and get cost questions to people because at the end of the day a transaction is a financial transaction.
If you can articulate a return on investment for your product, it will be that much easier to ultimately, not necessarily convince the developer team, but to convince their managers.
At the end of the day most dev teams, their budgets are not actually controlled by them, they're controlled by the business team. Maybe not in the Silicon Valley and maybe not in really early stage companies, but when you're dealing with large organizations everywhere else, it's the product management team, it's the business unit. And those guys think in ROI.
Do yourself a favor. Always try and take every pain down to a cost issue if you can.
If you can't, that's fine, but try to. You ask them, "What's this going to cost you?" Let's assume they're using contractors. They can calculate the number really quickly. "It's going to be 100 hours. We're paying $100 an hour, therefore, it's $10,000."
Now we've taken this issue of speed to market and we've tried to understand what it really means. Now we know that they've got to throw in engineering resources that they really need elsewhere. They're on a tight timetable that they're not sure they're going to make and from a labor perspective it's going to cost them 10 to 20 grand and that doesn't even include the cost of missing their deadline which is probably unquantifiable. Maybe it's not, maybe they know the revenue they're going to miss out if they miss out by a month or two.
Then you grab all of that and you confirm it back to the customer and make sure you actually understood it. "What I hear you saying is you're really worried about speed to market. You've got a tight timetable. This dev you need on this thing, and if you actually build this yourself it's going to cost you X just on development cost, probably 20% per year on maintenance cost and you have no idea how much it's going to cost you if you miss your deadline."
The guy says "yes," you move on. If they say "no," which happens, it happens a lot. It's very easy to misunderstand this stuff. You go back and you start all over again from wherever you missed out.
They say, "Well no, it's not really going to cost that much."
You say, "Okay, walk me through it. How much is it going to cost? How are you calculating this?"
They go, "Well I could maybe use this library here and that will short-cut it so it's maybe only going to cost me half that. And the maintenance isn't that big of a deal, so I'm not worried about that."
Once you think you understand it, confirm it back to them. You just keep confirming until they actually agree with you. Because if you don't understand it, there's no point in moving on.
Once you understand that person's reasons for having a conversation with you, once you understand that person's reasons for caring and having a pain related to your product, if you're selling to an organization there's other people. This is a really important thing to understand.
There's the developers. There's the product managers. There's the dev ops people. There's the IT guys. There's the CEO, the CTO, the finance organization, the legal organization, the marketing team. And almost all products that are out there impact more than just one person and more than just one org inside a larger company.
The next phase is really trying to understand the broader impact of the pain that they're having. You say, "Okay, well you've got this speed to market issue. Who else is impacted?"
"Well, don't get me started. The dev ops team, they have to build out all the infrastructure needed and they can't build the user management infrastructure until they actually know how it's going to work."
Or maybe it's the marketing team who's got to basically cue up all these things and they can't release the whole marketing campaign until they're done with their development and have beta tested it. Dev ops is impacted because they don't want to build this stuff either. They don't want to maintain the servers. They don't want to maintain the database tables. They don't want to keep up with security patches. Great, what does that mean for them?
"We've really only got one dev ops guy for this project, maybe half a guy, because this project is kind of a skunkworks thing or it's a side project and he's busy actually building out the scalable infrastructure for the core product. We don't really have time for him either to do this one other thing that's really important."
Okay, what does that cost you?
"Well if we did this right, given the timetables and the budgets that we have, we'd probably end up bringing on another IT guy, maybe a contractor to help with this piece and maybe that's going to cost us, let's say for the sake of argument, five grand."
You've now just taken this other pain which is a broader pain for maybe a different part of the organization or different person or different team member and you've also blown that out and now you've broken it down, or try and take it down, if possible, to the cost associated with that. Now you're starting to get an ROI story being built on this customer call.
You know that they're worried about how much it's going to cost them to actually build the software. You know they're worried about the revenue they're going to lose out by missing their deadline, and you know they're worried about the actual infrastructure cost of not just setting up the infrastructure to make it secure, but also the ongoing maintenance of that infrastructure because nobody wants to deal with this stuff.
Ideally you now have numbers around all these things and you also know the cost of your product. Later on you can now make, ideally, a compelling argument as to why you're a better solution than building it themselves.
Once you have an idea of the pain, you want to go talk to your customer about what they already think about how they're going to solve it. "How are you thinking of solving the problem?"
They might throw out a number of different things. They might say, in the case of many API services, "There's a RubyGem out there and we're thinking of using that."
"How else can you solve the problem?"
"Well we could roll it ourselves, of course."
How else can you solve the problem?
"We can bring in a contractor or we can look for an API service."
Obviously we're all API services in here so you might want to blow that out and say, "Okay, what if you could use a library, you could use a contractor, you can use your in-house team, but what if you just had a service where you didn't have to worry about it. What if your guys just integrated to it and there was no ops. You didn't have to worry about security. You didn't have to worry about figuring out hashing algorithms. This is all just done automatically for you. Would that work? Is that valuable to you?"
Now you're testing your own product features against them to see if they care. Because guess what? Not all your product features are going to land with all your customers. They might be things that you think are really important that they don't care about. For early stage companies this happens often. It happened to us.
A customer might say, "Yeah, you know, I really do care about the fact that I don't have to worry about the ops because my ops guy is limited, I don't have a lot of time for him, and he'll be really happy that this isn't on his plate."
"Okay great, what about the fact that we have really tight security and we provide the best hashing algorithms on the planet? "
They might say "I don't really care about that. At the end of the day this is a consumer site and as long as it's secure enough, I'm probably happy."
Okay great, now I know that's not a feature I'm going to push later on. I'm going to leave that one alone. "What about the fact that you can put all your user data into our system? You don't have to worry about a user table."
"That's really interesting because at the end of the day the user table in my application isn't that important, so if I could remove that from my app that would actually be helpful for the dev team because we don't like dealing with databases." Now you know that feature does matter.
In this phase you're trying to figure out what are your product features that are actually resonating with that customer. Because there's nothing more annoying to a customer and put yourself in the shoes of a customer, because you probably get sold to all day long, of being pitched something that you just don't care about. This is the phase where you get to figure out what those things are so that you don't run that same mistake further on in the sales process with your customer.
Once you figure out what are those keystone features for your product with your customer, again, you want to try to monetize it. For the sake of this presentation it's going to be a little too obvious, but it tends to be a little more complicated.
"Great, if you could have an API service to just handle all this stuff for you what would it save you?"
They would be like "Oh well, we already have the handy ROI that we just built in the process of this conversation. It's equal to that."
It's unlikely to actually be that in a real life situation, but you do want to try and monetize it because often times it's going to be a very complicated answer. They'll say "Well, we'll be able to save here, but this will cost more. We'll be able to save there, but then we made this trade off. We'll be able to save here, but this team may not actually care, so that cost is irrelevant."
But you want to understand how they're going to construct the ROI in their heads. There's the investment of what they're going to pay for your product and there's the return. If you can really understand that through this process, you'll come out of this sales call very, very informed.
One important thing about this is you will talk to customers who are not going to need your product. It's going to happen.
You're going to talk to a customer and you're going to be two steps into this thing and you're going to realize that they don't have a need. "Oh, I got a RubyGem and it just does the job."
You start throwing every single feature you have at them and they're like, "It's okay, it's not that big a deal. I've got five dev ops guys, I don't have a dev ops issue. My developers, they don't feel comfortable with having stuff in the Cloud, so they're happy to build it and I've got an in-house user management expert."
That's okay. Your goal here is not to browbeat your customer or magically convince them with your silver tongue that they absolutely need your product.
The real goal here is to figure out who actually needs it and then sell it to them. It's totally okay to figure out that your customer isn't going to be a customer and then stopping the conversation early thanking them for their time and then moving on.
Because if you've ever been at a meeting that ends short at the end of the day you're pretty happy about it. You think the guy did a great job. Even though they're not going to buy from you they're going to leave feeling that it was a good meeting because you were efficient with their time. There's nothing more painful than being on a call where you're not seeing any value and it just drags on forever.
Do everybody a favor, including yourself, if you see that the customer isn't going to be a customer cut it short, thank them for their time and move on.
Ideally, if the call has gone well and you've got a customer who is interested in what you're doing. There really is an opportunity here. They have a need. Your solution is resonating with them in order to solve that need. You've exited that call model I just showed you with the green light. Now we're going to talk about what the next step is. There are a variety of different next steps. There's nothing really here prescriptive for you, but it really just depends on where you are.
Often times it is something just as simple as scheduling the next meeting. If you're working on a really large project for a very large customer, it's unlikely you're going to get all of the "need" data from them in the 20 minute setting. You might need to have five of these calls before you even start to scratch the surface of what they really are trying to do because it's so big and so deeply technical. Maybe at the end of it you're just trying to move the ball forward.
Again, as mentioned earlier, it might be just to go meet with the decision maker. An important thing when you talk to people, and I see this mistake often with people who are new to sales, is you think you're talking to the right person every time you're talking to somebody. That is a huge assumption that is very often wrong. You want to understand what the purchase process is with your customer. It's totally okay to ask them this question:
"In addition to yourself who else is involved in the decision to use this product?" This is a very powerful question. You should never have a sales call where you don't already know the answer to that because at the end of that you might realize that the guy you were talking to doesn't actually matter.
You want to figure out who does matter so he can make an introduction to that person and you can have a substantial conversation. In my career in sales I have experienced painfully what happens when you don't do that and you assume you're talking to the right guy.
You'll spend three months going through a full-blown sales engagement with this person you think is going to make a purchase and then your competitor wins. It turned out that they were selling to the guy who mattered, and the guy that mattered didn't even know that you were involved. Maybe there are some politics involved. You have no idea. But you spent all of this time and energy. Guess what?
Sales is expensive because it involves people. Knowing you're shooting in the right direction is really important.
If you ask the question, "In addition to yourself, who else is involved?" It's very, very unlikely you're going to offend the person you're talking to. If they work at a large organization, they're used to the question. It's totally kosher to ask them to introduce you to the person who does matter.
The person you ultimately want to make sure you get a meeting with is the person who ultimately makes the decision. This is not always the person who has the money. Especially in developer services this is important because for many of us the architect is the guy who really matters. He's the guy who is ultimately trying to figure out what this piece of software is going to be built like and where the components are going to fit in and how they're going to work. But he may not actually have a budget.
The budget might be held by a business unit which has no idea what's actually being built. They have no idea what an API even is. You want to make sure you find that decision maker, not necessarily the budget holder, and talk to them.
This is a little contrary to what you'll read in some of the startup blogs out there where they say go follow the money. In developer services that will actually put you in trouble because when you're talking to a marketing guy who has no idea what you do and then they think you could be with Amazon.
Objections â€” is really honestly everything. When your customers throw objections at you what they're doing is they're testing their understanding of your product. They're testing their need for your product. It is almost always a good thing. If a customer doesn't like your product, if a customer doesn't want your product, if a customer doesn't want to be in the room with you, he's not going to throw many objections at you. He might throw one that's like an impossible question to show how smart he is.
For the most part people who legitimately aren't interested in your product, aren't going to take the time to throw a lot of stuff at you. It's the guys who are interested that will spend a lot of time asking you questions.
Some of those questions might actually feel antagonistic. Some of them might feel like they're poking holes in your baby, but it's almost always a good thing.
Understanding how to answer these questions in a way that isn't offensive and that's not going to tell your customer to go fly a kite is really, really powerful. Honestly, it is the difference between good reps and bad reps. I've been in many, many sales calls, I've worked with many different sales people and it's unbelievable the spectrum of abilities around handling objections.
If you get handling objections right, everything else becomes a lot easier.
Okay, a customer says something and, again, I think for many API services this is an easy one. "I can just grab a RubyGem. Why is this any different?"
So you've got an objection. The first step is you want to understand what their objection is. Instead of you just barreling in and telling them your canned answer, "Well, we're better than devise for these five reasons." You want to understand what they're really talking about.
"What does that mean?"
"Well, I'm currently building a rails application. Everybody here is rails, and devise does this stuff. Devise does authentication. Why can't I just plug that in and use them? It's free. Why would I pay you guys for the privilege of you doing this stuff?" Make sure you understand it.
Once you understand what the objection is, empathize. Acknowledge the fact that you heard what they said and what they said is valid. "Yeah, you're right. For some workloads using a RubyGem is sufficient. If it's a small workload, if you're just trying to do this narrow thing, that works. If you're totally cool with building out and maintaining the back end and the source code and all that, and if you're totally cool with that stuff, that works."
Customers like knowing that they're being listened to and so empathizing is you just confirming with them that you understood what they said and validated it. No matter how insane the question is.
It might be something totally irrelevant where they ask you how you compete with Netflix. You're like "what?" Empathize, make sure that you are listening. Make sure they know you're listening to them no matter how valid, no matter how detrimental the question, no matter how on the spot, no matter how easy, no matter how hard. Empathize. And then test it. Test your answer to it.
What "test" really means is, try and figure out if that's really the blocking objection because a customer might say something like "It's too expensive, I can't afford this." Is that the only reason they wouldn't buy it? Because if you spent all this time negotiating price with them, but it turns out that there's five other reasons they're not going to use your product, you just wasted your time.
"Okay, if price weren't an issue, is this a product that you would use? If I can convince you that we're better than a RubyGem is this something that you're still interested in?" You'd be surprised.
You'll often hear the answer "Well no, I've got all these other reasons." Or, "No, there's no way I could use this because of these reasons."
If you actually get a really strong "no" on this, something went wrong in the prior part of your conversation and it might be time to kind of revisit something that you thought you had right in the conversation. Actually, you might want to take a step back.
But if they say "Yeah, aside from the fact that I think that I could use a RubyGem for this," or "Aside from the fact that I think it's a little too expensive, I think everything else makes a lot of sense." Now you've got a real objection. You've got something that is blocking the customer from deciding to use you.
It will never be as simple as just one objection, but you want to make sure that you're handling objections that are on the path to them actually figuring out if they can use you. If they know outright that they're just not going to use it and you're handling objections, you're wasting their time and yours.
If the objection is real and they really are asking the questions, trying to figure out how they're going to use your product and this is an objection that's holding them up in that thought process, the step for you now is to consider: Is this a real disadvantage to my product? Maybe my product is too expensive. Maybe for this use case a RubyGem does do it.
Or, was it a misunderstanding? Did they misunderstand your pricing? In our case, maybe they think you're charging per user â€” we don't charge per user â€” and they're going to have a million users and they're worried that you're going to be like $20,000 a year or $20,000 dollars a month or something like that. Understanding if it's a misunderstanding is important because you can just quickly go in there, nip it in the bud and move on. Often times this happens.
For the same reasons you confirm the things you hear from your customers to make sure that you didn't misunderstand what they said, you just want to make sure that they didn't misunderstand what you said.
If it's a real disadvantage, like the price really is an issue, you want to understand that. If it really is an issue, if your customer doesn't have the budget or your customer can't use the Cloud for regulatory purposes or something like that, and it's really a show-stopper, now you know and you stop the conversation. You thank them for their time and you move on.
Now let's assume that it's a misunderstanding. You cover it. Give them the example and then you check with them to make sure that it worked. If it is a real disadvantage own up to it. The worst thing you can do is to start dancing around a real issue.
"Yes, it's expensive, but don't worry, it's worth it. Look at all these guys who love our products. It's money well spent."
"Yes, our product costs X. Are you okay with that? Can we make that work? If I can show you that there's a return on investment will you be willing to move forward with the conversation? But this really is our price. Yeah, sure, maybe we can negotiate it," if you have that kind of model and you can own up to that.
Own up to whatever the disadvantage really is because here's the thing, if you hide it or you convince them that it really isn't an issue even though it really is and they buy your product, you are going to be in a world of pain because then maintaining an angry customer, especially today where they blog and they tweet â€” not good. Make sure people know because here's the thing.
Your customer might walk away from that meeting believing that you're not the right product for them, but they're going to walk away respecting you.
Then in a month or two months or three months or a year when they try to do whatever the alternative to your product is and it failed and it was a disaster and they rethink what they were going to do and hopefully your product is sufficiently important where they could not do it properly themselves, they'll call you back. Now, because they know what your pricing really is or they know the limitations that you really do have, they may have rationalized those away and now they're contacting you and they're cool with those things. So, own up to them.
Once you think you've handled the objection properly, once you think that everything's cool, we're going to move on, confirm with them and move on. You're going to get these objections throughout the entire process. You're not going to get it at the end. You're going to get it from the beginning to the end at every single stage. Every time you bring up a question the chances are that you're going to get an objection. You might get it at the very beginning of the call. So preparing for them is really important.
Here's the good news. The more of these sales calls you do yourself, the more you're going to start to see a pattern. There are questions that are really specific to your application that you're going to get a lot. After a while you're going to know it and you're going to have this answer in your head. You're going to be able to walk through this objection handling in your sleep. That's also where preparation comes in.
The last thing is closing a call. Closing a call is actually really straightforward. You'll probably run out of time. If you're having a meaningful conversation with your customer you're going to run out of time. You want to identify the questions that were left over.
If they have questions for you that they didn't get to cover and maybe you have questions for them that you didn't get to cover, clear it up with them. Show them that those are the questions that you have and you're going to email them and maybe ask more questions. You're going to schedule time to have another conversation and cover those.
Then the important part is, you want to make it really clear to them why they should continue with you in any regard. Whatever that next step is, you want to summarize for them why they should take that next step with you.
It's not sufficient to say, "Okay, we had a great conversation, let's meet again in a week," because your customers are busy. They're busy as hell and the bigger they are the busier they are.
You want to say, "Hey, let's meet in a week because it sounds like you've got a problem with speed to market and it sounds like we might be a solution for you and if we can work together we might be able to save time and cost for you." Remind them why this matters.
Again, reiterate why your product matters. Why should they be talking to you? Chances are there are other vendors in the space or there's other alternative solutions in the space and you want to reiterate to them why it's worth talking to you. "We're an API service. We make this stuff real easy. We're Cloud hosted, it's instant, it's highly available, blah blah blah."
Then reiterate any of the key selling messages you picked up in the call: You heard that they've got this three-month deadline. You heard that this is costing them X number of dollars. You heard this, this and this. Reiterate those to them.
Reiterate anything else that you think is really critical for them to know that matters for them in the context of that sales call.
Then again, it's not just easy enough to say we'll chat again. That doesn't work because your customer will say "yes" and the meeting never happens. Get a commitment. "Listen, let's talk again. Should I schedule something for next Thursday? Should I schedule something for next week? We scheduled it with Tom. We scheduled it with Joe. We'll have you guys over at our office for a demo and I'll include these guys and you bring these guys."
Really try and articulate what that next step is going to be and if possible try and nail it down in that call because, otherwise, you're doing it via email and everybody's busy and those emails have a magical way of falling apart.
This sounds obvious and it sounds like lip service, but thank your customer for their time. There are anecdotes that are really powerful of customers literally ending sales calls with their sales people and being upset because they didn't get a thank you email or they didn't get a thank you of any kind and they were offended. This happens.
It may not happen as much out here in northern California, but I guarantee you it happens on the east coast. I've seen it happen many times. I guarantee it happens many places in the country. I would not be surprised if it happens here as well.
Make sure you thank people. A thank you email will go a long way. Don't get me wrong a thank you card is actually quite powerful.
I remember sending thank you cards to my customers sometimes and they would bring it up months later. They'd be like "Remember when you sent me that Thank You card, that was really cool." And you're like "Oh, that's cool man, thanks."
That's the presentation and I'm happy to take any questions you guys might have.
Q: When on a sales call for a technical product, when do you bring in a technical salesperson?
A: That's a great question. When you're really early stage, I'm a firm believer that you should not have two different sales teams. The sales team should be specifically your founding team, nobody else. Once you're a little bigger and you have more people, maybe you're bringing in like your VP of marketing, somebody who deeply understands your product. Bringing in multiple people into a sales engagement can complicate things.
Particularly in a sales call, having multiple people in a sales call hinders your ability to control that call. But once you're larger you're not going to be able to scale that way. There aren't enough people in the world that are going to be technical and skilled at sales that you can afford and hire a lot of. So, you often see that divergence quickly. There's no good answer.
I'll tell you what I've seen and what I've done personally. I have a very technical background. I very rarely brought in my technical sales guys. The way I handled my own sales calls was I would take care of all the first meetings, flesh out the need, flesh out what the customer is trying to do.
Your salespeople need to be technical enough to understand what your customer is trying to achieve. If your sales team isn't sufficiently technical to actually understand your customer's problems and be able to do what we talked about and actually whittle them down to a really specific pain and a cost and a need and they don't understand those keywords in your industry, then all you really have are order takers.
Order takers suck. You don't need order takers. Online you can have an ordering system. You need to hire guys who can actually have that conversation.
Assuming you have those guys to have those conversations they should do all the need analysis, as much of it as they possibly can. In that same spirit, if the call allows it, or the sales process allows it, they should do the very initial explanation of what the product is. The technical salesperson is great to bring in, to start hammering out the speeds and feeds.
What's the response rate going to be on the API call? How am I going to model this particular use case in your API service? How am I going to store this data? How am I going to migrate this system to that system? That's what a technical sales rep should be really good at because that's no longer sales, that's more sales facilitation. So your sales guy you don't want him bogged down in those things no matter how technical they are because then you're wasting the salesperson's time when they could be talking to more customers.
Even we do this too, as technical as I am and as much of the product I've helped build, I still bring in my co-founder, my CTO, the chief architect. I still bring him into sales calls every once in a while. The value there is if I know I'm talking to an extraordinarily technical person or the use case is really complicated, because I prepped, I'll bring him on and he'll just be waiting in the wings. He'll be paying attention. He doesn't have an active role in the call unless a question comes up that I can't answer. Then I go "Les, what do you think?" Then Les will dive in and really go into it. That works really well.
What doesn't work and what I've seen a lot of is that the salesperson will bring the technical salesperson into every call they have which, one, is extraordinarily inefficient because sales engineers are just as busy as sales people. Two, because the salesperson isn't that technical they'll open the call, they'll close the call, and they'll let the technical salesperson do everything in the middle.
Which is also really inefficient because most technical sales people have not been trained in handling need analysis and proposal. They're good at understanding speed and feeds and helping people understand how the migrations are going to work. So you end up with a very insufficient sales process. This is actually how most large enterprise sales guys actually operate unfortunately. Even at the biggest companies out there like Oracle and HP and Salesforce. So, don't do that.
Q: How do you keep track of relevant client information during a call?
A: This is where Marc Benioff will be super happy. Yeah, you put this in a CRM. If you've got a large enough sales organization first off, you're taking notes. If a salesperson doesn't have a notebook with him at all times and writing stuff down, don't hire that guy. Especially when you're doing technical sales, you're not hearing things that you're just going to remember.
When someone tells you like the API call they're trying to make, that's something that's really specific and you need to take that note down because it might sound like you're going to remember it when you first hear it, but 30 minutes later when you're talking about nine other things, you probably forgot it all. Taking notes is really important. I have a way of taking notes. I'm happy to show you how I took notes, later on, in my sales calls, but taking notes is absolutely paramount.
Then taking those notes and then summarizing them is really important. The way that I used to do it, and this is how I was trained to do it at IBM, was: I would take my notes. I'd summarize it into an email back to the customer. Then I'd take that email and I would put it in the CRM. That's a lot easier these days because Cloud-based CRMs allow you to basically just bcc the CRM and now it's just automatically in there. That's the way that I thought to be most efficient with my time.
It's great because these sales cycles, if you're selling to business customers, sales cycles can be really long. You can be talking about eight-month sales cycles, maybe more. Having this stuff in one centralized location like a CRM, no matter what it is, is important because if maybe a customer goes dark on you for four months and they come back to you, you can easily go in the CRM and see the entire history of the conversations you've had with them.
Q: Do you encounter developers who feel they can just build an alternative to your product?
A: That's a very common problem. If your customer thinks they can build it in a weekend, they're not going to be your customer. That's accepted. That is somebody who doesn't necessarily believe they have a pain and you're trying to convince them they have a pain. I'm sure that you might have a silver tongue and might be willing to spend all this time convincing them that it isn't worth them doing, but you've got better things to do. If you don't you probably have problems with your business model.
Maybe your customer already has a solution. Maybe they say, "Well I could build this. It will take me X, but I can build it."
Maybe it's not that extreme of an answer and it's like, "I can build this, but it's going to take me X." It's a reasonable answer.
What you can do is you can actually go back to this call model that I showed you. If you're actually competing with something, if you're going in with a customer who already has an alternative solution, whether it be a competitor or just some orthogonal way of doing it, you can start at capabilities.
You say, "If you build it yourself what are the things that you like about it? What are the things you don't like about it? Why is that not a great solution? Why is it a great solution?" Then you can understand why they're thinking about that. Almost always there's a problem with whatever they pick.
All products are imperfect. If those imperfections align with a big enough pain that you can solve, then you can basically go through this model with them regarding those things.
"If you build it yourself it's going to take you nine months. What if it only took you a week?"
"Oh well, God, if it took me a week that would be really cool."
Obviously, it may not be that easy. "If it took you a week what would be the value to you? How would you put a price tag or some sort of quantification on that value?" Once you hear that you start diving into the beginning of this thing from the very top and start cycling through.
Q: How do you handle a situation where you convince one person, who then goes into another meeting to convince someone else?
A: That's a great question. If you're doing this right, you shouldn't be prepping them to have that meeting. You should be prepping them to engage you in that meeting because if there's other people they have to convince that means you're not talking to the decision maker. So you need to identify who that person is. Ask them, "Who are those three people?
"Well, it's this guy and this guy and this guy."
"Can you introduce me to them? Can I give them a demo? Can I show them the product?"
Whatever you think is appropriate to get a meeting with them, offer that or ask for that.
What you might hear is "Well it's a little early for that. Let me feel you out a little more before I introduce you to them." If that's the case then make sure that you identify, "What would it take for us to get a meeting with them?" They'll tell you and if they don't have a good answer it's probably a bad sign.
The ultimate goal is not necessarily to fully prep them, though you should. I mean, you can hand them documentation. In the API services world it's almost always an issue of documentation or an issue of a case study of a customer that did something similar to them. You should have all that stuff on hand. You should work with your marketing team or build it yourself to generate those kinds of documents and just have them at the ready â€” product guides, whatever.
A lot of stuff can be handled with collateral, but almost always if there are other people involved you need to work to get a meeting with them.
To that end I'll add one more thing which is,
Just because you can have a sales meeting with somebody, just because you can go through a sales process and maybe after this you now think you can handle it all. And I hope you can, that's the intention of this. It doesn't necessarily mean you should.
If you're talking to somebody who is small and you're already past the product validation stage, now you're actually trying to scale the product and sell for real, you don't have to take every meeting. There are customers that are too small. There are customers that are too big.
You ideally have a clear idea of what your target customer looks like. If they're not in that target customer box, you probably don't want to waste your time.
It's okay to tell a customer "Hey thank you for your time. Check out our documentation and here's our self service model."
Q: What if you're in a meeting with the person whose job you're trying to replace?
A: It depends. Sometimes you think it's awkward and it turns out the QA lead maybe wants to outsource it. First off, is that person really against your product or not? You will have organizations where people are against your product. It happens. It happens to us all the time. There's a sales terminology for that. They're called saboteurs and you want to identify them. Who's not interested in your product? Who really doesn't want it? Whose job might you be replacing?
The goal is to understand that person, understand who they are. In some cases if you think it's valuable, take a meeting with them. But if you're literally replacing them, you probably don't want to take a meeting. It really depends.
At the end of the day in your scenario the question is who gets to decide? If the decision is ultimately the VP of Eng then don't worry about it. Understand that person, understand what you think they're going to say against your product, not necessarily disparage it, but the argument they're going to make against using you. And make sure you're prepared for those.
Put forward the best case you can based on the ROI that you hopefully have developed over the process of the sales engagement and present your case to the VP of engineering.
Look, if the VP of engineering brought you in to have a sales call and it's gone for more than just one call, it means that he probably understands there's a problem and is looking for a solution. Take comfort in the fact that you've gotten this far despite that awkwardness because there's a real pain that you're going to solve.
Alternatively, if you're having that high friction between those two people, it might mean that you're talking to the wrong person. Maybe it's the CEO or the CTO who's ultimately going to be the tiebreaker in which case you should have a conversation with him.