Building enterprise focused startups that dont suck(techcrunch.com)
techcrunch.com
Building enterprise focused startups that dont suck
http://techcrunch.com/2011/07/10/building-an-enterprise-software-company-that-doesnt-suck/
12 comments
I don't think the author understands the dynamics of the enterprise market. The companies mentioned in the article are definitely not the rule, and I don't see a trend here. I'm guessing that those companies don't have wide adoption across the largest of companies either.
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.
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.
The author's company has at least $10m in revenues.
As with others, I think the author is missing some things.
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.
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.
This article resonates with me particularly strongly right now. I'm knee-deep in an ERP implementation and, on all fronts (costs, software capabilities, end-user satisfaction), the author hits the nail on the head.
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.
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.
It resonates with me as well, as I'm the founder of an enterprise focused startup. Some of what the author says jibes with the ideas I was already working on... the point about customer support, in particular. Remaining engaged with the customer and helping ensure that their use of our software is successful, will be crucial to our success, IMO.
As for User Experience... I care so much about that, that my first co-founder is actually a UI/UX person, as opposed to a backend developer or a bizdev/sales/marketing person. Emphasis on User Experience will be woven deep into the DNA of the company...
As for User Experience... I care so much about that, that my first co-founder is actually a UI/UX person, as opposed to a backend developer or a bizdev/sales/marketing person. Emphasis on User Experience will be woven deep into the DNA of the company...
I'm working again in enterprise startups, and one of our huge selling points is the huge difference in UX / UI.
The premise of the article is wrong -- "Creating amazing products, not amazing RFP responses"
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.
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.
At the end of the day, if you want to sell to enterprises, you need to know your way around the market.
This is absolutely true, however, it's also true that you need to create amazing products. Enterprises are very conservative. There's a lot of "no one was ever fired for buying IBM" style decision making. An established product has a huge CYA advantage over entrants. To be more attractive, you need to be not just a little better, but a lot better.
I work at Endeca, and for our e-commerce search engine, increasing conversion rates is a huge selling point. Note that I'm in Engineering, so I don't have a strong handle on the day-to-day operations of the sales team, but there is a lot of communication between sales, PM and engineering, so I feel I know enough to comment.
This is absolutely true, however, it's also true that you need to create amazing products. Enterprises are very conservative. There's a lot of "no one was ever fired for buying IBM" style decision making. An established product has a huge CYA advantage over entrants. To be more attractive, you need to be not just a little better, but a lot better.
I work at Endeca, and for our e-commerce search engine, increasing conversion rates is a huge selling point. Note that I'm in Engineering, so I don't have a strong handle on the day-to-day operations of the sales team, but there is a lot of communication between sales, PM and engineering, so I feel I know enough to comment.
Usually smaller or companies entering a new market influence a VAR or enterprise vendor who have a gap in their portfolio.
If you're a services company, it's essential -- you basically subcontract through the "mother" vendor's contract.
Cisco is doing this with their blade servers. They partner with EMC and NetApp, especially at entrenched IBM/HP customers where vertically integrated vendors like EMC are at a disadvantage.
If you're a services company, it's essential -- you basically subcontract through the "mother" vendor's contract.
Cisco is doing this with their blade servers. They partner with EMC and NetApp, especially at entrenched IBM/HP customers where vertically integrated vendors like EMC are at a disadvantage.
IMHO, the "bottom-up" approach is the game-changer in the enterprise 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.
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.
This article is bullshit. It suggests the Enterprise Software and its associated Sales can be fixed by changing the vendor's behaviour. But historically vendors became the way they are because of their large, slow, complex inefficient clients.
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.
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.
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