I've worked for three well-funded startups that failed for another reason, though all of them ended up making the same mistake: they couldn't develop software.
All three made some of the most common mistakes in software development, and tried to hide those mistakes behind a sweatshop.
1) Hire lots of people. Silly... hiring people doesn't get work done if you can't actually tell those people what you want their product to do.
2) Assume that hours = productivity. In every case, the competent folks among us spent a lot of time cleaning up problems caused by the folks working the extremely long hours. That contributed to my departure in every case... I hate cleaning up other people's messes, as it prevents me from doing worthwhile work. Firing those folks would have gotten us to market MORE quickly rather than less.
3) Deadlines set in stone... that just doesn't work. If you can't adjust your scope, you'll never actually hit the deadline.
4) Marketing based on the deadline... duh.
5) Perpetual crisis mode... when the requirements are poorly defined (if they're defined at all) as well as late, you have to be willing to delay launch or trim scope, or both. If instead you go into crisis mode and assume that your sweatshop will churn out a working product, you've already failed, and most of your best people will start jumping ship, leaving you with your burnouts who's primary contribution ends up being technical debt rather than working products.
I could go on, of course; I'm sure most people here have had similar experiences. So far, what I've seen of startups that made it big, they succeeded because they were either smart and did things well (e.g. 37signals), or because their software wasn't what they made their money on. Where I work now, we have hundreds of developers whose job is to pay the technical debt of the sweatshop, and one side effect of this is high turnover and low tribal knowledge. Most of our systems are in perpetual triage, and it's pretty obvious that if they were the source of our revenue, we'd be history. Fortunately, they only support the core business, so we're still around and profitable... but very inefficient.
Several government contractors I've worked for clearly survive based on the contacts within the government, because their software in many cases doesn't even meet the requirements it was developed for.
All three made some of the most common mistakes in software development, and tried to hide those mistakes behind a sweatshop.
1) Hire lots of people. Silly... hiring people doesn't get work done if you can't actually tell those people what you want their product to do.
2) Assume that hours = productivity. In every case, the competent folks among us spent a lot of time cleaning up problems caused by the folks working the extremely long hours. That contributed to my departure in every case... I hate cleaning up other people's messes, as it prevents me from doing worthwhile work. Firing those folks would have gotten us to market MORE quickly rather than less.
3) Deadlines set in stone... that just doesn't work. If you can't adjust your scope, you'll never actually hit the deadline.
4) Marketing based on the deadline... duh.
5) Perpetual crisis mode... when the requirements are poorly defined (if they're defined at all) as well as late, you have to be willing to delay launch or trim scope, or both. If instead you go into crisis mode and assume that your sweatshop will churn out a working product, you've already failed, and most of your best people will start jumping ship, leaving you with your burnouts who's primary contribution ends up being technical debt rather than working products.
I could go on, of course; I'm sure most people here have had similar experiences. So far, what I've seen of startups that made it big, they succeeded because they were either smart and did things well (e.g. 37signals), or because their software wasn't what they made their money on. Where I work now, we have hundreds of developers whose job is to pay the technical debt of the sweatshop, and one side effect of this is high turnover and low tribal knowledge. Most of our systems are in perpetual triage, and it's pretty obvious that if they were the source of our revenue, we'd be history. Fortunately, they only support the core business, so we're still around and profitable... but very inefficient.
Several government contractors I've worked for clearly survive based on the contacts within the government, because their software in many cases doesn't even meet the requirements it was developed for.
That's quite a bit more than I'd intended :)