
The product manager's lament (why do I have to rewrite specs five times?) - eries
http://startuplessonslearned.blogspot.com/2008/10/product-managers-lament.html
======
ajross
_"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.

------
thwarted
"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).

------
ivey
_"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.

