[rsinger9]

A product manager who doesn't understand implementations will not be able to negotiate when an implementation bears on interface design or scheduling decisions. Conflicts arise all the time between implementation, interface and schedule. To resolve them one has to understand all three.

This doesn't mean the product manager must understand code. It means there's a trade-off. If they don't understand software implementation, they need somebody on the team who does (what the article calls a "Technical Product Manager.") Adding another person is possible, but it hikes up the overhead and communication costs while dragging down the speed of development and decision-making.

The best case is a product manager who can understand a given implementation if and when it bears on decisions about what is possible in the interface or the production schedule. That person can make informed decisions because they understand all the factors.

It's fine that not everybody can do all three, but imo we should stay conscious of the trade-off and keep the bar high.

[checoivan]

+1 on that.

Yes, you can be a PM without knowing code, but it's hard to be an excellent one.

A technical PM maybe doesn't code on a daily basis anymore, but one who understands technical challenges is highly valuable. A good PM who knows the chops can easily debug things when a customer calls, design good features and know whether it'll be easy or hard to implement,set more realistic goals,or call out BS from developers who says some easy task will take 4 weeks or something is impossible to implement.

[wslh]

I don't think so, you can have some middle men to be in charge of that and just shout very loudly if the things turn different. Obviously in this case you need a top team that is hard to find and build and was key in the Apple's case.

[noahlucas]

a middle man "shouting very loudly if things turn different" sounds more like a project manager, who gets a specific plan and tries to manage the development process after things have been prioritized and broken down by the PM and a tech stakeholder (usually more efficient).

I've noticed breakdown occurs when a PM is unable to understand and balance the constant push-pull of tech capabilities with desired functionality, or the ability to "satisfice"