OnStartups

Before we go too much further, let me explain a bit further what I mean when I say “competing with customers”. Although the concept sounds like it should be controversial (which startup in their right mind would want to compete with its customers?), it really isn’t.

What I mean by “competing with customers” is when the customer has the option of “doing it themselves”.  This is very common in niche sectors of the enterprise software industry.  One example would be my first startup, where I sold pretty high-end software to very big customers.  When I first started the company, my primary competition was not other startups nor was it other big software companies (liken an Oracle or an SAP).  My real competition was the customers themselves.  In the enterprise software business, your prospective customers more than likely have more development resources than you do.  They have hundreds of programmers (perhaps even more), lots of infrastructure support and fairly large IT budget overall.  The decision they are often making is not “should we buy this software from Company A or Company B”, their decision is often:  “Do we buy this from Company A or do we build it ourselves?”.

Now, what I’m finding interesting is that although I am no longer in the enterprise software business (for which I am very appreciative), I am still encountering this “compete with the customer” phenomenon.  In my current startup, HubSpot, we are targeting the small business market.  Even in this market, we encounter prospective customers that feel like they could “do it themselves” instead of licensing software from us.  The situation is a bit different because the alternative they are often considering is not actually writing the code, but “piecing together” a total solution by pulling together inexpensive or free components in order to solve their problem. 

I’m still in the early stages of the HubSpot lifecycle, so I’m going to focus most of my points below on the enterprise software side that are making the “buy vs. build” decision.  However, I’m guessing that when I’m done, most of the points will still apply if you are competing with customers that will “integrate” off the shelf components to try and replicate what you have.

How To Compete With Your Customers

1. Accept That They Can Do It:  It is very, very tempting to discount or dismiss a client’s ability to compete with you.  As startups, we have any number of rationalizations to convince ourselves of this. Here are some sample arguments:
1. The are too big, they’ll never be as nimble as we are and solve this problem.
2. They don’t understand this problem like we do, it’s hard and they won’t pull it off.
3. Although they have a ton of IT resources, this division will never be able to get their internal project approved.

I’m sure if you thought about it for a while, you’d come up with a few more reasons why you believe the client can’t really compete with you effectively.  This is a dangerous line of thinking.  Not because you’re not right (because you probably are), but the single worst way to handle the situation is to try and convince the customer that they can’t really do it themselves.  The key is to convince them that they shouldn’t do it themselves.  More on this later.

2. The Core Competency Argument:  The phrase core Competency Is clichéd but true.  Your best line of reasoning is to ask a simple question:  “Ms. Client, Although you probably could build build/integrate this software yourself, is that really the business you’re in?”.  Of all the things that you (the customer) could be doing to grow your business and differentiate, is solving this problem really where you should be spending your time and resources?  You can even be brave and insert the word limited “i.e. limited time and resources”.  I don’t care how big you are, everyone believes their time and resources are limited (because they are).  In my experience, you will find companies that simply don’t “get” this argument (and they have a library of rationalizations why doing it themselves is “strategic”).  I personally like to sell to the other group of companies.  The ones that are more likely to succeed.

3. The Heroes and Legends Argument:  I used this argument a fair amount in the enterprise software business.  If you’re competing with your customer in the “buy vs. build” kind of situation, more likely than not, you’re really competing with a relatively senior IT person.  (Rare is the time that I’ve had a VP of Sales at a Fortune 500 firm try to convince me they should be building their own software).  So, you need to know put yourself in the mind of the IT person.  The single best way to often convince them that they don’t really want this project is because it’s not glamorous, fun or exciting.  My line of argument went something like this:  “Joe, this stuff is really ugly.  Do you really want to spend the next couple of years writing those boring enterprise app that does <x>?  Even if you succeed, is this project really going to make you a hero and a legend to your executive management?  Is this really the project that you’re going to be able to attract your best talent to inside the organization?”.  In my experience, this is a very effective argument (particularly when it’s true, which in our case it was).  Lots of times, IT people don’t want to do things that ugly, boring or out of fashion.  They want to work on cool stuff that has high visibility and measurable impact to the organization (that’s where bonuses come from).

4. The Risk / Reward Argument:  As a startup, you have one big advantage over your customers.  This problem is what you are spending all of your waking hours on.  The client, on the other hand, has a hundred other worries and projects going on at that time.  If your startup is in the early stages, you often have a severe price advantage over your potential clients.  Everybody knows that it is much cheaper to license your software than try to do it themselves.  Often, the worry is not price:  it’s lack of control and “risk”.  If you can somehow mitigate the risk for the client (which is deserving of an article of itself), you can tip the odds in your favor.  In one instance, I actually made the bold argument that the client should go ahead and kick-off their own development project (which they did), but license my product anyways, because they could characterize it as “R&D” expense in the larger project.  Basically, my argument was that we’d be evolving our product anyway, and even if they did want to build it themselves, they’d likely learn a lot from us.  (This is a bit scary, but tempered by the fact that the risk of the client actually licensing their software to the market and competing with you in reverse is very low).  The client actually accepted this argument, licensed our product, did their own development project (which did not end up where they wanted) and ended up being one of our best customers over a 7 year period.

That’s all I have for now.  There’s definitely a lot more to say on the topic, but will save that for a future article.  What are your thoughts?  Do you encounter this challenge at all in your startup?  If so, how do you tackle it?  How do you convince a prospective customer that they’d be better off letting you (the expert) deal with this instead of taking a “do it yourself” mentality?  Would love to hear your ideas in the comments.