Why 'The Enterprise' might be hard for your startup to break into.
3 comments
"You deliver a product"
Thats 90% of battle won. Problem is most "startups" don't even get to that point. The reasons are not as simple as just "I dont have time". Enterprise contracts are usually for many years and vendors have a very strong hold on enterprise clients. I support a multi million dollar vendor system at my employer and I can tell you even though most of the client "users" hate it, no one can even think about getting rid of it.
Thats 90% of battle won. Problem is most "startups" don't even get to that point. The reasons are not as simple as just "I dont have time". Enterprise contracts are usually for many years and vendors have a very strong hold on enterprise clients. I support a multi million dollar vendor system at my employer and I can tell you even though most of the client "users" hate it, no one can even think about getting rid of it.
Besides which, if you've delivered a product to an enterprise then implicitly or explicitly they're paying for the support, in advance, possibly with agreed rates for "additional work", in their license agreement.
And although you can usually afford to lose them, small businesses can be demanding too.
And although you can usually afford to lose them, small businesses can be demanding too.
People don't realize that part of building a product is documenting how to use it and building a support system for it. Enterprise demands documentation and support for everything. But people tend to think that their app is self-documenting. Nope. Never w has been. Never will be. You need to include support and documentation as part of the product and develop it alongside. You also need to price it accordingly.
First hand experience selling Review19 - http://www.review19.com - to the enterprise: It is extremely hard.
Always nice to have the right contacts and have favors waiting to be cashed in.
Always nice to have the right contacts and have favors waiting to be cashed in.
One thing that soured us on startups was actually dealing with a startup.
Or rather, not dealing with them: they folded two years after we acquired the application. Leaving us with a very important tool written in a language nobody at our company knew.
This closed the door on future opportunity. "Nice product, will they be around in two years? Remember XYZ ..."
Or rather, not dealing with them: they folded two years after we acquired the application. Leaving us with a very important tool written in a language nobody at our company knew.
This closed the door on future opportunity. "Nice product, will they be around in two years? Remember XYZ ..."
You deliver a product. It works, but wait: there is a problem. Back to the vendor: we need to know how config X.
Now, it is not that I'm not capable of reading up on how to, say, edit $APP_ENGINE to be secure. I have a development environment, I can play around with this setting or that. I _can_.
I don't have _time_ for that.
I've got my normal workload, I've got projects, I've got a stable of applications to configure, babysit, fret over. If I had to spend my time re-discovering how to make each and every one of those applications work, that is all I would be doing.
No. What I need from my vendor is a cook book approach: if you have Solaris, do this. Redhat, do that. Windows, the other thing. I need guidance, so I can hand the book to a junior SA and say 'follow these directions'.
If you, the vendor, can't provide at least that level of hand-holding ... it's going to be a rocky relationship.