Startups: How To Compete With Your Customers

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Startups: How To Compete With Your Customers


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.


  1. 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.


  1. 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).


  1. 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.







Posted by Dharmesh Shah on Wed, Jan 24, 2007


Very timely and accurate. Echoes from Chasm and Blue Ocean Strategy. Sometimes we forget who our competitors are.

posted on Wednesday, January 24, 2007 at 11:58 AM by Perry Ismangil

These words really ring true. From my perspective it is as much about what is wrapped around the software. OK anyone can do the programming, but what is attractive about getting you to do it?

posted on Wednesday, January 24, 2007 at 12:22 PM by David

This is a great idea, not only at the enterprise level but sometimes even trying to simplify a solution for a customer.
The are many many free tools becoming available and the piece-together approach takes MORE knowledge I find to do it properly - especially if you want to "hide the edges" and make it look like one customized result!

The only danger hole I find is support, so once the customer does piece or build something themselves who really is going to be the one to support it?

The 'glamore' of development usually it believed to be far from the 'pits' of the helpdesk :)

posted on Wednesday, January 24, 2007 at 12:33 PM by Clinton Boyda

We get this a lot, especially because we sell software development tools (to software developers). For us the "it's a dirty job" argument is good. For example we integrate with version control systems, so I just have to start listing the various little things you have to do to integrate properly and they get the idea. The other technique is to bombard with features. We have a mature product with lots of integrations, client applications, and so forth. So e.g. I can say "You can upload files from Eclipse, or our Windows GUI, or the cross-platform command-line client, or with Web Services, or with our Java Client Library, all of which is already fully documented in this on-line or printable manual." Bombarding (but with good, useful stuff of course) is good because it throws in their face the magnitude of the project they believe will be so easy to "knock out." The counter-argument is "we don't need all that anyway," but if you're in a room with 4 people they'll each latch onto a DIFFERENT set of 4 things they like; to satisfy everyone they can either buy our tool or suffer with something that in fact does not satisfy all their "customers." Finally there's the update argument. When Perforce comes out with a new version, we get it early and we can test and update our software before any customer sees it. They would have to chase this constantly. It's fun to think about making a new skunk-works project but it's not fun to think about these issues.

posted on Wednesday, January 24, 2007 at 6:53 PM by Jason Cohen

How about a 'Value Added Partnership' argument? It's essentially a mash-up (to use web2.0 speak ;) ) of the 'Core Competency' and 'Heroes and Legends' argument.

Sell your product as a tool that in the hands of your customers IT department will produce spectacular results for the business.

No software is an island so it will take the skills and expertise of the IT department to deploy the product, provide first level support, develop any interfaces for integration to other systems, provide training, etc.

posted on Wednesday, January 24, 2007 at 7:21 PM by Scott Carpenter

This is a very well thought out argument. I think it applies well beyond the software business. For instance, if you are in a service or consulting business, the customer always has the option to hire a resource to do whatever it is you are proposing. I think the same arguments apply, and I think in this situation it is even more important not to argue about the customer's ability to provide the service internally. In these services or consulting sales, I would add an argument that an external, unbiased point of view can add significant value - I'm not sure that you couldn't use that argument in software sales as well.

posted on Thursday, January 25, 2007 at 10:57 AM by Andy Blackstone

Great post Dharmesh. We sell an Excel add-in to a relatively non-technical audience, and we also come up against this problem - even if you don't sell to developers you're not safe! One approach you didn't mention is the purely cost-based one. "How long would it take you? What's your time worth? You really don't want to just buy our solution...?". I guess the effectiveness of that approach would depend on your market - developers are often pretty unaware of the monetary value of their time. Unless, perhaps, they're running their own business, or consulting.

posted on Friday, January 26, 2007 at 5:41 AM by Martin Bromley

Most customers can do it themselves. There are 3 main reasons to buy vs. build in my experience. 1. You (as the provider) can do it for a lesser cost. Figure out what its going to cost the customer - do a real estimate and dont use made up numbers that are inflated. The basic assumption is that you can cost average over selling the same thing to multiple clients versus your customer trying to do it once for themselves. 2. You as a provider bring specific expertise that the client cannot obtain in the time frame they need to deliver on the project. They could still hire someone else who has that expertise but then you differentiate yourself from that other provider. 3. You as a provider has the benefit of "best practice" of learning from multiple other clients that face similar or same problems. Hence you have been through "most" problems that your client is going to face anyway. At the end of the day if you dont provide something "better, faster, cheaper" there's no point in buying vs. building.

