1. Library
  2. Arrow Icon
  3. Sales Calls for Developers
AUG 22, 2014 - NaN MIN

Sales Calls for Developers

  • Sales

Alex Salazar is the CEO of Stormpath and former top sales leader at IBM. While at IBM, he achieved “Sales Person of the Year” honors and successfully carried quotas as high as $30M. Prior to IBM, Alex was an enterprise software developer.

  • Introduction
  • Sales Calls for Developers
    • The Buying and Selling Steps
    • The Sales Call Model
    • Preparing for the Call
    • Opening the Call
    • Identifying Need
    • 9-Block Call Model
    • Proposing Next Steps
    • Handling Objections
    • Closing the Call
  • Q&A
Download slides

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 hiresneeds to be a salesperson becausethey know what to do and you don't.Also, a big myth.The third myth is thattechnical 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 thecore parts of everybody's sales abilitywhich 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 partsof sales, if time permitting.

So who am I?I'm Alex Salazar.I'm the CEO and one ofthe 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 carrieda 30 million a year quotafor large enterprises in New York.In my career I have sold over 200 million dollarsworth of software and services.

I'm also a former software developer.In fact, my co-founder and I met when wewere the founding engineering teamfor a SaaS startup back in the day,many moons ago.Prior to that he and I were also studentsin computer science at Georgia Tech.For posterity, I also have an MBA from Stanfordwhich makes me sound great,but it actually is irrelevant for this presentation.

About Stormpath, like many of you we area developer services company.We provide a user management andauthentication service for developers.We provide password security.We provide authentication.We provide access control viapermissions and groups.We also take care of things likeLDAP synchronizationfor larger enterprise-type workloads.

The value prop of our product is the factthat 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 dobecause as I take you throughthe mechanics of a sales call,I'm going to be using our companyand what the typical conversations we havewith our customers as an example of thethings I'm going to cover.

The things we're going to cover todayare really taking you througha normal sales call with a customer.I'm going to take you throughwhat the buying steps typically are for a customerand what the complimentsales steps are for most vendors.

When we go into the sales call,I'm going to take you throughwhat 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 objectionsbecause most customers have themand handling them is really where yougenerate the most value for your customers.Then time permitting, we'll actuallytry and go through a very interactive session. We'll see if time permits.

First let's talk about the steps thatpeople go through when they buy.If anybody's ever had a really bad experience with a sales guy,maybe you were purchasing a caror you went to go buy a pair of shoesand you just couldn't stand the sales guyyou were working with.If you really try and analyze why youdidn't like the guy it's almost always becausethey were trying to sell you at a different stagethan 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 tobuy this pair of shoes. Oryou go into a car dealershipand you're really just there to test driveto see what you like, and the guy doesn't want you to leave the dealershipuntil you've signed a contract.What's happening there is a mismatchin what you're trying to doand what he's trying to do.

Great sales, where your customer actuallyenjoys working with you,is when you are aligned.

When they're trying to figure outwhat their needs are, you're trying to figure outwhat their needs are.When they're trying to figure out what solutionsfit those needs, you're presenting your solution.When they've whittled down to a set ofone or two vendors that might be the solution,you're there trying to help themget over the hump and decide to use your product.Once they've decided to use your productat that point is when you start going intoheavy negotiation around priceand 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 thingsthat is really disruptivecompared to traditional software vendorsis that a lot of this tendsto be happening self-service.Developers don't like cold calls.They're not going to take a meeting with youjust because you found their email addressand sent them an email.They will take a sales call,but only after they've seen the productor maybe only after they've beenintroduced to you via somebodyor they saw a nice blog article.

There is still a sales call aspect to this stuff,especially for larger customerswho are unlikely to self-service all the way throughto a large transaction.In the developer services worldyou still can't get away from this stuff.What happens in a sales call?What happens when GE contacts youand they want to have a conversationabout 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 pointin continuing the conversation.

Then assuming that there is enough to continue, there is some sort of proposal.Whether it be to purchase your productor continue the conversationor make an introduction to somebodymore important in the organization.Then there's finally, actually closing the callin an appropriate way where everybody knows what's going to happen nextand you have the commitment to achievewhatever the next step isand whatever the company's process.

Then throughout every single sales callI've ever been in there are always objections.Customers will bring up all kinds of reasonswhy your product may not be a fit.It actually is always a good thingwhen you get objections.In fact, the worse sales call you can be onis one where you don't get any objectionsbecause it means the customer is not eventaking you seriously.

