We can now make software faster than we can dream it up. Good implementation teams are exhausting their product masters, chewing up requirements, and spitting out code. Bring it on! they cry. Have mercy! we beg. We need time to study the market, the users, the requirements... time to eat and sleep. But the releases roll on. Product managers have to deal with the implications. Radical innovation is required. This is the first in a series of articles on the coming age of evolutionary product development.

How can this happen? Just hypothetically, imagine that you are trying to design and launch a new Web product, and you have a team recruited from the best developers available on the planet. They can implement most ideas in a few days, and take care of many requests overnight. Also, just hypothetically, imagine that you can release new features into your server farm every day, on a server-by-server basis, see if they work with real users, and expand or reduce the deployment in real time. Also, just hypothetically, imagine that you have huge numbers of users to provide immediate feedback.

That sounds a lot like the situation at Google. I face the same situation on a smaller scale every day. You have to figure out every day what should be different about the product tomorrow, and that’s a big job, an exhausting job. It’s impossible to provide enough product design and direction to run this process at full speed. The implementers are often waiting for product directors, instead of the other way around.

So what happens then? At Google they ask people to spend 20% of their time thinking up new products.  They create new projects and products and product managers, and spread the same implementation capacity around to a larger number of projects.

Spreading out into more products is bad strategy. The important products don’t run at full potential because you are diverting energy to experiments. The long tail is a nice talking point, but in the real business world the short head, the really popular apps, get almost all the users. A better strategy would be to drive faster with the really important projects.

We don't know how to handle this situation, this abundance of implementation capacity, this excess speed, because in the past, we didn't see it. But the trends are clear. This situation will become more common. The organizations that can handle excess speed without pulling into the pit are going to drive past the competition in a hurry.

I can think of a few ways to channel that speed where we want it:

1) Train a faster driver: There are a few star product leaders with the product vision, technical depth, and pure stamina necessary to drive these fast processes the way a racecar driver drives a Formula 1 car. Where are they? Can they be made, not found?  Can we train new product leaders? I think we will be able to train people to do this. This is a new problem, and we are only beginning to figure out how to solve it.

2) Use evolution: We can build a machine that evolves the product by user-testing variations.  It will be an autopilot that responds to feedback faster than any human.  Every day that we come back and look at the app it is working on, it will be a bit different, more focused on the job we want it to do.  Is this science fiction?  No, it is the direct descendant of today's advertising optimization engines, which quickly learn to give users the offer they will click on.  This type of automation bypasses the limitations of the human workday. I will write further about that in future articles.

What do other people think?  Have you noticed that it is getting harder to keep up with the output development team?  Have you seen an organization start new projects to absorb capacity?  How do you handle speed?  Do you have any tips and tricks for agile product management?