Heed warning - it's not this simple. The only way to properly do this is to build a strong network with the stakeholders who buy this IT software. Mainly the CTO/CIO (or CFO). That's the only way to make money in the enterprise. Sales cycles are long and arduous, so be prepared for the long haul.
In most companies, the CTO or CIO comes nowhere near the kinds of purchasing decisions made by the kinds of companies started by a process like this. There are many tens of dir/it or dir/ops people in almost any Global 2000 company that routinely make six-figure purchasing decisions.
Many of those decisions do percolate to the CIO/CFO level for approval, but there is a world of difference between "purchase approver" and "decision maker". Directly targeting the purchase approver is often a very bad sales strategy.
Good point. A VP of Operations/Infrastructure (of IT) who would report to a CTO/CIO would be more suitable. I guess I should have clarified that a bit better. It's also, as you allude, not as simplified as this.
Either way, my point was more about the fact that working day to day-to-day IT work won't give you the edge unless you have some sort of in with the guy/girl who ends up actually making the purchasing decision. It's also not as simple as this, as IT/Business organizations can be muddied with politics that don't always serve the IT personnel's productivity interest.
It also doesn't hurt to also get in with procurement. Which is another barrier I've found in "BigCo". Many large (Global 200) companies have a shortlist of companies they will work with and won't even entertain a conversation unless you are a certain size or have a pre-existing contract with them.
I agree. Solutions pushed downstream from the executive level (usually from someone who happens to play golf with the bosses) really succeed, because they aren't usually what we actually need.
I think ec2 is the counterexample here. EC2 costs vastly more than owning hardware, and is in many ways harder (you have to design your application to be able to lose any server /much/ earlier than you do with hardware backed by a good SysAdmin's pager,) but from what I've seen working at large corporations, it's far easier (and to further contradict what I said earlier, cheaper) than running those servers in-house, at least for companies that aren't very IT focused. It's also vastly faster; as soon as the budget is approved and you have a guy trained on bringing up ec2 stuff, bang, you have your hardware, whereas in many companies, you ask IT and it's a long back and forth while IT tries to "help" you figure out what you really want, then it's another week while they get the hardware, then it's not just what you wanted, so there's another back and forth of a week. If the hardware was of a new type, there's another week while weirdness due to the new hardware are worked out. During all this time, the manager that wanted the servers can't do anything but whine to IT. With ec2, that manager can just get a better ec2 sysadmin and get on with it.
Therefore, many big company managers just head to amazon for their hardware rather than to the IT department. Part of the efficiency of ec2 is that you don't have to go through some salesrep and spend weeks going back and forth on price like you do when you buy pre-built servers (or way worse, data centre space or bandwidth.) There is no "vendor relationship" to manage, and "vendor relationships" add rather a lot of hidden costs on both sides.
My point is just that if you can solve the problem in a way that managers can plausibly justify an end-run around existing obstacles? I mean, you do need hype, and name recognition, but you can do it without a whole lot of high touch sales and "customer relationships."
Depending on your product you might be able to sell to small and medium businesses as well to keep you going/gain momentum before you break into the enterprise market. Github is a good example of that.
Comments
Heed warning - it's not this simple. The only way to properly do this is to build a strong network with the stakeholders who buy this IT software. Mainly the CTO/CIO (or CFO). That's the only way to make money in the enterprise. Sales cycles are long and arduous, so be prepared for the long haul.
In most companies, the CTO or CIO comes nowhere near the kinds of purchasing decisions made by the kinds of companies started by a process like this. There are many tens of dir/it or dir/ops people in almost any Global 2000 company that routinely make six-figure purchasing decisions.
Many of those decisions do percolate to the CIO/CFO level for approval, but there is a world of difference between "purchase approver" and "decision maker". Directly targeting the purchase approver is often a very bad sales strategy.
Good point. A VP of Operations/Infrastructure (of IT) who would report to a CTO/CIO would be more suitable. I guess I should have clarified that a bit better. It's also, as you allude, not as simplified as this.
Either way, my point was more about the fact that working day to day-to-day IT work won't give you the edge unless you have some sort of in with the guy/girl who ends up actually making the purchasing decision. It's also not as simple as this, as IT/Business organizations can be muddied with politics that don't always serve the IT personnel's productivity interest.
It also doesn't hurt to also get in with procurement. Which is another barrier I've found in "BigCo". Many large (Global 200) companies have a shortlist of companies they will work with and won't even entertain a conversation unless you are a certain size or have a pre-existing contract with them.
I agree. Solutions pushed downstream from the executive level (usually from someone who happens to play golf with the bosses) really succeed, because they aren't usually what we actually need.
I think ec2 is the counterexample here. EC2 costs vastly more than owning hardware, and is in many ways harder (you have to design your application to be able to lose any server /much/ earlier than you do with hardware backed by a good SysAdmin's pager,) but from what I've seen working at large corporations, it's far easier (and to further contradict what I said earlier, cheaper) than running those servers in-house, at least for companies that aren't very IT focused. It's also vastly faster; as soon as the budget is approved and you have a guy trained on bringing up ec2 stuff, bang, you have your hardware, whereas in many companies, you ask IT and it's a long back and forth while IT tries to "help" you figure out what you really want, then it's another week while they get the hardware, then it's not just what you wanted, so there's another back and forth of a week. If the hardware was of a new type, there's another week while weirdness due to the new hardware are worked out. During all this time, the manager that wanted the servers can't do anything but whine to IT. With ec2, that manager can just get a better ec2 sysadmin and get on with it.
Therefore, many big company managers just head to amazon for their hardware rather than to the IT department. Part of the efficiency of ec2 is that you don't have to go through some salesrep and spend weeks going back and forth on price like you do when you buy pre-built servers (or way worse, data centre space or bandwidth.) There is no "vendor relationship" to manage, and "vendor relationships" add rather a lot of hidden costs on both sides.
My point is just that if you can solve the problem in a way that managers can plausibly justify an end-run around existing obstacles? I mean, you do need hype, and name recognition, but you can do it without a whole lot of high touch sales and "customer relationships."
Depending on your product you might be able to sell to small and medium businesses as well to keep you going/gain momentum before you break into the enterprise market. Github is a good example of that.