Objections are a way of a customerprodding to see if they understandwhat you're doing. How you handle themis really where the difference betweena good salesperson anda great salesperson lays.

There's actually a lot of data around that.I think Harvard Business School did a landscape studyof different sales reps to seewhat made great high performingsales reps different from mediocre reps.Across the board the only thing that hadany real correlationwas 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 crazyin your office.Your marketing person reaches outto ESPN to figure out what they wantand 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 IBMI 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 thinkabout what's going to happenuntil 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 thingsyou want to do.The first thing is try and understand your customer.Not all customers are going to be big brandsthat 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 backgroundon what you're thinking?"The more preparation you have going into that call,the more likely you are tohit on a hot button issue that's going to reallydrive the engagement with them.The more likely you are to make them feelthat you're not wasting their timeand the more efficientyou're going to be with that call because a customer call is roughly,honestly, only about 20 minutes.

Getting more than 20 minutesof a customer's time is really hardand 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 minutesit's actually really hard to get that second meetingbecause customers don't want their time wasted.

In addition to preparing yourself for this callfrom a research perspectiveyou also want to figure out what you want out of it.What's the goal of the call?If you're talking to a customerfor the very first time,are you going to try and close themon that one call?Really unlikely, especially if you're sellingto larger organizations.

The objective might be to get an introductionto the person who actually gets to make the decisionas to whether or not yourAPS 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 bringthe whole team in for a demo or vice versa, you go there for a demo.Maybe it's just to continue talkingbecause you only scratched the surfaceof the technical problem that they're having.

Knowing what the set of objectives areis really powerful because it allows you to focusthe conversation and keep itfrom going off on tangents.

To that end try and think throughwhat the tangents are that your customermight jump off on, and have a planfor bringing them back inon the path of what you're trying to achievebased on what you think they're trying to do.

Also, what are the objectionsthey're going to run into?If you've talked to customers more than onceyou already have a sense for whatthese objections are going to be.The tried and true objection is, 'It's too expensive.' So have an objectionresponse ready for 'it's too expensive'or anything that's related to your product: "I found a Ruby librarythat already does this stuff."

Having those kinds of objectionsalready pre-handled in your head will makethe call go a lot smootherand 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 quickand talk about what happensbefore 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 builda relationship with a customerat 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 callto ask them like what they did for the weekendand 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 pointis really appreciated because everyone's busyand so are you.

And if there is a realbusiness relationship to be had,there will be many opportunities for youto build a relationship with themthat are about the Niners game and what they did for the weekend. But it will be a lot more naturalonce there are now the beginningsof a real relationship.

I'm actually an opponentof 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 likereally depends on who your customer is.Walking into Twitter's offices in a suit and tieis an easy way of getting laughed atand is not going to win you any points. But walking into any office on Wall Streetwith a T-shirt on with your company logo on itis an easy way of never getting called back.

Being really sensitive to whatyour customer's business is,what their culture is,what their expectation of a dress code isand trying to mirror that forthe purposes of the sales callis really, really powerful.

Off the record ask me a question about thisand I'll actually give you a strong example of the wayI learned this the hard way.

Also, the sales call is neveran absolute thing that happens on its own. There's a lot of conversations beforehand,there are a lot of conversationsthat happen afterwards.One of the best things you can do to prepareis to present yourself professionallybefore the sales meeting.When your customer is trying tocommunicate with you for schedulingor they're asking for docs or they're askingfor any kind of particular data, you're responsive.

You're showing that you area professional organization and they can trust you.When you walk into that call, you're walking inwith 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 productand get your feedback and if there's interestI'd love to have a conversationwith your broader architecture teamor 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 thatyour 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 actuallytalk to this guy instead becausethat'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 betotally different than yoursand you need to know that as soon as possible.

They might just want to explore your productbecause they actually don't havea real project on hand.They're just doing lab workand just trying to seewhat the landscape out there is.You want to know that before you end this callthinking that Goldman Sachs is now a lead.In fact, it might not be anything.You talked to some random dudeand 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 knowthat they're talking to somebodythat's worth talking to.Let them know that you're competent.There are many ways thatyou can articulate competence.Explain to them that you've been in this spacefor X number of years.You can explain to them that you'reone of the founders or whatever is relevant to your particular storyand to the customer that you thinkis going to carry some weight.

