The Napkin Sketcher

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.

6 thoughts on “The Napkin Sketcher

  1. With regards to solutions, and having been working under a Napkin Sketcher recently, I would say that “Enforcing requirements” is a fair an achievable strategy. Usually involves a light but constructive rejection of the story on the grounds that it needs more well-defined requirements. Follow-up grooming meetings are planned with tech lead, assigned developers and the PM in question who is forced to sit through technical grooming and therefore be present to answer questions as story is groomed and thus requirements are built. This ensures accountability from all members involved; thoughts?

    • There’s a difference between “I don’t give good requirements because I don’t know how” and “I don’t give good requirements because I don’t have to.” My though is that you encountered the former, by “The Napkin Sketcher” archetype refers to the latter.

      Most people – especially early in their career – need a bit of coaching from time to time to improve how they execute. If the requirements are no good, as you say a “light but constructive rejection” is just want someone may need to learn how to properly do their job.

      “The Napkin Sketcher”, however, doesn’t feel they have to go any further than a rough sketch of what they want. That means that *somehow* they gained that sense of entitlement, which in my experience usually comes part-in-parcel with an executive/VP/Director title. The solution is more of how to deal with these types of people, rather than to coach a well-intentioned person who simply needs a bit of guidance to improve.

Leave a Reply