"While the programmers are off building the next major feature, he is busy writing specs so that, when they finish, there won't be any idle time before they can start the next iteration."
This is essence of the problem right there. If the developers aren't involved in the design of what they're building, you have a broken process. The idea that you can "skimp" on talent such that you're hiring people to implement things you wouldn't trust them to design is pretty flawed; it means that you're developers are going to be producing a lot of crap by failing to see or find implementation-time improvements to the stuff in the abstract specs. And the idea that you can get that design right the first time at all, without having written a line of code, is fundamentally flawed.
The rest of the suggestions in the post seem to be attacking this solution sideways, by involving the developers earlier, iterating the specs, etc... But it doesn't seem to recognize the core problem. You can't "hand off" low-level specifications to someone other than the implementor. It doesn't work.
"This system naturally lends itself to a pipeline approach, which the product manager organizes."
Whoever came up with "the pipeline approach", or thought it would be a good idea, had never actually worked on any part of a project before. The reason the pipeline approach fails is because the people with the most knowledge about what is possible are at the end of the pipeline, and for some reason they are kept there. The implementers need to be learning the process they are implementing, before a spec is even written. I bet the majority of everyone's career has been spent being told to implement impossible requirements, or admitting that the requirements aren't actually impossible and having to say that the company doesn't actually have the time or the money to implement it (which is the logical definition of impossible, if not the physical definition).
"Focus on speed of iteration rather than utilization of every function. Let people go idle, if they can't help the current iteration succeed.... By letting them focus on the success of their team exclusively, you empower them to do whatever it takes to make the team successful."
This is, for me, one of the most important things we've learned in software development: self-empowered teams with a common goal can do things that compartmentalized teams cannot.
This is essence of the problem right there. If the developers aren't involved in the design of what they're building, you have a broken process. The idea that you can "skimp" on talent such that you're hiring people to implement things you wouldn't trust them to design is pretty flawed; it means that you're developers are going to be producing a lot of crap by failing to see or find implementation-time improvements to the stuff in the abstract specs. And the idea that you can get that design right the first time at all, without having written a line of code, is fundamentally flawed.
The rest of the suggestions in the post seem to be attacking this solution sideways, by involving the developers earlier, iterating the specs, etc... But it doesn't seem to recognize the core problem. You can't "hand off" low-level specifications to someone other than the implementor. It doesn't work.