It really depends on yourrole in the organization, your history. But for almost every single personwho you're going to put in front of a customerthere's almost always something therethat gives them some sort of credibility, and make sure that gets highlightedin the opening so there isn't the risk of your customersimply ignoring you offhand.

The meat of the sales call is really identifying need.

You really hit sales nirvana whenyou are talking to a customerwho is still in the process of figuring outwhat he actually wants.He knows he has a pain,but he's not really sure yetwhat solutions he really needs to solve that pain. So he's still in that exploratory modeof figuring out what he's looking for.If you can have a conversation with your customerat that stage, something really powerful happens.You can help them shape their visionfor a solution based on what you're selling.

That's really powerful if your product is goodbecause then when another vendor, maybe a large incumbent or another startupgets involved in the sales process,because your customer will try and findyour competitors if you have any,and they will try to figure outif 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 competitorswill be a one-to-one competitor to you.They'll do things that you don't doand they won't do things that you do.If you're the first person in it will help.

This is a really tough oneespecially for entrepreneurs.I sometimes fall into this trapand I've seen a lot of my friendsfall into this trap.There's need and there's active need.Just because your customer saysthey "need" something doesn'tmean they're going to buy it.An active need is that a customer needs it,they know they need itand they're actively looking to solve that pain. Because if they're not actively lookingto solve that paina 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 knowthat anybody is looking at this stuff.Chances of them being able to organizethe architecture team and the dev teamand the dev ops team to even careabout your product is unlikely.That means the CEO or the CTO, or whoever is the purchasing agentis probably going to be really,really hard to convince.

You don't want to be in a world whereyou're selling something where your customer isn'tactively looking to solve that problem.

Unfortunately, this is really commonfor most IT products.If you find a customer where the pain isn't active,move on. Go find the guyswho have active needbecause as a vendor it's nearly impossibleto actually move your customer from justa 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 budgetcan convince the customer that this isa must-have product, but unlikely.

Go find the guys who actually do believeyour product is a must-have productand that's why they found you.

Need questions — this is where we're going to spendmost of our time in the presentation.This is where I'll kind of walk throughhow Stormpath does its thing.There are three types of questions that we useto 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 questionsand the beauty of them is that you're allowing the customer to give youa free form answer.They're going to give you any answerthat they want and it's wide openfor what they care aboutand it's not a leading question.Leading questions are bad for sales peopleat the very beginning becauseyou're there to try and be a sponge.

We're going to hear certain thingsin 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 ableto pick that out, ideally, if they have an active pain.

Once you pick it out the next stepis, you're going to have control questions. This is where you actually usethe leading questions.This is where you actually usemore 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 haveany ability to budget, to kind ofmonetize or budget this?Why is this something that is high priority for you?

These are the questions that you're going to useto understand the gravity of the pain.Is this pain that actually matters?Is this a pain that you can useas a justification to sell your product to them?

Once you think you know what you're talking about,once you think you understand what thecustomer is dealing withyou then want to confirm it. For most IT products,and especially when you're dealing with developers,the things that they're dealing withare really complicated.Just because you think you understand them,you'd be surprised you probably didn'tunderstand it 100%.

By pushing itback on them and being like, "Hey, what I heard you say is that you've got two applications andyou're really having a problemwhen one customer opens up, they log into this applicationand they try and go into this application;and you really don't want them to re-authenticatebecause it makes you look disjoined.That's a big pain becauseyou're seeing drop-off of 10%,and that's really important because your cost of acquisition is Xand if you're losing 10% of peopleover this minor thing, you're losinga wide number of dollars."

That level of confirmation is where youultimately want to get to. If you are right, the customer will tell you and now you have a very, very strong understandingof the pain that you can then show them in return when you get tothe proposal phase to say,"This is why you should buy our product. These are your own words.These are your own rationale for whyyou 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 preparationwhich for Stormpath preparationis 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 thinkwe're going to fit?Why do I think they're bringing us in?Is it because they have multiple applicationstrying to centralize everything?Is it because they're building one appand they have some prototype code in therethat they want to tear outand put something production grade in?I'll do some research.

