Very timely and accurate. Echoes from Chasm and Blue Ocean Strategy. Sometimes we forget who our competitors are.
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?
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 :)
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.
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.
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.
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.
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.
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!
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.
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.
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.