Building enterprise focused startups that dont suck

There is nothing wrong with serving all audiences, and creating software that doesn't suck (in fact, you should), but with poor sales teams, presentations and RFP's you will struggle for adoption in enterprise, period.

Hacker Centric cultures are huge and are very important imo, but it remains key to understand the increased weight on a strong Business Development team in enterprise.

Dealing with enterprise is not easy. Generally speaking, whatever software you are selling is displacing something else (even if that displacement is administrative assistants). Thus there is a high degree of complexity, process changes etc. that change how the game must be played vs. B2C

First, the person with the purse is not usually the end-user. Therefore, features, capabilities lists and slide decks are generally more valuable than product design.

Second, the person with the purse is not usually the bringer of new tech. The decision-maker isn't usually the company's earlier adopter. Large companies select and condition for certain types of people to fit certain molds. That person typically has had, "pick your battles carefully" drilled into them, and they tend to avoid making unnecessary risks.

Third, companies only begin to change when they're under pressure, and at that point, their internal software systems aren't usually their primary focus. Large companies only make big changes in software when they see others succeeding at it, when it's mandated, when the ROI is obvious, when the employees are uprising over it, or finally, when they want to seem the industry vanguard.

Fourth, FUD still rules in the enterprise. It's much easier to fall back on the tried-and-true than to take a risk with uncertain results. And, if the tried-and-true comes from the 'best thinkers around' (e.g. the high-end academics and other big company employees), they're easily adopted. Try to see how hard it is to get a REST API adopted in the enterprise, and you'll understand.

Fifth, enterprise procurement can be dominated by RFP processes that generally tends to favor big lists of things other than usability and openness. Sometimes it's who is the cheapest. Other times, it is who is most secure. Or, who is the most reliable. It's rarely which product is the most well-designed.

Sixth, enterprises are _extremely_ process driven and have custom workflows for everything. The employees are very attached to those workflows. It usually takes a team of fast-talking consultants to piece together a Frankenstein monster system from available APIs to get those workflows to work. It's better to change the workflows at the beginning, but that rarely happens (then you have training issues, which is a whole other issue).

We will only see better designed enterprise software when the small companies that are using them now become big companies and have that mindset written into their corporate principles list.

With most of the SaaS 'enterprise' systems out there, you're often not replacing anything up front, but early adopters are free to try some parts of a service, demonstrate ROI, then angle for a wider rollout. This is the opposite of most traditional "enterprise" software evaluation/deployment cycles.

The ability for individuals or departments at companies to use bits and pieces of services (imagine one dept at 'bigco' using box.net, for example) is what gives these SaaS players any chance at all of getting their foot in the door, and it's a good strategy. It's far less about 'sucking' from a 'checkbox feature list' standpoint, and more about grassroots adoption.

Years ago I was on a team that developed an LMS for a distance learning institution. It checked off quite a lot of feature-list checkboxes - had far more features than most other open source packages out there at the time - but... it was a top-down system, designed solely to be used by all levels at a school org. It fit that institution just fine, but for anyone else to try to adopt it at their school, was just too difficult. We could have tried to do long sales cycles to other institutions, but didn't (for a lot of reasons). Moodle was being released around the same time, and while we had far more features that teachers wanted, Moodle was something any teacher could install and use just for their own classroom, without any external dependencies. History has shown that Moodle's really taken off - it got a lot of early adopter support from people who wanted/needed it, but didn't have the ability to affect change in their whole enterprise.

I've been uncomfortable throughout the implementation believing that, in 2011, there must be a better way. Kudos to the start-ups and companies fighting for this space. A lot of money and opportunity.

Innovation and "amazing" are concepts completely alien to enterprises, particularly government. Corporate people have certain motivations, government people have other motivations. Maybe they need to comply with "strategic sourcing" procedures. Or funnel all procurement through a procurement group incentivized to get large % discounts from "list" or "state contract" or "GSA" pricing. Or maybe they need to run all of the business through some BS minority/woman/veteran owned company to hit some quota.

RFP responses matter, maybe more than the product.

At the end of the day, if you want to sell to enterprises, you need to know your way around the market.

With the freemium model, software can be basically given to the user; then, ASSUMING you have a strong product, that person will become your promoter within the organization. Get to the CIO through that user, if they are not enough keep building critical mass. Eventually the CIO will listen.

Right now, the enterprise has mis-alignment with the buyer and the user. Whatever can be done to bring that into proper alignment will in the end benefit the user.

Also, open source is not a game changer. Proof: it's been around a while, and nothing's changed. It's just a new checkbox ("feature") that the client demands. Sure open source is great, but I know from experience that it doesn't fundamentally affect this situation.