Then once we go in we openand 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 projectsin the industry in the Java world.Based on what we saw in that marketwe 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 applicationand we've got to build it,but it needs user managementand every app needs it and it's a pain.Nobody here really wants to build it.I've got limited engineering resourcesand 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 toor knows how to really build the stuff properly.We'll grab the speed to market issuebecause I think for many developer APIsthat's probably a really common theme.

"Okay, great, tell me aboutthis speed to market issue.Why does that matter?"

"Well, I've got my appand the product management teamhas kind of committed to the businessthat we're going to get this thing out in three months,but when I look at the user management sectionit's going to take me at least 100 hours, minimum,to get this thing done right."

"Is that one engineeror is that two engineers?"

"It's 100 hours and probably one,one and a half engineers, if I do itlike the bare minimum. But they're also askingfor 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 reallydoesn't want to build them again.He really hates it and so he reallydoesn't want to work on it.More importantly I really need that particular guyon this core feature for my product."

"Okay, if you put that guy on therewhat's going to be the ultimate cost?"

Now, for most development organizationscost questions are a little funkybecause they don't always know the answers.That's okay, you ultimately want to tryand get cost questions to peoplebecause at the end of the daya transaction is a financial transaction.

If you can articulate a return on investmentfor your product, it will be that much easierto ultimately, not necessarily convincethe developer team,but to convince their managers.

At the end of the daymost dev teams, their budgets are not actuallycontrolled by them, they're controlledby the business team.Maybe not in the Silicon Valley andmaybe not in really early stage companies,but when you're dealing with large organizationseverywhere 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 toa 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 calculatethe 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 marketand we've tried to understandwhat it really means.Now we know that they've got to throw in engineering resourcesthat they really need elsewhere.They're on a tight timetablethat they're not sure they're going to makeand from a labor perspective it's goingto cost them 10 to 20 grand and that doesn't eveninclude the cost of missing their deadlinewhich is probably unquantifiable.Maybe it's not, maybe they knowthe revenue they're going to miss outif they miss out by a month or two.

Then you grab all of that and youconfirm it back to the customerand make sure you actually understood it. "What I hear you saying is you're reallyworried about speed to market.You've got a tight timetable.This dev you need on this thing,and if you actually build this yourselfit's going to cost you X just on development cost,probably 20% per year on maintenance costand you have no idea how muchit'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 againfrom wherever you missed out.

They say, "Well no, it's not really goingto 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 hereand that will short-cut it so it'smaybe 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 theyactually agree with you. Because if you don't understand it,there's no point in moving on.

Once you understand that person's reasonsfor having a conversation with you,once you understand that person's reasonsfor caring and having a pain related to your product,if you're selling to an organizationthere'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 thereimpact more than just one personand more than just one org inside a larger company.

The next phase is really trying tounderstand the broader impactof the pain that they're having.You say, "Okay, well you've got thisspeed to market issue.Who else is impacted?"

"Well, don't get me started.The dev ops team, they have to build outall the infrastructure needed and they can't buildthe user management infrastructureuntil they actually know how it's going to work."

Or maybe it's the marketing team who's got tobasically cue up all these thingsand they can't releasethe whole marketing campaignuntil they're done with their developmentand have beta tested it. Dev ops is impacted becausethey 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 onedev ops guy for this project, maybe half a guy, because this project is kind of a skunkworks thingor it's a side project and he's busyactually building out the scalable infrastructurefor the core product.We don't really have time for him eitherto 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 onanother IT guy, maybe a contractor to help with this pieceand maybe that's going to cost us, let's say for the sake of argument, five grand."

You've now just taken this other painwhich is a broader pain for maybe a differentpart of the organization or different personor 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 thecost associated with that.Now you're starting to get an ROIstory being built on this customer call.

You know that they're worried abouthow much it's going to cost themto actually build the software.You know they're worried about the revenuethey're going to lose out by missing their deadline,and you know they're worried about theactual infrastructure cost of not justsetting up the infrastructure to make it secure,but also the ongoing maintenanceof that infrastructurebecause nobody wants to deal with this stuff.

Ideally you now have numbers aroundall these things and you also know the cost of your product. Later on you can now make, ideally,a compelling argument as to whyyou're a better solutionthan building it themselves.

Once you have an idea of the pain,you want to go talk to your customer aboutwhat they already think abouthow 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 thereand 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 orwe can look for an API service."

