If you are a developer, I know what you are thinking: "We don't need them! They only make noise, create meetings and do no work!"
Well, you are wrong. They do make a lot of noise, create meetings and do not code. BUT, we do need them.
First some (mucho little) background knowledge about Product Manager job, whom I will call PM in this piece. There are two kinds and two types.
| type \ kind | Good | Bad |
| Inbound | ||
| Outbound |
While everybody can tell Good from Bad, Inbound and Outbound require explanation.
Inbound PM usually comes from development. He is a technical guy and feels at home with the architecture. Thus, the prefers to define to engineering how the product looks, behaves, what it does, how the features work and how many concurrent users it should support. Such PM works closely with the engineering and writes detailed specs from which architecture and test strategy/plans are derived. Writing those specs is a LOT of work! Microsoft has come with some magic number of 1 PM per 3 Developers. However, their PM's are also program managers, so you could get by with 1 PM per 5-6 developers.
Outbound PM can be recognized by the spec he provides. If the spec is an Excel file with one-liner per feature, then this is an outbound PM. Such PMs work with marketing, sales, professional services and customers. They concentrate all the input coming from the outside, analyze it and digest in PRD. Clearly one person writing such specs can provide a work for gazillion of engineers. Just write: time machine and teleportation. Done. BUT, gathering all this input, analyzing and deciding what is important and what is just a junk also a LOT of work. Still there is no need for 1:5 ratio, it easily can be 1:20 (depending on the project).
Clearly, this is a simplification, as just like people are not pure optimists and pessimists, PMs cannot be clearly cut into inbound vs. outbound categories. Most of the PMs are somewhere in between with some strong tendency towards one of the categories. This tendency defines the focus, effort, amount of invested time and consequently, deliverable content. In that order. Here actually lies a problem with PMs and this is the main distinction from optimist vs. pessimist separation. Wake up, this is the important part:
I (just like 99.999% of the people) don't need to decide whether I am an optimist of a pessimist. It does not matter to me and I don't care. PM, on the other hand, has to decide what type of PM he/she wants to be: inbound or outbound. He cannot be both and he cannot move from one side to another. Just like I cannot be both optimist and pessimist.
The problem is that some PMs do not decide, so they belong to the new category: "Not decided yet".
This leads to the following table and I will fill it in as well. There are no "pros" in "Bad" column for obvious reasons.
| type \ kind | Good | Bad |
| Inbound | Pro: the product advances really good and fast, and the product is very consistent to the users. Cons: the users might not buy the product as it does not solve their needs | Developers ignore those PMs, but they keep on trying to define low-level things, there are constant clashes between PM and Dev. |
| Not decided yet | PM is able to pull a little bit of everything. If Dev Manager is good and can do Inbound work (or at least part of it), then things will work out. If Dev Manager is not good, then PM will quit and the fate of the project will depend on the next PM. | There is no direction and no customers. PM and developers both clash one with another on daily basis (when PM decides to be inbound) and blame one another. |
| Outbound | Pro: the product does what customers want and solves real problems. Cons: The product looks like a patch-work. There are no conventions in UI, names or behavior. Each developer decides on something else and it shows. | Nobody wants the product and it also does not look good. PM and developers blame one another. |
To summarize this already long post: you have to decide whether to go with an affair or a spouse, and then do your best there. The indecision period is very risky.
No comments:
Post a Comment