Comment by exelius | Hacker News Reader

Comment by exelius | Hacker News Reader

This sounds like a pretty typical trajectory for a failed startup: CEO dreams big, encourages sales guys to chase big fish through the commission structure, but meanwhile the big fish demand more features, guarantees, complex contracts, etc. than 15 smaller customers would. I've seen it happen quite a bit; and it's one of the biggest (and most common) mistakes that B2B software startups make.

An early-stage company really needs two things from its customers: cash flow and feedback. It's fine if you don't make any profits, but you need revenue coming in the door to get future rounds of funding. It's fine if your revenue per customer is lower than you would like. Small customers are great at both: price it low enough to start that it's not a huge business expense for them, and you will be able to deal directly with the people who will use the system. If they have a problem, your product guys will know and be able to relay it to development.

Big customers often get you neither. They require lengthy contract negotiations that will rack up thousands in lawyer's fees from your side before you bring in any revenue. They ask for features that aren't core to your product and are likely years down on your roadmap (think LDAP authentication, customer admin functionality, audit logs, etc.) Again, these have to be developed before they sign a contract and before you see money. If you actually manage to get them into a production environment, they're much less likely to give you actionable feedback.

tl;dr: B2B software startups that target big contracts are much more likely to fail because the market dynamics of chasing after big customers will increase your burn rate while diverting your sales team's attention from smaller fish.

Yes, I've heard (and experienced) most of this. It's still good to hear it again, though, and being from another country we can learn that some mistakes are universal.

EDIT: Joel's Camels and Rubber Duckies[1] is essential reading for how hard it is to sell enterprise software. Price it free, cheap, or dear. Not to say that there is no hope in selling to enterprises, because lots of people are very successful doing it, but you need to know how hard it is before you start.

[1] http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...

Hey guys these are excellent feedbacks! I discovered too late this behaviour was typical, and you confirm it even more… I wish we had sought this kind of trustful insights beforehand.

We actually thought our lawyer was helping us but you know, he was a "close friend" with the CEO so the game rules were a bit faked.

Thanks for the book reference as well!

Yeah, it can be hard to know some of the core things like market entry strategy without having been burned before. Even if you get the strategy right, setting up your sales and marketing plan (compensation, market profile, etc.) such that it implements your strategy is also a challenge. My belief is you should never have commissioned sales people in a young software startup; always pay them on a salary + bonus structure with bonus targets that reflect your strategic priorities (i.e. number of customers, revenue per customer, etc.) These can and will change frequently as you "pivot" your product development.

It's not impossible to sell software to enterprises, but they shouldn't be your first target customers for a number of reasons. First, any enterprise problem that is valuable to your potential customer probably already has a solution available from their ERP vendor (e.g. Oracle, SAP or IBM). If your prospect chooses not to go with that solution, price is likely the issue; so you are selecting price-sensitive customers. Second, you will likely have to integrate with an ERP system, which will likely confuse your Rails developers because ERP systems are ass-backwards and make no sense.

It also becomes a lot easier to sell your product to a big customer if you already have a lot of little customers. But selling software to big customers will require a lot of custom integration work: you need to have the scale to be able to provide integration services to them while still supporting your existing customers.

Enterprise customers should absolutely be a goal of any B2B software startup, but not early on. Early on you want to focus on the customers that are easier to please, and make a kick-ass product for them. Once you have built that product, you can start to scale it up to larger customers and get the feature integration right. You also shouldn't be afraid to say "no" if approached by a potential big customer because your product isn't ready for them.

In my experience working on an enterprise software product, it's not so much that price drives them away from Oracle/SAP/IBM/..., but a perceived lack of value or ROI. Competing on value instead of price is definitely possible in a B2B context (although to be fair some companies are just cheapskates and will always buy the cheapest product).

Well, all other things held equal, most customers would prefer to buy from an existing vendor (one throat to choke and all). Given the nature of most RFPs for this kind of software it's hard to win on value since the requirements are laid out in advance; so you almost have to win on price. The danger of winning one of these contracts is that SAP/Oracle/IBM all know how difficult their ERP systems are to integrate with, and if you can under-price them, you're likely underestimating that cost.

Basically, there's a lot that can go wrong and you need to have a certain scale before you even attempt to go after the big whales. You shouldn't be trying to work with them while building out the basic version of your product.

From my experience, the problem is that when your strategy is chasing big customers v. small ones, the customers you often end up with are the worst of both worlds - they are large enough to act like big customers (want contracts and features outside the scope of what you are working on), but will only be looking to pay prices that small companies need. I worked at a company in that spot for a while. In SaaS, sales teams can play a big role, but until you have a pretty decent cashflow, it makes more sense to me to have them focus much more on inbound sales (and account management) than outbound, which is a very different sales model. Eventually, once you hit a certain size, you probably need a real sales team, since that's what will close the real big fish. But before you go after them, make sure you have enough cash flow that your boat doesn't sink before they can reel them in (to continue the fishing metaphor).

When I worked at Pearson, I was often at the other end of the transaction in these situations. We required LDAP, hosted local admin, and a few other enterprise-y features that don't play well with cloud startups. But it was essentially window shopping.

I would often interact with a startup where the sales guy was fired on the other end because they just didn't understand that we were doing a 3-6 month competitive technical evaluation (in addition to our more important day-to-day work) after I'd clearly explained it a few times. No amount of "sales" will make up for a lack of required, costly-to-build features. Also, the answer to missing features is rarely ever "wait for them to be built."

Reply on news.ycombinator.com