posted on Friday, January 26, 2007 at 5:52 PM by Christina Murphy

Oh man, yes I know what you're talking about!
In our case, we are an internet video niche network. We broadcast almost all of the quilting (we're starting with that group and expanding to crafts) content there is, and we produce our own. What we provide is a distribution channel for how-to programming for crafts enthusiasts. ( Although the business model goes beyond that.)
Early on I came up against "But I have video on my site." Right, agonizingly slow Windows Media and Real Player video. It isn't about the video, it isn't about people coming to one site. Our industry is all abuzz about growing by reaching new crafters. Of course, the way to do this is to get making things and the success of making something in front of people. It's about the industry getting out there to give as many people as possible that exquisite feeling of, "I made this!"
Our advantage is we aggregate eyeballs and riccochet them throughout crafting on the 'net creating a web-wihtin-a-web. We get nowhere as an idustry fragmented, with bits of video here and there.
We're launching a nifty new proprietary player our parent company has recently introduced called 'Vidego" that will serve to connect all of us. It can be customized any which way, and easily planted anywhere. Like placing a little video crumb trail, some with RSS feeds, others filled with a company's content, but all pointing back to us, the hub.
What's interesting is that even in our industry, companies are getting that promoting the craft is the best way to promote themselves.
Thanks for the post. it's always nice to your not alone!

posted on Friday, January 26, 2007 at 9:47 PM by Jodie Davis

Invaluable perspective indeed. 'I can do it myself' is always the first resistance by many when you approach a customer with a solution. Its not limited to Small Businesses, but a well known problem in the developer community as well If you look at all open-source projects, one will immediately realize they are no different, not to that extent it needs a different project. Most probably, slightly differently implemented.

posted on Saturday, January 27, 2007 at 12:39 PM by Murali

Dear Dharmesh, A prospect who is saying 'we can do it ourselves' is someone like a dog which barks but does not bite. He/she is only saying that he /she can do it and not will do it. a person who will actually do it will not say it. I have met people who actually said 'I can probably do something like this but you would have done elaborate testing and that makes it a different class. I would rather buy than reinvent' At best, it is a lever in negotiation from their end and at worst it is nothing but sadism, wanting to demolish the other person's initiative. I remember the first time i encountered this specious objection and i also remember my counter 'Perhaps you can but do you really want to?' and that closed that line of reasoning. Over time, I have learnt to distinguish the enthusiastic beaver and the 'I know it all' type. With the former, I spend the time giving them a peek into the finer nuances of my products and educating them of the research and work that has gone in. With the latter I just shrug that indicates 'be my guest'. Thanks for the sharing.

posted on Thursday, February 01, 2007 at 11:26 AM by Badri

Hi Dharemsh, A very valid point here. As far as I have observed enterprises want their things done better, faster and cheaper than if they were to do it themselves. If all of the above concerns/desires of the enterprise are addressed by the software firm (in their sales argument), I believe the potential customer can be converted to a customer and the sales closed. Better: I believe this will assist in getting into the door, but not close the sale altogether. Cheaper: Building it by themselves may be an expensive affair initially, but over the long run building a software in house saves a lot of licensing and maintenance costs (exceptions are there), but the cost is never that a concerning factor for the enterprise anyways. Faster: I think this is the most important of the all. And your points 2, 3 and 4 are are on similar line. "Time-to-market" is the single most critical thing that big firms confront. Additionally, after sales support, thorough-put of bug fixes, enhancements and support in integrating the software with that of the customer's IT setup will definitely help. On a side note, I am hit by a question. How developed/mature should the software be at the start (during) of the sales process. Too little features effects the time-to-market factor. Fully developed software leaves the IT firm at a risk of developing something which could be very far from what is needed by the customer.

posted on Monday, February 05, 2007 at 12:49 AM by Shabbir Husain

Comments have been closed for this article.