A Product Manager whose requirements are so vague that the development team must fill in the gaps, only to be told their decisions were incorrect.

• Can mutate into: ”The Patent Author” Product Manager
• Dangerous when coupled with: “The Artist” Designer
• Likelihood of fixing: None
• Danger to project: Extremely High

Problem

The term “Back-of-Napkin”, is used to describe when high level concepts are quickly jotted down for illustrative purposes. This is typically done between high-level stakeholders, and as the name implies most often happens in an informal setting such as having drinks at a bar. The Napkin Sketcher Product Manager believes that this napkin sketch, along with a thin supporting documentation is sufficient for building the product, but after using the product is quick to point out that it was built incorrectly.

To be an executive, “Vision” and “Thinking Big” are practically prerequisites. This leads to a broad-yet-shallow view of products, whereby the core ideas are considered important, but the specific implementation of those ideas are not. This is considered perfectly appropriate in a hierarchical organisation, as vision comes down from above, to be implemented by those below. Indeed this can be quite healthy, provided that control of the specific implementation of those ideas is given up. However, the Napkin Sketcher wants control of the specific implementation despite the fact that they gave no guidance as to what exactly they wanted.

The Napkin Sketcher is all too common in the software development industry as:

• Defining requirements is hard, but loosely outlining vision is easy.
• The time burden is far less, as the sketch takes very little time, and to give feedback on what was build incorrectly can be done quickly in a live-demo setting.
• They can claim that they are only responsible for vision, but also want to “See things through to the end”, such that blocking what they believe to be misimplemented requirements is part of their job.
• They cannot be accused of making poor decisions, as they have never made any.

Napkin Sketchers cause a considerable amount wasted effort as developers build and rebuilt features. As a feature has to be fully complete before the project team can receive feedback, all of that work may have to be thrown away if it is not to the Product Manager’s liking.

The larger the scope of the project, and the larger the size of the development team, the more dangerous Napkin Sketcher Project Manager becomes as:

• More scope gives more opportunities for the development team to have guessed wrong.
• Large development teams usually means more work is being produced, and therefore more work that may have to be thrown away.

If there is no deadline, as typically is the case with R&D projects, then this process can be healthy, as innovation and discovery lead to the iterative refinement of ideas. However, most projects have deadlines and deliverables, and the Napkin Sketcher has the power to declare the project was built incorrectly at any time, for any reason.

Solution

The Napkin Sketcher Product Managers are either executives, or have executive aspirations. As a result, they cannot be fixed without altering their career ambitions back to being that of a lowly writer of requirements. However, while they cannot be fixed, they can be mitigated:

• Write the requirements for them, and have them approve what is written. Care must be taken to make sure they actually read the requirements.
• Have frequent review meetings with them, showing incremental progress. This will minimize any waste caused by them rejecting a final implementation.
• Put an intermediary Product Manager between them and the project team (see “The Executive Assistant”)
• Have them work directly with developers such that the developers can learn how to more accurately guess what they are looking for.