If there's a techie on the phone, keep it real

Hope this post doesn't go too far down a sales-thought-leadery path… mostly something to get off my chest based on a few recent experiences.

My clients often invite me to product demos — that is, demos where they're the prospect — to add color/understanding/skepticism to the discussion.

This usually means the other side ropes in their own techie, whether willing or not. (The “Look, my VP of Engineering just walked by” moment is so common it seems faked. Anyone have inside dope on this?)

But what happens next, more often than not, is their tech saying things that are either so preposterous or so dumbed-down they make the sales experience much worse overall.

Now, some part of the responsibility lies with the salesperson, since anytime you grab someone away from their work without a warning, there's tension built-in. And the engineer is probably no good at selling and shouldn't be expected to be. Someone else should have that technical sales job, and they should be the one brought in.

But here's what's interesting: it's not the stereotypical asocial engineer personality that gets in the way. (Heck, I live that personality a lot of the time, and I'm used to being around it.)

And it's not like a sale would suffer from an excited exchange of interesting-only-to-us info while the non-techies nod off. (Since I usually have product recommending ability, it's good for me to be excited.)

It's that the techies try to sell me a lie. And sometimes such a transparent lie that I actually think they do think of themselves as salespeople, in the worst possible way.

Example 1

Today the PM for a well-known SaaS platform uttered the following sentence on a sales call:

We're looking into REST, but for security, SOAP is actually more secure than REST, because of some other information that is passed in the request.*

I had asked why this company's Marketo integration was still using the SOAP API instead of Marketo's REST API, since SOAP is both less secure and deprecated.

For technical context, using the SOAP API gives an an outside company root access to your Marketo instance. That's read-anything, delete-anything, destroy-everything access. Does that mean they will deliberately abuse that access? Of course not. But if their code has a tragic bug, you're the victim. If they're hacked — and we should take that to mean when they're hacked — they have your SOAP credentials stored in their database. (And it's impossible for them to be irretrievably encrypted, since they must be converted to plain text to be put on the wire.)

Further, if your Marketo SOAP credentials are compromised (or merely that you stop doing business with a provider who has them) you have to generate new credentials. And you have to send them to all of your integration providers and have them migrate at exactly the same time.

REST, in contrast, allows for tight control of exactly what the outside provider can access (if they do need write ability, they can get it to only a narrow section of the instance). Plus it allows you to audit usage by each individual remote app, and to discontinue/regenerate creds for just one app without affecting any others.

So this supposed technical authority responded to a fairly innocuous question with an answer that comes off like I'm a liar, I'm an idiot, I don't respect you, or all of the above.

All he had to say was this:

You're right, we're still adapting our technology for REST, and be assured that we too are concerned about the security issue with SOAP.

More long-winded but still honest:

You're right about SOAP and we'll be on REST soon. In trying to build brand-new functionality, we've found that the REST interface has bugs in some recently added endpoints. That made us second-guess whether some of the older endpoints were working as they should.** That might have been an unfair judgment so we appreciate the poke.

Example 2

Last week, I was on a call with someone offering a new Marketo integration for their landing page service, including pre-fill via API. Now, bear in mind these are people whose technology I already trust for syncing to ▓▓▓▓▓ ESP. You'd think it would be a slam dunk.

I ask the (non-sales) tech how they're going to manage daily API calls.

“Look, here's my developer,” he says instantly, forcing me into the did-that-just-happen mindstate that doesn't lend itself to generosity.

I ask the dev, kind of feeding him the answer I want: “So, hey, I'm concerned about the number of API calls per day since we're already using API calls for other integrations. Can you limit the number of calls you use per day? And are you caching?”

There's no need to limit. You'll never hit the limit. What do you get, 100 conversions per day?

I note that not just legit users but malicious users have to be considered. And also that at moments of peak activity, the client might get 1000 conversions a day, easily. And that supposedly they're looking up leads (by Munchkin cookie) every time somebody views a form, regardless of whether they fill out the form.

We restrict the number of connections by IP, so someone can only fill out a form once per day.

I point out that if you take Marketo's guidance (which is hardly generous) this still means you have to allow for up to one form post every 30 seconds per unique IP because of NAT. Unless adjusted by time of day, that's 43,200 API calls per day per IP. With only 30,000 calls to give in total, that's obviously not a useful cap.

We have enterprise clients and they don't have a problem.

I gave up at this point and said we had a hard stop.

In this case, the techie wasn't as profoundly deceptive as in Example 1, but defensive because he was unaware of Marketo's API limits prior to the call.

Strange as it is to not know about the limits, rather than denying reality, he could have acted the part of a modern, security-conscious developer. I had given him an out: I implied that if he could cut off the API calls at a certain number so they wouldn't affect other integrations, we were okay (for the time being) with the fact that we'd be losing leads after malicious and/or overload conditions.

If he wanted more info, he could've said:

Sorry, I wasn't aware of the rate limits. Can you tell me how they work? They're not per-application?

Or just believe me and skip to:

Appreciate your bringing that to my attention. We can definitely implement a hard daily cap and later on think about adaptive rate limiting.

Note he didn't even have to say when they'd add a usage cap, just admitting it was a good idea would've sufficed.

So then…

In Example 1, I still told my client (who was pretty deep in the sales cycle) that they might as well go ahead with the purchase, since aside from the security concern the product seems to behave as advertised. But will I recommend the product to others? Shaky.

In Example 2, I told the client in no uncertain terms that the vendor is not to be trusted. (Note the client is in the managed security sector, where they expect vendors to understand they're a hacker target.)

And in both cases, the non-techie salesperson had been doing okay. All it took was a little honesty from the techie to close the deal and leave a good taste.

Notes

* I assume what this person was getting at — though he's wrong — is that data types aren't automatically validated with REST during the HTTP transaction. (This is true in a generic JSON acceptor, just like in a generic form-encoded POST acceptor, but technologies such as JSON Schema exist to validate input.)

** This is my own thought process about the state of Marketo REST, btw.