One of the huge advantages of the cloud is its ability to cut the time to market for new ideas, creating more agile enterprises.   While rapid provisioning and access to a larger set of resources than you might otherwise have contributes to this, the biggest win comes from realizing that the cloud eliminates the need to think linearly.

Over the last 10 years or so, software development methodologies have evolved from a "waterfall" analogy where design was followed by development then by test, then by deployment (to put it simply) to an agile, concurrent model where software releases became much smaller and all of the activities above happened at the same time.  So instead of:

design->develop->test->deploy

organizations realized that they can be much more customer responsive and get more done by developing software as follows, in which their team is broken up into smaller groups that work on multiple releases at once, speeding up release times by 4 (in this example):

design4->develop4->test4->deploy4

develop3->test3->deploy3->design7

test2->deploy2->design6->develop6

deploy1->design5>develop5->test5

However, the cloud allows you to apply this same discovery to your deployments, not just your development cycle.  What does this mean?   Well, for most growing internet enterprises, deployment isn't static: as their code evolves, so does their deployment architecture.   

Let's look at a little example.  We have a customer who is bringing their internet service from beta through ramp-up to large volumes.   As they do so, their deployment architecture has changed from single-instance MySQL to multi-instance MySQL to Mongo+MySQL and finally Mongo-only.   Here's how their IT staff laid out their IT architecture plans:

prototype MySQL -> test MySQL -> production MySQL -> prototype MySQLmulti
->test MySQLmulti -> production MySQLmulti -> prototype mongo -> test Mongo
-> production Mongo

If there were any problems in any of the prototyping or test phases for their deployment architecture, they'd run the risk of falling behind their code or the demands of their customer base and having a site meltdown or constraining their business.   But they don't need to think this way.

Even with a small team, they can simply develop each of the deployment architectures concurrently by creating a separate cloud instance for each one and making progress as their teams' knowledge base evolves, rather than being constrained by limited amounts and configurations of hardware for hosting the deployments.

prototype MySQL -> test MySQL -> production MySQL

                   |-->prototype MySQLmulti ->test MySQLmulti -> production MySQLmulti

                                  |-->prototype mongo -> test Mongo -> production Mongo

The organization has the option of trading off staffing for project schedule on the deployment phase, while avoiding any potential budget problems by using small cloud instances when needed to speed development of their deployments.   As a result, they no longer have to worry about being "taken by surprise" by a sudden hockey-stick in their usage that overwhelms their current-generation of deployment architecture.   And their IT operations staff no longer needs to worry about taking the blame for falling behind the market.

This applies equally well to testing new markets with mini-versions of new products, and whole host of other processes that used to be linear but can now be done in parallel, thanks the cloud.