the problem with optimization.

I optimize things all the time.

Whether it's optimization in the true sense of the word (i.e. using a Newton-Raphson method to optimize a design to a particular set of parameters), or a more iterative approach to zeroing in on the best design, much of the product development work I do could be defined, in one way or another as optimization.

But then there's this (via Josh Porter).

 

How do you avoid optimizing to a local maxima?

 

Whether you are dealing with an actual numerical problem or are managing a product development effort, the principle is the same: procrastinate.

Just not too long.

Optimization cannot occur without constraints. In math-speak, if you have four variables, you need four equations in order to solve them simultaneously. This creates immense pressure for a manager to create equations (i.e. constraints) so that the solving can begin.

The reason that procrastinating on creating these constraints is such a good idea is that, by definition, you will know more about the product (it's use scenarios, technical limitations, marketing requirements) tomorrow than you do today. This equips you with the knowledge to make good constraints as well as (more importantly) avoiding arbitrary (i.e. bad) constraints.

Of course, you can't procrastinate forever; eventually the product needs to be shipped and the company has to make money. Where this line is drawn is dependent on the technology, product cycle, tooling lead times, etc.

The ability to procrastinate on these decisions just long enough to feel out a larger maximum while avoiding detriment to the goal of the project is what separates the great program managers from the rest.