Developers Guide: Why do we need Product Manager?

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.  

Career Advice: Stop Whining and Do Your Drill

"I feel stuck man. Not sure what potential I have at my current job. I just not happy here. People are great, but something is missing..." 

This is not the first I hear that, so I know exactly what to do. Usually I slap the guy, but this one looks like he could slap be back, so I smoothly move to the verbal part:

"Stop Whining and do your drill"

We, read as "software engineers", were trained to build products. Why your career is different? Do you know how to build a product? If yes, then you know how to build a career. Before I give you a recipe there is one catch. 

Career is not only climbing a corporate ladder. I have decided a long time ago that I want to work only on interesting stuff and made it a goal. Lately, I have noticed that I am good at building a new stuff, so I want to concentrate on that. One of my ex-co-workers decided that he wants to be happy and be home at 17:00. It can be anything really, not only "become a VP".

Now the plan:

1. Define where you want to be in 15-20 years. 
2. Divide it into 3 year chunks. 
3. Think how you get to the first milestone.
4. Get to work.

Oh, you don't know where you want to be in 15-20 years? Well, there is a different method then. Designed especially for guys that don't know what they want in a long-run: Agile Development. How does it look in Agile? Simple.

1. Define your goals for the coming 3 months. This should be easy as the goals are simple. They don't even have to be career/development goals. You can say: "I want to learn something new", "I want to feel that I've done something" or "I want to start some new project". It can be anything that you can somehow know whether it happened or not. I suggest to record your current state when you do that for comparison. You should also think about the goals and how to achieve them.
2. After 3 months check where you are. If you have achieved your goals, then return to step #1.
3. If after 6-9 months you are still unhappy, then you have to seriously re-evaluate your goals. There is something wrong with them or with how you achieve them. 
4. If after 9-12 months you are still unhappy despite all the above. Start looking for new options. It is not worth it. 
5. If after 2 years you are still unhappy and at the same place, come to me and I will slap you. 

Good Luck!

As a side note, the company I work for (EMC) has a quarterly goals system. It is mandatory, like in many other places. This system actually can be used for the agile method. It also will give you a feeling of purpose doing it.