I get the impression that a lot of companies think that load testing is something that gets done fairly late in the development cycle.  I'm a longtime believer in load testing early and often.  If your product's normal operating mode is carrying dozens or thousands or millions of transactions at a time, you really ought to make it do that as early as possible.  Some or many things might not work, but at least a few basic transactions ought to be working end-to-end very early on.  (And if not, why not?)  Over the years, I've gotten a lot of useful results from some very simplistic load scenarios.

I particularly remember one incident in my past when I connected a few spans of bulk call generator to a voicemail server very early in the release cycle and fired up a simple incoming-call load scenario at, um, I think somewhere between 8,000 and 12,000 calls per hour, it was more than a maintenance window load but still pretty light, well below the 60,000 calls per hour the system was advertised to support (a quite respectable call volume for its day).  I watched the logs for a little while, and then let out a virtual scream to Development for help, because that nearly-trivial scenario was running just fine EXCEPT that the system was in load limiting (dropping calls due to lack of resources).  An experienced senior developer took a look and discovered that the application was making vastly more database accesses than it should have - several recently-hired developers had been working on the application, and hadn't realized what data needed by a call would already be in cache by the time the call reached their code, so they were making database accesses they didn't need.  The code got cleaned up, the hole in those developers knowlege got repaired, and we continued with the release with *that* complication out of the way.