Obviously we're all API services in hereso you might want to blow that out and say, "Okay, what ifyou could use a library,you could use a contractor,you can use your in-house team,but what if you just had a servicewhere you didn't have to worry about it.What if your guys just integrated to itand there was no ops.You didn't have to worry about security.You didn't have to worry about figuring outhashing algorithms. This is all just doneautomatically for you. Would that work?Is that valuable to you?"

Now you're testing your own product featuresagainst them to see if they care.Because guess what?Not all your product features are going to landwith all your customers.They might be things that you thinkare 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 aboutthe fact that I don't have toworry about the ops because my ops guyis 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 thatwe have really tight security and we providethe 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 longas it's secure enough, I'm probably happy."

Okay great, now I know that's not a featureI'm going to push later on.I'm going to leave that one alone. "What about the fact that you can putall your user data into our system?You don't have to worry about a user table."

"That's really interestingbecause at the end of the daythe user table in my applicationisn't that important, so if I couldremove that from my appthat would actually be helpful for the dev teambecause we don't like dealing with databases."Now you know that feature does matter.

In this phase you're trying to figure outwhat are your product featuresthat are actually resonating with that customer.Because there's nothing more annoyingto a customer and put yourself in theshoes of a customer, because you probablyget sold to all day long, of being pitchedsomething that you just don't care about.This is the phase where you get tofigure out what those things areso that you don't run that same mistakefurther on in the sales process with your customer.

Once you figure out what are thosekeystone features for your productwith your customer, again,you want to try to monetize it.For the sake of this presentationit's going to be a little too obvious,but it tends to be a little more complicated.

"Great, if you could have an API serviceto just handle all this stuff for youwhat would it save you?"

They would be like "Oh well, we alreadyhave the handy ROI that we just builtin the process of this conversation. It's equal to that."

It's unlikely to actually be thatin a real life situation,but you do want to try and monetize itbecause often times it's going to bea 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 goingto construct the ROI in their heads.There's the investmentof what they're going to pay for your productand there's the return.If you can really understand thatthrough this process,you'll come out of this sales call very, very informed.

One important thing about this isyou will talk to customers who are notgoing to need your product. It's going to happen.

You're going to talk to a customer and you'regoing to be two steps into this thing and you're going to realize thatthey don't have a need."Oh, I got a RubyGem and it just does the job."

You start throwing every single featureyou 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 havingstuff in the Cloud, so they're happyto build it and I've got an in-houseuser management expert."

That's okay. Your goal here is not tobrowbeat your customer or magicallyconvince them with your silver tonguethat they absolutely need your product.

The real goal here is to figure outwho actually needs itand then sell it to them.It's totally okay to figure outthat your customer isn't going to be a customerand then stopping the conversation earlythanking them for their time and then moving on.

Because if you've ever been at a meetingthat ends short at the end of the dayyou're pretty happy about it.You think the guy did a great job.Even though they're not going to buy from youthey're going to leave feeling thatit was a good meeting because you wereefficient with their time.There's nothing more painful thanbeing on a call where you're not seeing any valueand it just drags on forever.

Do everybody a favor, including yourself,if you see that the customerisn't going to be a customercut it short, thank them for their time and move on.

Ideally, if the call has gone welland 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 themin order to solve that need.You've exited that call modelI 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 simpleas scheduling the next meeting.If you're working on a really large projectfor a very large customer,it's unlikely you're going to getall of the "need" data from themin the 20 minute setting.You might need to have five of these callsbefore you even start to scratch the surfaceof what they really are trying to dobecause it's so big and so deeply technical.Maybe at the end of it you're just tryingto 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 withpeople who are new to sales,is you think you're talking to the right personevery time you're talking to somebody.That is a huge assumption that is very often wrong.You want to understandwhat the purchase process is with your customer.It's totally okay to ask them this question:

"In addition to yourself who else is involvedin the decision to use this product?" This is a very powerful question.You should never have a sales callwhere you don't already know the answer to that because at the end of that you might realizethat the guy you were talking todoesn't actually matter.

You want to figure out who does matterso he can make an introduction to that personand you can have a substantial conversation.In my career in sales I have experienced painfully what happenswhen you don't do thatand you assume you're talking to the right guy.

You'll spend three months going througha full-blown sales engagement with this personyou think is going to make a purchaseand then your competitor wins. It turned out that they were sellingto the guy who mattered,and the guy that mattereddidn'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 directionis really important.

