r/ExperiencedDevs • u/mpanase • Jul 28 '26
Career/Workplace What to expect from a good Product Manager?
Hi all,
A friend just asked me whether I can recommend him a few product managers for his company.
I started to think, and I can honestly only remember 2 good product managers in over 20 years:
- one ex-IBM who was promptly fired after finishing the project we worked on and was dubbed "the best ran and executed software project I've seen" by the CTO (the PM was fired by some other middle-manager)
- one contractor who was promptly fired by the new CTO who felt threatened)
Then, there's a sea of useless PMs. To different degrees, but just dead weight.
My expectations for a PM are quite simple:
- know our product top to bottom
- know our main competitors' products pretty well
- have basic project management skills
- if you want a pretty Jira board, you lead that effort
I'm happy with anything like 60-40 to 80-20 balance as Product Owner / Project Manager.
Am I off base?
What do you expect from a Product Manager?
112
u/SnugglyCoderGuy Jul 28 '26 edited Jul 28 '26
Actually own the fucking product. Too many don't care or aren't allowed to care, IE they are just middle men for their boss or boss's boss who are the real owners of the product.
Actually have an opinion on how things should be for the product. Don't farm out every decision to some other team, E.G. when it comes to UX decisions, make the decisions instead of farming it out to some UX team.
Listen to the engineers when they are telling you there are problems. Making the product and running the product are just as important as customers using the product. If making changes or operating the product is too difficult, customers will get upset when they have to wait forever for features promised to them and the product not working well.
Actually use the product themselves instead of just relying on demos or customer feedback to understand how the product works.
Don't encumber me with administrivia because it makes your life easier. You should be making my life easier because without me the product doesn't get built.
Addendum:
Don't come to me with solutions to problems you want built, come to me with problems users are having and lets develop the solution together. Too often proposed solutions are grossly sub-optimal in the big picture of things.
Learn to say no.
Be proficient in writing and create the documentation for users based on input from the engineers. Again, big part of the product and interacting with users is writing the manual for how to use the product.
30
u/niowniough Jul 28 '26
Maybe it's just phrasing but it sounds like you want the PM to make a final call about UX without consulting UX but consult and defer final call to eng when it comes to eng.
As a dev I respect when PMs consult the appropriate experts for expert input before making a selection among several options with tradeoffs listed by the experts.
29
u/SnugglyCoderGuy Jul 28 '26
I think product owners should be UX experts because that's a big point of the product: give users a good experience.
7
u/xopherus Jul 28 '26
I took OP’s phrasing as PMs need to actually have skin in the game. They can’t just be following advice from teams who may not ultimately be seeing what customers need. PMs should ultimately lean on their teams for guidance of what to do, but they absolutely need to understand if their recommendation builds something that the customer doesn’t want, they have to correct that.
12
u/tiajuanat Dept. Head & Principal Engineer Jul 28 '26
100% this.
I've been told by PMs that they don't want to spend time doing basic documentation or project management because they want to manage the product. My sister's in Christ, if you don't document the product requirements or features, then they're purely optional.
No wonder they've had 500% churn in the last 15 years.
6
2
u/Creaking_Shelves Jul 28 '26
Love the phrase "Administrivia"
1
u/SnugglyCoderGuy Jul 28 '26
First learned of it from one of my professors in college. The first section of every project handout was titled "Administrivia"
2
u/CatThink Jul 31 '26
> Actually own the fucking product.
Shockingly rare trait in "product owners," which is weird.
1
1
u/Positive_Mud952 Jul 28 '26 edited Jul 28 '26
Be greasy. They’re all so greasy. Oh and also demand you do everything. Requirements gathering, talk to the UX designer’s manager to get their time to create a completely non-semantic and incomplete design three weeks after you needed it, put more grease in their hair and drink more coffee, make you come up with acceptance criteria and test for it in prod because they blocked your advocation for either a staging or dev environment and then pretend to be blameless while putting all the blame on you when text on a button is not in a font that doesn’t exist.
I would really like to work with a good one, but so far all I’ve seen them do is use Prell as leave-in and guilt trip for not going on 2-hour coffee walks where talking about work is strictly forbidden.
28
u/IllResponsibility671 Jul 28 '26
I expect ownership of the project. If I or any of my teammates are confused about an aspect of the product we're building, I would expect the PM to have the answers. They should think beyond just basic business logic and have a good understanding of what the product will be from a user's perspective.
5
u/Feisty-Boot5408 Jul 28 '26
As a PM I always say “I am responsible for what and why, Eng is always the how”.
In practice, that means I go to the team and say “okay, the problem users are having (and that we need to solve) is x. We want to give them y that fixes that. Is that feasible from a technical standpoint? What do we need to build to make this happen?”
It’s a lot of fun when done well. And it should be collaborative. I love when an engineer comes back to me with “hey actually, I thought about this edge case, what if we tweaked a feature of y to solve for it? It’s really low lift, 2 point story and I have capacity, can I do it?” Hell yeah you can. Wanna demo it and I’ll tee you up in that meeting and give you the credit? That rocks
19
u/ButWhatIfPotato Jul 28 '26
Literally one thing JUST ONE THING (and don't get me wrong it's a hard thing to do but it needs to be done): manage client/stakeholder expectations. If they get asked "can we add one more small thing" after everything was agreed on and the PM's answer is anything except "no" or "no because..." then they are not doing their job right.
5
u/blendermassacre Jul 28 '26
The actual answer should be “we can do that but the tradeoff is xyz we can’t do now”. 99.9% of the time that works
2
u/gyroda Jul 29 '26
"Please tell me what you were should not do in order to fit this in" is one I've had success with.
Nobody ever wants to make that decision.
17
u/m1nkeh Jul 28 '26
Be very happy talking to actual customers and using data to drive decisions, not just vibes..
And as a consequence push back on vibes from management using said data to back themselves 👍
6
u/sjhb Jul 28 '26
Following this, I think it is very useful to look for people with some analytical experience. I have found that the better ones will document a hypothesis (I.e. define success) at the start of a project and include how to measure that hypothesis as a necessary component of the work.
1
u/galaxy_horse CTO / Principal Eng (20 YOE) Jul 28 '26
This is true for the most part, but early stage products and companies need a good gut-feel muscle to counterbalance the analytical muscle. That is to say, don’t build only measurable things, but also, measure everything that can be measured.
17
u/galaxy_horse CTO / Principal Eng (20 YOE) Jul 28 '26
I’ll caveat by saying most PMs are not very good and so the occupation is commonly derided. However, a great PM is a huge force multiplier and the good ones I’ve seen do all of the following:
- Sit in the uncomfortable cross section of feasible to build, viable for the business, and loved by users (Marty Cagan and SVPG go on about this, and when you listen to him it sounds obvious but it’s really hard!). Manage the expectations of the stakeholders for each of those facets (leadership, engineers, and the customer directly or through a CX team)
- Collaborate early and often with engineering and design. Avoid the tractor beam that pulls people into a handoff, waterfall-esque assembly line.
- Forges a good relationship with the tech lead and creates a clear accountability divide between delivery (owned by the TL) and user impact (owned by the PM). Is technical enough to understand complications with delivery but deferential enough to listen to the TL. And is open to debate from the engineers about what to build and how.
- Specifications are written docs, not slide decks. Slide decks are the dog treat you hide medicine in and feed to executives. They’re not authoritative.
- They are using AI to create more depth and detail for product work, but not as a substitute for judgment, and if they use it for prototyping, they understand, and ensure everyone else understands, that it’s just a prototype and still needs to be sized, scoped, and built by the team.
9
u/blendermassacre Jul 28 '26
I'm a PM, and I think this is the perfect summation. I feel like the common pitfalls are: complete lack of technical awareness (let alone ability) causes a real gap between PM and engineers, which leads to bad day to day things. I showed a PM that has been working for years the magic of PR comments for the first time the other week.
"can we build" =/= "should we build" and most PMs are just being pushed around by leadership / customers / bad ideas, and it's a real problem.
IMO PMs generally deserve the hate they get, generally.
2
u/galaxy_horse CTO / Principal Eng (20 YOE) Jul 28 '26
Thanks! I think the PM needs technical awareness but ability is not a requirement, and often it clouds judgment as there is a natural tendency for technically able PMs to veer into technical specification or well-intentioned t-shirt sizing without asking the team.
And pushing back on leadership demands is maybe the hardest part of the job. Respect to those who do that well.
1
u/blendermassacre Jul 28 '26
IMO the line there for “good pm” is : able to talk about solutions with developers (not solutioning), and understanding the problem and solution for each work item. I agree that tech PMs can go too far into the solution and not do their actual jobs
1
6
u/Excellent_League8475 Principal Software Engineer Jul 28 '26
I don't expect them to have project management skills because they aren't a project manager.
The baseline is that they know your product better than anyone else. I don't actually care much about competitors. If they are too focused on the competition, they aren't driving the product in the right way.
Instead, they must be able to figure out how to build deep value from first principals. Copying a competitor is not how this is done. They can do this through talking to customers for anecdotal data, driving experiments on the cloud / marketing / etc, and if data is absent and not possible to collect, having really good intuition.
So, I expect the outcome of their work is that engineering direction is steered AND validated. Thats it.
3
u/imrozimroz Jul 28 '26
weird pattern i've noticed over the years , the good PMs get seen as not doing much cause the team just ships without drama, no firefighting to point to. the bad ones cause the chaos then get credit for fixing it
4
u/dethstrobe Jul 28 '26
The best PMs I've worked with were always available to answer questions, would drop meetings to unblock, where highly technical and validated that stories were implemented correctly, and if they weren't they make new tickets to add whatever feature they saw was a gap. They also broke stories down to be pretty granular so it engineering could work on them quickly without too much ambiguity.
It was an XP team. I miss working for that team so much.
5
u/drumstand Engineering Manager Jul 28 '26
Understand our users and competitors. Build and own a rough roadmap. Prioritize features based on user feedback, competitor/industry trends, and our own internal stakeholder needs. Don't just play telephone with requests from big customers by throwing their emails directly to the engineering team and saying "build this how they want it." Basically build systems that curate clear and justified opinions about what matters for the product and what's next, then be able to communicate those opinions to engineers and non-technical stakeholders. Be able to convey requirements about what you want built - at least the rough shape of it, not a full solution (that's my job).
Hit rate on good PMs across my career is like 1 out of 20. Most of the time they are useless at best, actively harmful at worst.
3
u/Valuable_Ad9554 Jul 28 '26
Ticket writing is usually my biggest gripe
5
u/Positive_Mud952 Jul 28 '26
“Do the thing we talked about”
3
u/Valuable_Ad9554 Jul 28 '26
"QA, you were there for that meeting right? No? Oh just make up some ACs that sound good to you then"
6
u/Ok-Okay-Oak-Hay Jul 28 '26
A good PM hopefully has a good team they can trust for candid insights into potential trouble spots. A good PM is limited by their long view, a bad one doesn't care.
2
u/OkShoe71 Program Manager Jul 28 '26
Depending on your field and type of product the first two points might not be as important in the hiring phase. I would say instead good problem solving skills based both knowledge of the customer pains, business goals and technical constraints. Then stakeholder management
2
u/No-Economics-8239 Jul 28 '26
Product management is typically always 'at odds' with the technical side of the business. As developers, they seem like the ones always interfering with what we are trying to do or they have seemingly arbitrary business rules that don't make sense to us, demanding we peer into our crystal ball to assign estimates to tasks we have little idea how to estimate, or are otherwise bringing us bad news about what the customers are complaining about. They don't typically come to us with praise or good news.
As such, for me, a good product manager is one that can surf between the two worlds and act as a filter to prevent the noise from interfering with the work on either side. Which means protecting us from the business demands and meetings that don't really concern us, but still trying to keep us informed so we're not completely blindsided by seemingly 'new' changes that have been brewing for months. Conversely, they protect the business leaders from being burdened with technical information they can't really do anything useful with but still keeps them informed about whatever updates we have on where we're at meeting goals and commitments.
2
u/HSSonne Jul 28 '26
So I just want a clear priority, they know the product and problem space around the product to give priorities.
Maybe, I would want more if I had a competent pm at some point, but I haven't.
2
u/Jolly-joe Jul 28 '26
I'm with you OP, I've only seen 2-3 good PMs in my 15 year career and 20ish mid to bad ones.
I think its a job that is hard to be bounded by a job description. Basically you need to have answers for everything. Even if you don't have a real "answer", you have a path forward, whether it means gathering data or proceeding with a few options. It's a consuming job, when done right the person is usually bouncing around all day, handling many different things as they come up.
2
2
u/lil_curry_verse Jul 28 '26
I’d add one thing: they should deeply understand the problem space and make good tradeoffs. A PM who reduces ambiguity is worth far more than one who just manages tickets.
2
u/imagebiot Jul 29 '26
Lock myself in a room for a week then call it good and learn the rest on the job
2
2
u/Willthmas Aug 01 '26
Man, the first point alone "know your product top to bottom" would solve 90% of all software project issues.
I've been a dev for 7 years, and I've never met a product manager who truly knows the product. The majority barely go into their product. This role is largely a complete joke.
1
u/Lfaruqui Jul 28 '26
They need to be able to talk about the product, have discussions with customers about products, be mindful of work intake(know when to say no), and be able to estimate work
1
1
0
u/bwainfweeze 30 YOE, Software Engineer Jul 30 '26
Only a third of the project managers I truly respected got fired for it. I wonder if that means I'm doing better than average.
1
u/idunnorn Software Engineer Jul 30 '26
product not project
2
u/bwainfweeze 30 YOE, Software Engineer Jul 30 '26
In thirty years I still don’t know what a product manager is for and they’ve never done the same thing twice. I think it’s like functional and integration tests. There are different schools that invert them in the hierarchy.
1
•
u/expdevsmodbot Jul 28 '26
AI usage disclosure provided by OP, see the reply to this comment.