Had this discussion many times and people have different opinions on this topic. I want to provide my opinion and would love to open this up for discussion. It really depends on the team, if you are on a ML or AL team, you should probably understand ML/AL concepts. Should you know how to code? Imo, no. If you are on a consumer facing product, imo, you should be more business savvy than technical. Yes, you should know what a server or a backend is, or what an API is to help write features or stories for the teams, but there should be tech leads/archts/devs that should lead the solution from a technical perspective. At the end of the day, when a PM is too technical, it takes away from what a dev should do. Imo, the dev starts relying to heavily on the PM and takes away from the creativity a dev should have. PMs should know enough to understand wether something is a risk or a blocker or even support how they prioritize their features, but when they get to technical, again, imo, it takes way a lot from allowing the devs to own the solution. #Google #meta #product #Amazon #Netflix #apple #workday #oracle PM = the “what” and the “why” TPM = “why” and the “how” Dev = “how” = solution
I find it incredibly frustrating when PM's aren't technical enough to contribute to feasibility discussions. PM's should be engineers looking to move into management, not business majors trying to manage engineers.
1000% disagree. Product managers are the face of the customer. You do not need to be a engineer to understand the needs of the customer…
50% customer facing work, 50% herding cats. PMs take customer requirements, make sense of them in the context of the product, and drive engineering focus to meet those needs. If a PM doesn't understand why a feature could or could not be added, then they dilute the communication chain, or worse, promise something the engineering team can't deliver.
Pm bulid a web 2 product in 2021, customers can not even be bothered to shrug
As per your definition of PM, TPM and Dev roles in the post, there is overlap between the responsibilities.. which is what causes the confusion. Define clear cut distinction and there is no problem.
Agreed. I think the issue is these roles are not clearly defined and definition is thrown up for individuals to define which Sets wrong expectations
PMs should always be technical. Non-technical PMs are usually useless
What’s your definition of technical?
Prior Eng. MBA PMs are glorified business analysts
To != too btw. Its really interrupting the flow with these errors. I agree with others above, non-technical PM could be a disaster to a team. Recently trying to hire a few DS director positions and dropped all non-technical candidates. Simply bc they wouldn’t be able to lead/support when needed.
Again, not saying PMs should not be technical, but the question is how technical?
@FedEx, mixing too and to makes the post confusing. PM needs to be technical to some degrees but need not to be the tech lead. However, there are the types who don’t know how to tone down the technicality when communicating with non-tech people or overstepping the tech lead role when they (PM) are not really competent in technical — they are to be avoided at all cost.
Tc?
Disagree that PMs should not be technical. They don’t need to code, but they do understand the tech stack and constraints on what is reasonable, and strike that balance with customer requirements. I have seen PM after PM lose credibility and value because they write something without understanding reality, and it turns out useless for the team.
Yea but what I stated was just that. They should know enough to support how they define requirements. For example, if a single source of truth DB does not support xxx fields, understanding that maybe we can dev these changes and save to a local DB until that ssot is ready, but also understand the risk in doing so, which could be duplication of data. So yes, PMs should still have a level of technical knowledge, but some people think PMs should be able to code, and live in Tables Querying data all day. That’s the point of have a dev team and leads. PMs are to help provide guidance on what to work on and why.
Ok that makes more sense. I hear you, but bottom line is PMs add value by bringing focus and business impact. If the devs don’t get this value, they are going to ask PMs to do what they think. Sadly, most PMs don’t focus on this value add and it ends up hurting them as well as the team.
With regards to technicals PMs should.. - grok basic technical concepts like how web apps work (frontend <-> backend <-> db) - know your tech stack (what lang on frontend, backend.. helps keep up with ENG convos and tickets) - know how your data is modeled and what different collections or tables you have - understand general technical workflows and tooling (e.g basic AWS services and what they are used for) PMs should not.. - read or review code (IMO this includes SQL unless you're at a small co) - write technical specs/schemas - have to figure out what algo to use - be responsible to test or QA non-user facing code (e.g testing that a new service returns a certain response or something) Note a lot of this is a generalization. AI/ML or tech PMs (working in infra) are exceptions to some of this. Some people would say a good PM does some of the things in the last list. I'd argue a great PM knows the boundaries and would never.
This is a great post. Thank you! I agree 100%%% Even with your second point regarding the tech stack. If a defect comes up, the dev should provide enough info for the PM to document anyways. So, it’s just team work. Next point regarding tables. I do agree to an extent. You should know where the data lives and how many tables you have. For for example, where does customer purchase history live vs customer passwords, etc.. this does help
@Braze - what do you think about PMs writing SQL to find potential opportunities for new/improved features?
I used to be of the view that you wrote at the end of your post i.e. Devs own the how, however, am reading Continuous Discovery Habits and the advice on there is that of PM/Engineering/Design to work together in problem + solution space as the solution may change as we learn new information during the discovery process about the problem at hand - I agree with it but haven't done so in practice yet. Keen to learn how other PMs achieve the CDH methods. Personally, I disagree with the way and how the OP has answered some questions....I believe successful PMs work in equal partnership with engineering & design and have no ego about solutions.
I’m a bit confused with this post. No where did I mention PMs shouldn’t be part of the technical solution. At the end of the day everyone should support each other on the team, but you need to set expectations regarding roles and responsibilities or you will have more bumping heads than delivering any value. This post is referencing individuals who say PMs should get into code and help debug issues, provide technical solutions for the devs, etc.. this should not be the job of a PM. Many people confuses the role of a TPM and a PM. TPM owned execution and the PM is more strategic. Every company is different yes, but generally you need structure when it comes to who owns what. That’s not to say you can work together on the business or technical solution. My devs reach out everyday asking for my opinion on some of the solutions they come up with and I don’t mind. I also apply this same logic to UI/UX, so I think you’d agree with me more than you disagree.
Okay, so what you said here makes sense. I agree with not needing to get into code etc. (Most likely I misunderstood earlier as I skimmed through)
Pm = product manager or project manager or program manager? Project manager doesn't need to know much at all. Product manager needs to know constraints and feasibility and rough timelines and enough to converse roughly with eng. Pgm idk
Product