If you ask the question, "In addition to yourself, who else is involved?" It's very, very unlikely you're going tooffend 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 themto introduce you to the person who does matter.

The person you ultimately want to make sureyou get a meeting with is the personwho ultimately makes the decision.This is not always the person who has the money.Especially in developer servicesthis is important becausefor many of us the architectis the guy who really matters.He's the guy who is ultimately trying to figure outwhat this piece of softwareis going to be built likeand where the components are going to fit inand how they're going to work. But he may not actually have a budget.

The budget might be held by a business unitwhich has no idea what's actually being built.They have no idea what an API even is.You want to make sure you find thatdecision maker, not necessarily the budget holder,and talk to them.

This is a little contrary to what you'll readin some of the startup blogs out therewhere they say go follow the money.In developer services that will actuallyput you in trouble because whenyou're talking to a marketing guywho has no idea what you do and thenthey think you could be with Amazon.

Objections — is really honestly everything.When your customers throw objections at youwhat they're doing is they're testingtheir 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 wantto be in the room with you,he's not going to throw many objections at you.He might throw one that's likean impossible question to show how smart he is.

For the most partpeople who legitimatelyaren't interested in your product,aren't going to take the timeto throw a lot of stuff at you.It's the guys who are interestedthat will spend a lot of time asking you questions.

Some of those questionsmight actually feel antagonistic.Some of them might feel likethey're poking holes in your baby,but it's almost always a good thing.

Understanding how to answer these questionsin a way that isn't offensive and that's not going to tell your customerto go fly a kite is really, really powerful.Honestly, it is the differencebetween good reps and bad reps.I've been in many, many sales calls, I've worked with many different sales peopleand it's unbelievable the spectrum ofabilities around handling objections.

If you get handling objections right,everything else becomes a lot easier.

Okay, a customer says somethingand, again, I think for many API servicesthis 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 understandwhat their objection is.Instead of you just barreling inand telling them your canned answer,"Well, we're better than devisefor these five reasons."You want to understandwhat they're really talking about.

"What does that mean?"

"Well, I'm currently buildinga 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 guysfor the privilege of you doing this stuff?"Make sure you understand it.

Once you understand what theobjection is, empathize.Acknowledge the fact that you heardwhat they said and what they said is valid."Yeah, you're right. For some workloadsusing a RubyGem is sufficient. If it's a small workload, if you're just trying to do thisnarrow thing, that works.If you're totally cool with building outand maintaining the back endand the source code and all that, and if you're totally cool with that stuff, that works."

Customers like knowing that they'rebeing listened to and so empathizing is you just confirming with them that you understoodwhat they said and validated it.No matter how insane the question is.

It might be something totally irrelevantwhere 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 themno 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 somethinglike "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 timenegotiating price with them,but it turns out that there's five other reasonsthey'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 betterthan a RubyGem is this somethingthat 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 thisbecause of these reasons."

If you actually get a really strong "no" on this,something went wrong in the prior partof your conversation and it might be timeto kind of revisit something that youthought 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 thatI could use a RubyGem for this," or"Aside from the fact thatI 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 isblocking the customer from deciding to use you.

It will never be as simple as just one objection,but you want to make sure thatyou're handling objections that are onthe path to them actually figuring out if they can use you.If they know outright that they'rejust not going to use itand you're handling objections,you're wasting their time and yours.

If the objection is realand they really are asking the questions,trying to figure out how they're goingto use your product and this isan objection that's holding them upin 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'recharging per user — we don't charge per user — and they're going to have a million usersand they're worried that you're going to belike $20,000 a yearor $20,000 dollars a monthor something like that.Understanding if it's a misunderstanding is importantbecause you can just quickly go in there,nip it in the bud and move on.Often times this happens.

For the same reasons you confirmthe things you hear from your customersto make sure that you didn't misunderstandwhat they said, you just want to make surethat 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 budgetor your customer can't use the Cloudfor regulatory purposes or something like that,and it's really a show-stopper, now you knowand 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 exampleand then you check with themto make sure that it worked.If it is a real disadvantage own up to it.The worst thing you can do is to startdancing 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 investmentwill you be willing to move forwardwith 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 isbecause here's the thing, if you hide it or you convince themthat it really isn't an issueeven though it really isand they buy your product,you are going to be in a world of painbecause then maintaining an angry customer,especially today where theyblog and they tweet — not good.Make sure people knowbecause here's the thing.

