Monday, August 6, 2012

Building Products for the Enterprise Market

"Large companies are quite price-sensitive... Corporations will always base their purchase decisions against their internal cost of building the same products... You're out of the running if you use the wrong technology."

A week ago, I listed a set of topics that I would write about soon. I'm excited that I'm already getting to this particular topic, but I also feel bad because my startups need TLC and I'm procrastinating. So it goes.

Note: This post is based on anecdote and my experience inside several medium and extremely large companies. If you have your grain of salt ready, then lets get started!

1) Believe it or not, large companies really are price-sensitive when it comes to buying products

I know that nobody in software likes to say this, but its true. After all, companies are staffed by individuals who bring their own biases when researching software solutions. Often, large companies are price-sensitive enough that in the world of B2B and B2C marketing, they like to lump these folks in with the B2C market so that it doesn't destroy their marketing paradigms. But, it really is surprising, having worked inside large companies, how very price sensitive they are.

Now, a large company isn't going to balk at a one-time purchase that varies $20 to $50 from the low-end solution, but they do get consternated about cost differences when it scales. So whereas in pricing your product you may think in terms like "I can sell this company a 10-seat license. At $50 per-seat license, their costs will fall in the comfortable range of $500/year", they're thinking "Well, geez, what if we expand and roll this out to 10,000 users, those $50 per seat fees are going to eat us alive!" Businesses in growth industries tend to translate those prices into a much larger multiplying factor than what you may be targeting, even if their current expected number of seats makes your software interesting at first. So if you're selling per-seat licensing, at the very least you may want to include price-breaks at certain levels to bring that price down into tolerance, because corporations will make somewhat ridiculous calculations based purely on a potential for expansion.

I worked for a software product company once where we brought in a reporting-solution vendor that we were considering for integration into our $30,000 application. Understanding our price points, they wanted somewhere in the neighborhood of $100 per installation. I had done the evaluation and the company demonstrated every kind of integration we wanted and it played very nicely with our software. I was surprised when the vendor came huffing out of a close-door meeting along with his regional sales manager and our marketing team. They seemed quite put-out. We wanted a price in the range of $30 per installation, 0.1% of our install price.

2) Corporations with IT shops will always perform a buy versus build analysis

Oftentimes, it isn't even important that they can get the software 3 months sooner by buying it from you. Some companies certainly may have what they call a time-preference, and it matters a lot to them to get things faster. But companies are so used to buying software that takes months to integrate, and are so used to planning months in advance for things, that unless it solves a real pain point right now, a time preference just doesn't factor in as an advantage for you. But, where you can almost always compete is on a price basis that is relative to their internal costs.

Where I worked before, they had internal per-hour costs of between $75 and $100/hr. So whenever they would estimate something, they multiplied the projected number of hours to complete by those per-hour values to arrive at the estimate. That will be the basis of comparison. If the cost is less or it's about the same as buying it off the shelf, and it creates a new internal capability for them, then they'll choose to build instead of buy. If the cost to build it internally, after factoring licensing and consulting support costs, if it costs less, they will build it themselves. So, there is a limit to what companies will pay. It's not as subjective as you think.

Another caveat: If you are selling a completed large software package to a business with an IT shop, then there is one extra benefit where you can capture enormous value that throws out the whole "What would it cost if we built it?" calculation. That benefit is that the product is complete. And by that I mean you successfully built it. This is a benefit because corporate IT has a long history of failed software projects, and they tend to have doubts about their ability to build fairly complicated software internally. This is probably where the most blue-sky is sold in software. If that isn't the primary driver for IBM's and Oracle's success (its probably brand at this point) then its a secondary reason.

So it may seem arbitrary from your perspective, and you think "Geez, companies really pay a lot for software", its really not arbitrary at all. Its just that their tolerance for paying is based on their internal costs. Its not really a value perception, its whether they can build it or not or whether they will get any other benefit from building it themselves (such as training the new guy to develop apps).

At one very, very large firm, I was tasked with evaluating mobile asset tracking software. The vendors were very astute. They were charging very close to what it would cost us to build the same solution, so to us the pricing was very reasonable, and it had the added benefit of ongoing support and limited upgrades. However, they lost the bid simply because we felt like we wanted to develop the mobile development capability within our staff.

3) You're out of the running if you use the wrong technology

The #1 requirement you're going to run into all the time is that companies want to self-host their solutions, and if they want to self-host, they'll probably only tolerate 3-4 technologies. Generally those technologies are:

  • .Net
  • Java
  • +1-2 random scripting languages (Perl, Ruby, Python, etc). Typically, these are only used for batch scripting, so don't get your hopes up.
If you're building a product that allows large companies to self-host, congratulations, you're halfway to an acceptable enterprise app. However, if you wrote the application server in Ruby, you probably won't have much success selling it. This is because companies won't want to have to bring their staff up to speed on Ruby to support it. So if you're going to write self-hosted client-server software for large enterprise, you need to consider building your product in Java or .Net. Also, you better build your software with the idea of integration with their existing systems otherwise, again, you'll be out of the running.

More about architecture considerations in an upcoming post. Also, in an upcoming post, we'll talk about an actual list of ideas for products you could build for this market.

[1] Note: We are really talking about price-sensitivity as it pertains to total-cost-of-ownership. In per-seat or per-installation licenses, they go nuts when the price is $20 more, but 1-time purchases create much less chaffing, even when there is an order of magnitude of price between competitors.

1 comment:

  1. Hi, Great.. Tutorial is just awesome..It is really helpful for a newbie like me.. I am a regular follower of your blog. Really very informative post you shared here. Kindly keep blogging. If anyone wants to become a Java developer learn from Java Training in Chennai. or learn thru Java Online Training India . Nowadays Java has tons of job opportunities on various vertical industry.

    ReplyDelete