Tales from direct sales email outreach

Direct email outreach is one of our sales channels: we find data scientists working at interesting companies and email them. We've refined our template through a few iterations and A/B tests to the point where we get a response rate of over 5%, which seems reasonable. But we also get some perplexing responses. I wanted to share some of them, not as sour grapes, but because I think they shed light on some of the challenges involved selling enterprise data science software. Just to be clear, I am not complaining; I'm sharing -- for two reasons. First, maybe people will have suggestions. Second, this might help others trying to do enterprise sales.

Here are some responses that represent some recurring themes we run into:

Build it ourselves

By far the most common rejection we hear is "no thanks, we build our technology solutions ourselves." Here's an example:

Hey Nick,Sorry for the delay in response. I have chatted with a few of the developers here and they have decided to tailor build our platform in house. I am not entirely sure why, but this has been a common trend with [company]. Thank you for your time though.

Or another example:

Hi Nick,Congrats! Seems like an awesome product, my team was definitely impressed. I don't think it's a fit for us as we prefer to homegrow and err on the side of needing control but would love to let you know if that changes.

Or simply:

We have already built (and continue to build) the in-house technology we need.

My thoughts on "buy vs build" could fill a long blog post on its own, but here are a few:

First, it is not at all surprising that developers prefer to build their own solutions. Most developers are developers precisely because they enjoy building things, and most companies have a culture that rewards people for doing things, rather than finding optimal solutions based on overarching business goals and constraints. So asking a developer (or even most engineering managers) "would you rather build a solution or buy one" can be misguided, because it isn't natural for them to weigh all the factors to make that decision optimally — instead, they have a certain intuition. When you have a bunch of hammers, you find reasons to nail things.

Second, I think a principle like "we generally prefer homegrown solutions" is sort of meaningless without more qualification. You will always be buying some software and building some software. If you think you really prefer to build your own solutions, ask yourself if you built your own programming language, word processor, email client, operating system, database server, IDE, firewall software, etc.

Whether to build your own solution should depend on how important and differentiated its functionality is to your business.

You should build a homegrown solution if you are addressing capabilities and use cases that are unique to your business, or so central to your competitive advantage that it's critical that you are in complete control of them. (And, of course, even that is dependent on your having the engineering capacity to deliver and maintain the solution yourself.)

Conversely, you should consider buying a solution if you need functionality that is largely commoditized, i.e., many other companies need to do the same thing.

Two observations about this:

1. Many companies we encounter think their use cases are more unique than they actually are. Most people want to think that "the way we do things" is special -- but often it's not much different from what other companies do. In our specific context: of course your company's particular analytical models are highly differentiated, but that doesn't mean that you have unique needs to support your data scientists who are building those models.
2. Many companies dramatically underestimate both development costs and the total cost of ownership when considering the buy-vs-build tradeoff. Development costs should include time from business users to engage with requirements and acceptance testing. They should also include opportunity cost of taking those developers off of other possible projects. And total cost of ownership estimates should include developer resources for ongoing support and maintenance.

Underestimating the work to productionize functionality

Here's an exchange with a prospect that actually implemented a working proof-of-concept with Domino. In about an hour, he got his use case working (exposing a Python predictive model as a web service for consumption by an existing web application). But the decision-makers at the company decided not to use our service. Here's what we heard back:

As I understand it, the reasoning was pretty simple - they didn't want to be dependent on an external service that they would have to pay for when the exact functionality that they need is achievable using ZeroMQ and some shell scripts.

I think this indicates an underestimation of what it takes to really harden an application for production use. Slapping together ZeroMQ and some shell scripts might work for a prototype, but there will be real engineering required to ensure the solution meets the company's requirements for availability and uptime; that there's a good story for deploying new versions; and that the company has the internal knowledge required for support and maintenance when issues inevitably occur.

The "have to pay for" part of his rationale also seems misguided. It will certainly not be free to implement a custom solution with ZeroMQ and shell scripts, in order to integrate a predictive model in Python with an existing Java web application. Aside from the up-front work, there will be the ongoing drawn on resources for support and maintenance.

Processes over outcome

A very large consulting firm wrote back to say they weren't interested in learning more about Domino because:

We are pretty far down the path evaluating several different technologies in this space and don’t want to incur the cost of spinning up another.

With all the objectivity I can muster, this still seems illogical to me. If you're going to make an important decision and invest months (and probably man-years) of time to find a good solution to your problems, isn't it worth taking 30 minutes to learn about another possible solution? In expected value terms, that seems like a no-brainer.

I'm not sure if this is symptomatic of anything deeper, but my instinct is that this is reflective of bureaucracy at large organizations. There's a disconnect between the ultimate business goal and all the activities on the ground. Rather than seeing an opportunity for a better business outcome, someone sees a distraction from a process he is running.

Unfortunately, I don't have good techniques to disarm these reactions — indeed, disarming them may be impossible, since most people won't change their minds when they're convinced of something. But if we figure it out, I'll share our insights in a future post! If you have thoughts, post in the comments or send us an email.