It's a great method to get inspiration for potential problems in the B2B space. The challenge however, after you've come up with a solution is the sales. Enterprise sales are notoriously difficult especially due to "big business" culture that creates inefficiencies to solve in the first place.
"Start by writing software for smaller companies, because it's easier to sell to them. It's worth so much to sell stuff to big companies that the people selling them the crap they currently use spend a lot of time and money to do it. And while you can outhack Oracle with one frontal lobe tied behind your back, you can't outsell an Oracle salesman. So if you want to win through better technology, aim at smaller customers."
As someone who works (not in IT) at a government-owned BigCo (2000 employees), let me tell you: building the software that will solve our problems will be the easy part. Navigating the bureaucracy of BigCo's procurement processes will probably take you more time, skill and money than actually building the product.
And it's not enough to have a product that solves a problem. BigCo never fixes things all at once. So whatever your product is, it'll have to work with innumerable poorly-documented legacy systems. Integrating with BigCo's existing, proprietary systems might take longer than developing the core of your actual product.
But the upshot is that BigCos are used to dealing with BigSoftwareCo that is just as slow and unresponsive in its development processes as BigCo itself. BigSoftwareCo doesn't want to fix our problems, they want to sell us an off-the-shelf product at a price tag that implies thousands of hours of dev work. So if you can show them that you can accommodate their needs quickly and without the usual obstructionism, technology dogmatism and nickel-and-dime-ing practices of BigSoftwareCo, there's definitely an opportunity to build a great relationship.
Not to mention BigCo's managers are highly averse to risk and won't put their bonuses and careers on the line by vouching for a small company that may or may not be around in a few years in case they need support or maintenance.
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.
"Before I started IndexTank I already knew that people would be willing to pay $$$ for such a service because I'd been making money with search consulting for a while."
I started off the in a similar manner, doing lots of consulting work. I know there is demand (in my case, its selling structured data), but however I am not too sure on whether the same demand would exist if I were to 'productize' my consulting work (ie. launch an api for structured data).
As one of the commentors, mentioned its really hard targeting the big companies and most small companies simply don't have the technical expertise to use an API (as in my case).
True ... the alternative is to stay where you are and actively look for problems. They're not limited to BigCo and if you have the entire breadth of human suffering in view, you're bound to find at least one idea that can be sold (for money ... not users) and excites you.
I think more clearly it is a suggestion to find a problem that needs solving, and then solve that. This is solid advice.
Many people will 'dream up' a new product/idea/concept, fall in love with it, and then try to build a company out of it. This has a much much lower chance of success. (great for including in a work of fiction, less useful when you're trying to convince people they need something they never heard of before). So don't do that.
But it also works for life, the 'Just Landed' app is a good example of something that I do infrequently, FlightAware made better (you can watch as the plane comes in) and this could be even better. But you have to have to consciously make the step of stepping outside 'living' your life and look at like as a process to be improved.
Some people do this naturally, others have to work at it, and some never get it. Diego's advice to talk to people and find out their pain points (everyone loves to complain) is a good way of seeing the process outside of that actors implementing that process.
Yes, I wrote this post because I've chatted with a few first-time founders who haven't experienced life at BigCo. As a result, they are creating solutions to problems nobody has. To me, it seemed obvious that you had to know BigCo from the inside before trying to sell them something.
Sounds like a good idea, however to sell at BigCo:
- you really need contacts. As the OP points out, this involves working with them some time (in the inside, as contractor, selling to them, whatever). If you haven't, find a salesman who has the right contacts and experience: "don't call X, he's retiring next year and doesn't want to rock the boat with a new purchase. He'll just string you along. Call Y instead, he's new to the company and wants to prove himself - I play golf with him next Saturday".
- decision making at BigCo is at a frustrating, glacial pace. If you're used to the instant feedback of throwing something up in an app store or HN or whatever, you'll be disappointed.
- lots and lots and lots of meetings. Incredibly inane and the lead times are ridiculous.
- once you've proven yourself, it can be a real gravy train.
PG has this to say in his essay (http://paulgraham.com/start.html) :
"Start by writing software for smaller companies, because it's easier to sell to them. It's worth so much to sell stuff to big companies that the people selling them the crap they currently use spend a lot of time and money to do it. And while you can outhack Oracle with one frontal lobe tied behind your back, you can't outsell an Oracle salesman. So if you want to win through better technology, aim at smaller customers."