Forget Virality, Selling Enterprise Software Is Still Old School

Although I agree with a lot of the advice in the article, there's a "new school" of enterprise too, and ideas like virality from the consumer world often apply to the new enterprise.

"Old school" enterprise sales meant hiring an army of field salespeople. It meant on-site visits, and pitching directly to the CIO, CFO, CMO, hiring sales engineers to build pilots, negotiate with procurement for months, etc. And all that meant the cost of a sale was high -- often $50,000+ -- which meant that your contracts had better be in the six-figures if you want to be profitable.

That's now how most B2B companies work in 2013. Look at Stripe, Yammer, Parse, Github, or Twilio -- you can sign up directly on their web site, often get started for free or cheap enough that you don't trigger purchase approval. Most of the customers for those companies come in through inbound channels, like blog posts, ads, partnerships, or referrals. And to the extent that they have sales, it's inside sales, primarily working to convert existing, happy users of the product to paying customers.

Chris Dixon has a great related blog post on this: http://cdixon.org/2012/09/24/the-rise-of-enterprise-marketin...

Enterprise (Or b2b with tech customers) is really fun. My take on the sales process: you don't want a sales guy talking with the customer, you want a core engineer for your product or service spending time collecting exciting challenges / needs from your possible customers. Its fun to see all the variation in seemingly simple problems that get quite complex at scale in large businesses.

That said, my experience thus far can be summarized as this: "if you can make a product or service that derisks a company innovating within its business, they will want to buy your product"

Or said differently, as long as the value gained > your price, and resulting risk is less than any alternative, someone will write a check the moment you can validate this value prop for them. (Of course, if they can't pay they won't, but then they aren't a possible customer).

This seems like a much more fun way to bootstrap a real business than some b2c thing, and its what I'm doing with my efforts at wellposed. Or at least that's my short form thoughts on this matter.

I agree with the article and I'd like to challenge pg's view that hackers should let others (arguably non-hackers) start enterprise startups.

I agree with the article because while it is true that startups addressing "localized" enterprise-problems can go to market in a super effective new way (e.g., salesforce, box, etc), there are still a huge set of problems that require enterprise-wide/complex adoptions (e.g., infrastructure, analytics) and therefore cannot be purchased by individuals-workers with their credit cards over the internet.

In those cases, a lot of people need to agree on how to proceed, budgets assigned/etc etc - that can take forever and you need to hand-hold the process - thus - you need "sales people"

So the traditional view is those type of startups are 'sales' startups - ie the main deciding factor of success is being good at sales (that is roughly pg's view)

I disagree with that point of view - because many things have change in the past few years - nowadays with a small team you can adress niche enterprise-wide problems, by leveraging AWS, tons of open source libraries and so on. At the same time, large companies are more into trying niche solutions to their needs even if they come from tiny companies.

That is our story at Kormox - we are a super small team of hackers who are targeting a huge market, but started focusing first on a specific vertical (in our case, targeting our offering first to Management Consulting Firms).

It is still true that you need to be very patient and iterations last WAY longer (ie - you don't know if what you are building is not something people want up until WAY longer than in a non-enterprise startup, because the cycles for customers to use something are super long).

On the flip side, you can find adventurous customers that can virtually fund you.

The good news is you don't have to raise $967876876M to start as it used to be the case to "build the product" - I think nowadays a bunch of energized hackers can build the product in a relatively short period of time.

No questions though you'll need someone that is willing to wear suits (or at least kakis) and go talk to hundreds of middle-managers across a bunch or large companies. But I don't see why is that a problem (especially when compared to all the sort of "boring" things people do for growth hacking in a non-enterprise startup).

The thing I like about enterprise software and selling to enterprises is that you can build big, sticky revenue flows. You're usually dealing with pretty meaty technical and organizational problems, which can be fun. And in the right circumstances, the customers will fund or subsidize your development efforts, which can make your investment go farther.

The tradeoff is it's less sexy. Sales cycles are long. The tools you build need to be robust.

pg addresses this in http://www.paulgraham.com/start.html

Start by writing software for smaller companies, because it's easier to sell to them. It's worth so much to sell stuff to big companies that the people selling them the crap they currently use spend a lot of time and money to do it. And while you can outhack Oracle with one frontal lobe tied behind your back, you can't outsell an Oracle salesman. So if you want to win through better technology, aim at smaller customers. [...] Corollary: Avoid starting a startup to sell things to the biggest company of all, the government. Yes, there are lots of opportunities to sell them technology. But let someone else start those startups.

On the other hand I see a lot of potential in selling cheap, lightweight, cloud-hosted, but effective "small business IT" applications on a subscription basis to help enable the little guys to compete with big business on a more level playing field. You're running a small business and you can't afford to shell out millions on an Oracle or SAP system? Maybe you can't afford to hire a full-time developer or even a consultant to build you an application? Who cares, when there's a just-as-good application that you can access online for less than $100/month?

The key to this would be understanding the use cases particular to whatever industry you are selling to. You might have to have industry-specific modules within a larger application framework.

Then there's always the potential challenge of ETL-ing the data from whatever legacy system the small business might be currently using in order to make it available inside your application, but that's much more of a consulting job than a product marketing job. That's got to be one of the the most expensive aspects of selling enterprise software in the first place.

And of course, assuring the customer about security, privacy, and IP protection of their data would also be of paramount importance, if it's going to be cloud-based.

We should agree on definition of terms, what actually is enterprise? Not all B2B is enterprise, so we should draw a line somewhere. There's a lot of SME B2B solutions where the sales and marketing process is quite similar to B2C. Should we say enterprise is when you start doing direct sales?