A Product Manager who produces such a high volume of requirements documentation that it creates a barrier to adapting to change, as the documentation must be kept up to date.

• Can mutate into: ”The Dictator” Product Manager
• Dangerous when coupled with: “The Blueprinter” Designer and “The Scientist” QA
• Likelihood of fixing: High
• Danger to project: Low

Problem

The core responsibility of a Product Manager is to articulate business requirements. On small development teams this can be done verbally, or through the use of terse requirements documents where the expectation is that the Product Manager will be consulted for details. On large projects (especially those involving remote teams) these requirements documents must be much more explicit, with minutia clearly spelled out to erase ambiguity that could lead to features being implemented incorrectly. The Patent Author Product Manager has written documentation so far out of proportion to what is needed, that they have introduced significant cost to making even the smallest change.

Generally, Developers do not enjoy reading long requirements documents, as they are dull, boring, and remove any opportunity for Developer creativity. QA, on the other hand, have the opposite reaction, as it makes writing test cases far easier if requirements details are spelled out in advance. However, verbose documentation comes at a cost: the documentation itself has to be reviewed, approved, and maintained every time there is a change.

The issue with the Patent Author Product Manager is one of change cost, which leads directly to opportunity cost. With the care and feeding of tomes of documents, the following legitimate sources of change have potentially huge project impacts:

• Threats from competing products.
• Feedback based on a customer reviews.
• Changed required due to technical feasibility constraints.
• Reduction to scope necessary to meet deadlines.
• Changes of opinion among stakeholders upon actual use of the product.

As the volume of documentation increases, the ability of the project to adapt to these changes decreases, yet over the lifetime of the product changes such as these are inevitable.

Solution

Bear in mind that the Patent Author Product Manager is only a problem when their level of documentation is substantially more than the project requires. There are many legitimate situations where explicit documentation is essential:

• Projects requiring non-trivial integrations, whereby all parties involved must build to a common specification for the integration to go smoothly.
• Projects that have hardware components, in that changing the hardware after manufacture is impossible.
• Projects involving remote teams across multiple time-zones such that documentation is the only practical means of communicating requirements.
• Project involving outside contractors, where project deliverables are tied to contracts, and therefore must be clearly articulated.

If the Patent Author Project Manager has proven to be problematic, the solution is to characterize the project as being Agile, as opposed to Waterfall. This difference is well understood as it relates to documentation, so simple defining the project as Agile and phasing out the existing documentation will eventually solve the problem. The challenge then is to educate the Product Manager on Agile methodologies, and provided they are open to the change (which they often are, as Agile places less demands on them) many educational resources exist.