[opportune]

Partially covered under others but as someone who has worked with PMs as an engineer: be a power user. If you are working on a technical product you should be an expert end user of the product. You don’t necessarily need to know how the entire product works under the hood, but if you don’t understand the product well enough to be an expert you’re probably not going to make good product decisions

[AlexDReeve]

Completely agree. The PM is there to help the team figure out what to build, and help them succeed in building it. They can do this in a number of ways: Being an expert on the product is "must have", but they also need to know the market, the needs of users/customers, the metrics, and more.

[ghaff]

That only applies to certain types of products though. Many years ago I was a longtime product manager for mostly large computer systems. I was very familiar with how they worked at an architectural level. But other than getting a cast-off Unix workstation on my desk at one point, I wasn't a user of the systems at all--and being so wouldn't have been practical.

[opportune]

I guess I have a hard time understanding how you would answer “what” questions in that position other than simply doing what customers asked. If you really didn’t need to add any new features other than what customers directly asked for I can kinda see how it would work. But how would you know how to advise customers on workarounds/that they are using the product wrong, or a future product roadmap, if you can’t see the product from a customer standpoint? I’m sure you could be an effective project manager in that position but to lead a product’s development without fully understanding how it’s used is a bit suspect to me.

[ghaff]

>but to lead a product’s development

My guess is--haven't really been a PM for other types of products--is that the relationship between the PM and engineering is probably different. I would certainly never have considered that I "led product development." And, yes, I did bring in requirements both from customers directly and from sales and I worked closely with engineering on defining the product. But actually--remember that product development cycles of big hardware were relatively long--after the initial requirements and basic design were worked out for a given system model--there often wasn't a huge amount for me to do until closer to launch when a lot of selling/marketing/pricing/etc. tasks had to get done. (I tried to plan my longer vacations during the quiet periods.)

To be clear, I wasn't just sitting around for months at a time as I was usually handling multiple products and involved in exploring new areas.

>if you can’t see the product from a customer standpoint?

As far as customers are concerned, big systems have a lot to do with specs, features, pricing, upgradability, etc. (And the availability of software.) They're not even maintaining them themselves.

[designium]

You brought up good points where for B2B and big corp type of product development requires different best practices. Also the politics from big corps or in B2B environments are very different than B2C. As simple as reviewing if you product via Google Analytics funnel can work for B2C, that may not apply vis-a-vis to B2B products. You can still use analytics to review, but usually the corporations are already focusing on another features and there is never enough time to revisit past products nor the budget to improve existing ones. Then, what does a PM should do?

[ghaff]

Open source is also a somewhat different situation that I'm familiar with but not as a PM. Obviously it varies depending upon the degree to which the project overlaps the product, but a company may be more in the position of influencing a community than dictating a product roadmap.