Your customer might walk away from that meetingbelieving 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 monthsor a year when they try to do whateverthe alternative to your product isand it failed and it was a disasterand they rethink what they were going to doand hopefully your product is sufficiently importantwhere they could not do it properly themselves, they'll call you back.Now, because they know what your pricing really isor they know the limitations thatyou really do have,they may have rationalized those awayand now they're contacting youand they're cool with those things.So, own up to them.

Once you think you've handledthe 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 objectionsthroughout the entire process.You're not going to get it at the end.You're going to get it from the beginningto the end at every single stage.Every time you bring up a questionthe chances are that you're goingto 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 applicationthat 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 throughthis 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 meaningfulconversation with your customeryou're going to run out of time.You want to identify the questionsthat were left over.

If they have questions for youthat they didn't get to coverand maybe you have questions for themthat you didn't get to cover, clear it up with them.Show them that those are the questionsthat you have and you're going to email themand maybe ask more questions.You're going to schedule timeto have another conversation and cover those.

Then the important part is,you want to make it really clear to themwhy they should continue with you in any regard.Whatever that next step is,you want to summarize for themwhy 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 arethe busier they are.

You want to say,"Hey, let's meet in a weekbecause it sounds like you've got a problemwith speed to market and it sounds likewe might be a solution for youand if we can work togetherwe 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 spaceor there's other alternative solutionsin the space and you want to reiterate to themwhy 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 messagesyou picked up in the call:You heard that they've got thisthree-month deadline.You heard that this is costing themX number of dollars.You heard this, this and this.Reiterate those to them.

Reiterate anything else that you thinkis really critical for them to knowthat matters for themin the context of that sales call.

Then again, it's not just easy enoughto say we'll chat again. That doesn't work because your customerwill 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 officefor a demo and I'll include these guysand you bring these guys."

Really try and articulate what thatnext step is going to beand if possible try and nail it down in that callbecause, otherwise, you're doing it via emailand everybody's busy and those emailshave a magical way of falling apart.

This sounds obviousand it sounds like lip service,but thank your customer for their time.There are anecdotes that are really powerfulof customers literally ending sales callswith their sales people and being upsetbecause they didn't get a thank you emailor they didn't get a thank you of any kindand they were offended.This happens.

It may not happen as muchout 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 cardis actually quite powerful.

I remember sending thank you cardsto my customers sometimesand they would bring it up months later.They'd be like "Remember when yousent 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 happyto 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 havetwo different sales teams.The sales team should be specifically your founding team, nobody else.Once you're a little bigger andyou have more people, maybe you're bringing in like your VP of marketing,somebody who deeplyunderstands your product. Bringing in multiple peopleinto a sales engagement can complicate things.

Particularly in a sales call, havingmultiple people in a sales callhinders your ability to control that call. But once you're larger you'renot going to be able to scale that way.There aren't enough people in the worldthat are going to be technical and skilledat 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 seenand 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 wasI 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 enoughto understand what your customeris trying to achieve.If your sales team isn't sufficiently technicalto actually understand your customer's problemsand be able to do what we talked aboutand actually whittle them downto a really specific pain and a costand a need and they don't understandthose 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 canactually have that conversation.

Assuming you have those guys to havethose conversations they should do allthe need analysis, as much of itas they possibly can.In that same spirit, if the call allows it,or the sales process allows it,they should do the very initial explanationof 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 beon the API call?How am I going to model this particular use casein your API service?How am I going to store this data?How am I going to migratethis system to that system?That's what a technical sales repshould be really good atbecause that's no longer sales, that's more sales facilitation. So your sales guy you don't want himbogged down in those thingsno matter how technical they arebecause then you're wasting the salesperson's timewhen they could be talking to more customers.

Even we do this too,as technical as I am and as muchof the product I've helped build,I still bring in my co-founder, my CTO,the chief architect.I still bring him into sales callsevery once in a while.The value there is if I know I'm talkingto an extraordinarily technical personor the use case is really complicated,because I prepped,I'll bring him on and he'll just bewaiting in the wings.He'll be paying attention.He doesn't have an active role in the callunless 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 ofis that the salesperson will bringthe technical salesperson into every call they havewhich, one, is extraordinarily inefficientbecause sales engineersare just as busy as sales people.Two, because the salesperson isn't thattechnical they'll open the call,they'll close the call,and they'll let the technical salespersondo everything in the middle.

