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
Relevant Podcasts
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 has not realized the 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.
Hong Kong IT managers has no technical skill, remember this
Peter – I am an IT Manager and love Hong Kong. I think I have lots of skill. These are quite broad generalizations.
Because I am not familiar with development practices in Hong Kong, and because I always allow for leeway if I suspect someone speaks English as a 2nd language, I am never certain how exactly to interpret statements such as “Hong Kong IT managers have no technical skill”. It may very well be a fact that the practice in Hong Kong is explicitly that product managers in Hong Kong are not allowed to have a technical background for some reason. It’s a big planet with a lot of software projects, so I try to be open to new ideas. However, if the statement was intended as “There are no technically skilled managers in Hong Kong”, that would seem highly unlikely. I lack the insight to know the difference.
On-the-job experience has taught me that it is impossible to “create good new experiences” with Dictators. Dictators are authoritarians who resist any attempt to learn or do anything that doesn’t conform to their narcissistic terms and conditions.
One particular dictator was so immune to any kind of feedback or collaboration that half of my coworkers quit. Upper mgt blindly supported the Dictator, ignoring all pleas for some kind of remediation, even from our managers and sibling managers to the Doctstor.
I myself was a week from quitting—just wanted that resume in good shape—when this Dictator announced they were moving on themselves. (Afterwards I looked ill this person’s employment history. They had never worked more than two years anywhere, and their average stint was 11 months. Their tenure at my job was 13 months.) I waited it out another three weeks and like magic everything was better.
You can’t fix toxic. Dictators are toxic, end of discussion. Either they themselves are forced out, or you’re screwed.
Typo “does not realized” -> “has not realized”
Fixed!
As a product owner I’ve been subjected to the above treatment many times.
..even when laying down process for Dev input, making it critical path, allow Devs to write their own tickets if we all agree the subject is very technical and the goal is clearly defined.
The problem is often confusion on who set the vision – and who’s head will ultimately roll if that vision can’t be monetised.
A lot of people have strong opinions…
..but very few are prepared to carry the weight of monetisation = paying everyone’s salaries.
People usually want power – not the responsibility.