The Dictator

A Product Manager that rejects any idea that did not come from them.

  • Can mutate into: ”The Patent Author” Product Manager
  • Dangerous when coupled with: “The Diva” Developer
  • Likelihood of fixing: High
  • Danger to project: Low

Problem

Despite a movement towards collaboration, the software development industry still has a clear division of labor: Product Managers write the requirements, and Developers write the software. There are Product Managers who believe that Developers should only write software, and that the defining of requirements should be done exclusively by them. This mindset then prevents developers from providing the Product Manager feedback on:

  • The cost of a feature, allowing the Product Manager to make prudent choices on the relative importance of what they are asking for.
  • Simplifications in features that would allow a faster time to market without reducing the product’s business value.
  • Changes in features to allow the development team to use preexisting capabilities, or to use off-the-shelf solutions.

The Dictator Product Manager either does not realized these benefits of collaborating with developers, or has decided that this level of collaboration is not worth doing. It is rare that a Product Manager would not be aware of these benefits, and it is therefore much more common that they feel it is not worth doing. Sadly, this is most often a result of bad past experiences with Developer collaboration.

There are some situations where Developers should implement the requirements handed to them without question, as when the Product Manager is an expert in a domain the Developers know nothing about. However, these situations are not common, and generally projects will benefit immensely from having Developers give their input to the requirements.

Solution

If The Dictator Product Manager does not realize the benefits of collaboration with developers, a relatively short discussion with them from upper management will settle this rather quickly. This will most likely come as a relief, as they can now share ownership of the product direction, reducing their burden to be perfect in every product decision.

More often, however, The Dictator Product Manager has been made through bad past experiences with developers where:

  • They were subtly or not-so-subtly accused of not knowing how to do their job, or of being little value to the project.
  • They were seen as merely shepherds of requirements (see “The Executive Assistant“), rather than having any real decision making power, and therefore having no say in product direction.
  • After “collaboration”, very little of their original product direction remained, as developers chipped away at requirements claiming requirements were wrong or technically unfeasible.

As bad past experiences are the cause of this variant of The Dictator, the solution is to create good new experiences. To this end, a representative of the developers should approach The Dictator with assurances that the experience of collaboration with them will be pleasant and productive (see “The Peacemaker” Development Manager). This same representative should then facilitate developer requirements review meetings to keep the collaboration healthy, shutting down developers who would squander any nascent goodwill.


Having a problem with a Problem Personality? I offer Coaching for you or for them!