Which is also really inefficientbecause most technical sales peoplehave not been trained in handlingneed analysis and proposal.They're good at understandingspeed and feeds and helping peopleunderstand how the migrations are going to work.So you end up with a veryinsufficient sales process.This is actually how most large enterprisesales guys actually operate unfortunately.Even at the biggest companies out therelike 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 notebookwith him at all times and writing stuff down,don't hire that guy. Especially when you're doingtechnical sales, you're not hearing things thatyou're just going to remember.

When someone tells you like the API call they're trying to make,that's something that's really specificand you need to take that note downbecause it might sound like you'regoing 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 notesand then summarizing them is really important.The way that I used to do it,and this is how I was trained to do itat IBM, was: I would take my notes.I'd summarize it into an email back to the customer.Then I'd take that emailand I would put it in the CRM.That's a lot easier these days becauseCloud-based CRMs allow you to basicallyjust bcc the CRM and now it's justautomatically in there. That's the way that I thought to bemost efficient with my time.

It's great becausethese 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 stuffin one centralized location like a CRM,no matter what it is,is important because if maybea customer goes dark on you for four monthsand they come back to you, you can easily goin the CRM and see the entire history of theconversations 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 itin a weekend, they're not going to be your customer.That's accepted. That is somebody who doesn't necessarilybelieve they have a painand you're trying to convincethem they have a pain.I'm sure that you might have a silver tongueand might be willing to spend all this timeconvincing them that it isn't worth them doing,but you've got better things to do.If you don't you probably haveproblems 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 backto this call model that I showed you. If you're actually competing with something,if you're going in with a customerwho already has an alternative solution, whether it be a competitor or just someorthogonal way of doing it,you can start at capabilities.

You say, "If you build it yourselfwhat 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'rethinking about that.Almost always there's a problem withwhatever they pick.

All products are imperfect.If those imperfections alignwith a big enough pain that you can solve,then you can basically go through this modelwith them regarding those things.

"If you build it yourselfit's going to take you nine months.What if it only took you a week?"

"Oh well, God, if it took me a weekthat would be really cool."

Obviously, it may not be that easy. "If it took you a week what would bethe value to you?How would you put a price tagor some sort of quantification on that value?"Once you hear that you start divinginto the beginning of this thing from the very topand 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 youin that meeting becauseif there's other people they have to convincethat means you're not talking tothe 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 appropriateto 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 morebefore I introduce you to them."If that's the case then make sure that you identify, "What would it take for us to geta meeting with them?"They'll tell you and if they don't havea good answer it's probably a bad sign.

The ultimate goal is not necessarilyto fully prep them,though you should.I mean, you can hand them documentation.In the API services world it's almost alwaysan issue of documentationor 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 teamor build it yourself to generatethose kinds of documentsand just have them at the ready — product guides, whatever.

A lot of stuff can be handled with collateral,but almost always if there areother people involved you need to workto get a meeting with them.

To that end I'll add one more thingwhich is,

Just because you can havea sales meeting with somebody,just because you can go through a sales processand maybe after thisyou 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 somebodywho is smalland you're already past theproduct validation stage, now you're actually trying toscale 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 ideaof 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 documentationand 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 awkwardand it turns out the QA lead maybewants to outsource it.First off, is that person reallyagainst your product or not?You will have organizations where peopleare against your product.It happens. It happens to us all the time.There's a sales terminology for that.They're called saboteursand 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 dayin your scenario the question iswho gets to decide?If the decision is ultimatelythe VP of Eng then don't worry about it.Understand that person,understand what you think they're going to sayagainst your product,not necessarily disparage it,but the argument they're going to makeagainst using you. And make sureyou're prepared for those.

Put forward the best case you canbased on the ROI that you hopefullyhave developed over the processof the sales engagementand present your case to the VP of engineering.

Look, if the VP of engineering brought you into have a sales call and it's gonefor more than just one call,it means that he probably understandsthere's a problem and is looking for a solution.Take comfort in the fact thatyou've gotten this far despite that awkwardnessbecause there's a real painthat you're going to solve.

Alternatively, if you're havingthat high friction between those two people,it might mean that you're talkingto the wrong person.Maybe it's the CEO or the CTOwho's ultimately going to be the tiebreakerin which case you should havea conversation with him.