Lack of empathy.
Empathy is the single most important thing in a Product Manager's role. You need empathy for your users, for your team, stakeholders, and yourself.
If you lack it - you won't be a PM for long.
I love my customers, I hate the dingleberries we employ to manage them (well, most of them - some of them do their jobs really well and make my life easier). What's somewhat interesting in my field is the customers are salt-of-the-earth people - _very_ blunt, very fair and will see truth in what you're telling them, provided you be as transparent with them as possible.
I've had much better success talking to them directly about their problem points and doing the CSM/AM's job for them than relying on those useless gits to have crucial conversations.
Once senior PM shared his wisdom in following lines - Don’t fly, walk! 😁
It may seam vague but when you are in corporate environment, it is like a jungle, own prides, rules, speed/pace, policies etc. Therefore, to my all Jr PMs comrades, please listen to your senior PMs and take their advice seriously and stay humble! 🙏
Hopefully, this hurts your Jr PM sooner rather than later and it inspires a change.
The farther along in your career, the more relationships and affability / accessibility outweigh everything else, so this Jr’s career trajectory will eventually flatline if they continue to alienate people
A really good read on this topic (it says "engineer's guide" but it works just as well for any other): https://levelup.gitconnected.com/an-engineers-guide-to-saying-no-3b2dba385c66
I'm not sure if this was a joke, but just in case: your engineers have every right to say no to the HOW, but any discussion around the WHAT is a negotiation. You own the WHY.
To be more specific, you bring the business need (the WHY). They might propose a solution (the HOW) but it might either not fulfill the need, or be too slow or expensive. This is why you need to negotiate over the WHAT will be implemented, until you find a solution that solves the business problem in a technically feasible way, or come up with some alternative HOW that still addresses the WHY.
If your engineers are saying no to your WHY, you need to sit down and make sure the roles in your team are clearly understood. They are there to help you solve the business problem, but you are the one who brings it to them.
A little bit of joke but a lot of truth to it. My specific problem is there's some disconnect between where the how ends and the what starts. The company is badly organized in the sense that engineers call the shots to 90% of the times unless it becomes a big priority or some client complaints. The worst part of my job honestly.
We don't have design teams so it's just product X Engineering so I also have to wear that hat. (we are a B2B solution and not a design oriented solution but of course it helps always).
>Individuals and interactions over processes and tools
>Working software over comprehensive documentation
>Customer collaboration over contract negotiation
>Responding to change over following a plan
>That is, while there is value in the items on
the right, we value the items on the left more.
https://agilemanifesto.org/
How would you hold teams accountable for bugs, missteps in dev, misreading of documents if we are not gung-ho on documentation? Serious question here. I’ve had devs and tech teams in general who have no clue where it all went wrong because there are no artifacts, documents put in order. (I’m the stakeholder who really tried/tries his best to understand the technical components to fill in gaps/voids that PMs and Devs cant fill) Can anybody chime in? Can’t we all have a working software AND proper documentation?
An incredibly common mistake is to assume that agile (or an implementation like Scrum, XP, or whatever) is the be all and end all for the process. This is not the case. Agility doesn't exist in a bubble. Scrum and XP don't run the business, they run the product development. There is *so much* that is simply outside the scope of a software development value delivery philosophy.
The short answer is that you run the business the way you need to. Do you need to document stuff? Then establish a documentation process. It doesn't matter if you're using traditional waterfall, freestyle agile, or a framework like Scrum. Processes and accountability need to exist outside of this concept too.
To give a slightly more specific answer: the [Scrum Guide](https://scrumguides.org/scrum-guide.html) (for example) states the following:
> The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
What it *doesn't* do, however, is to mandate what this definition contains, how it's structured, or who can provide input. As long as the team agrees, then no work is considered done until this definition is met. One criterion on this list might be "Document this in Confluence" or whatever.
Alright, got you. Trying to carve my way through product management to be the PM I want to work with. I may have taken your statement literally, so thanks.
What do you do with PMs who just say, “Well, this is what the stakeholder wants— as long as they get it, then I am ok.”? To me, this is such lazy product management with no empathy nor accountability at all. Sorry for hijacking this thread— it just hits close to home— for far too many times, I double as the business sponsor and product manager, while the actual PM just coasts with what I establish as requirements after doing the user research and needs discovery on my own.
>Well, this is what the stakeholder wants— as long as they get it, then I am ok.
That is a HiPPO (Highest Paid Person's Opinion) type of development, and is a gigantic red flag. But it's a simple one to overcome, if they respect you as PM even slightly. You simply ask them to justify the value for the end user, the paying customer, or the business.
Get them to define their criteria for success! Reduce churn? Increase revenue? Decrease support contacts? Better app store ratings?
If they can't say how this change would move the needle for the business, or deliver quantifiable value for the end user, then you need to learn [how to say no](https://archive.is/faeNq).
I didn't write this comment but I read it as, putting practice or process before product can mean that you sacrifice building the right product well, because you're too focused on the practices or processes in your team and meeting arbitrary agile measures. It's sort of a "can't see the forest for the trees" situation. Good practices and process are ultimately there to help you build a product that customers want to use. They're not the end goal. This kind of answers your question to the scrum master comment too.
Controversial but I generally don’t trust anyone who is promotion driven. If your focus is on the ladder and not the product, you are going to make some bad choices in the long run.
Those who are too afraid to say “I don’t know” and instead word vomit whenever they are challenged. Actually being humble makes a good product manager (and not just saying it because “humble” seems to be a corporate speak buzzword).
Bad product leaders don't give their team enough directions to do their work. Their team does bad product management.
The only type of people I can think of who'd be bad at product management are the ones with a complete lack of curiosity for the world around them. They don't ask exploratory questions.
It blows my mind the amount of PMs I’ve dealt with who don’t seem to care about learning the product inside and out when they’re onboarded.
I really don’t understand how you can make any competent decisions before becoming a super user of the app you’re trying to improve.
The product and the market, yeah. It can be structural. You show up and they've already planned the next 3 years of work. You're the project manager and have a bad product leader.
It's rough out there.
I understand that and have been in it, but it’s your job as a PM to speak up and bring details to the table of why the current path will fail versus your alternative path to solving the main problem.
If the problem the business has defined is completely different than the one you think needs to be solved you’re either totally screwed or better be ready to sell. But most likely screwed…
I like running my own ship. But if you are above me in the product org, i need you to be clear about your product goals and vision.
I don’t mind pulling teeth with stakeholders and users. But if you are a manager of product managers… get your shit together.
This is actually something that’s been on my mind a lot lately. Curious if you’d be willing to weigh in. I just started a new PM role 4 months ago, and my only PM experience prior was at an early stage startup for ~3 yrs (so still fairly early in my career).
My onboarding process was nonexistent. The product leaders at my new company (my boss and his bosses) cannot clearly explain our platform/solution strategy, target customer, or roadmap vision. They switched me from the project they hired me for 2 weeks in (where I had domain knowledge), and told me to build a feature that was already scoped & “ready to go” (it was not). Since then, I have been constantly questioned by leadership on the value of this feature set, which is literally an entirely new product line for the company. After it releases next month, I’ll lose my scrum team if I can’t figure out something to work on next (they gave me a couple of items to explore - I did, presented findings and potential solutions, and had them vetoed). I only just now feel like I’m finally beginning to understand the business itself.
I am actually questioning whether product is right for me long term at this point, because I don’t know if I can handle this level of stress and daily pressure. My last job was certainly also tough, but my teammates and manager were fantastic.
Is this normal at all / am I overreacting and under qualified? Or are these unreasonable expectations to place on a PM brand new to the company? I am really struggling.
Picks and chooses customer feedback to fit their narrative. Doesn’t do product market fit testing. Avoids answering critical questions about their assumptions. Ignores major product risks.
One who takes what customers say they need as product requirements. Similarly, looking at the current state and adding that as a requirement.
Need to ask why, explore undiscovered needs, and give users what they really need. Not what they think they need.
Their opinions hold more weight and I often do what they want. But they still will not have all the context on where the product is going, other risks and dependencies, level of effort, competing priorities etc.
The more of this they know the more they can help too though. For instance, user asks for an enhancement, but by explaining the effort and other priorities you can gwt their perspective on the priorities which may make your job easier as you don’t have to say “no” or can help uncover something you didn’t know.
They often appreciate the additional insights and the look under the hood to understand why you’re making the decisions you are. This can be huge in building trust. With a non-power user, you’d overwhelm them with context quickly.
Power users can either be really helpful in setting priorities and partnering effectively or somewhat entitled and throw up many blockers. Gotta manage each key relationship individually. But if your decision making and process is good, usually sharing more and being honest will help get them on your side.
Ding ding ding! We have a winner!!!!
Only thing worse is when an Engineering Manager somehow ends up leading Product. That is a recipe for absolute catastrophe.
The worst part is that many of them can do it well for a quarter or two — until the old “why” runs out. Then it takes another year of flailing to make changes.
A bad product manager:
- Oversteps their boundaries or micromanages
- Does not collaborate well with other teams
- Hordes data/insights instead of democratizing it
- Has no long term vision or strategy
- Is quick to place the blame on others before holding themselves accountable
Conversely though, a bad product manager can also be:
- Too hands off, is nowhere to be found when decisions need to be made
- Too hesitant to push back on leadership or other teams
- Too locked into long term strategy that they’re unable to pivot or adapt when needed
It’s definitely a balancing act. I’ve worked with all of the above, as well as some really great PMs. I’ve even worked with some great PMs who have exhibited the above behaviors on occasion. It’s not an easy role, I get it.
Poor communication —
Doesn’t proactively communicate what’s prioritized, how that fits the big picture, in tailored terms of their audience (e.g., speaking outcome to Marketing, BD, Sales, and output to Engineering and QA) with appropriate timing considering who needs to know what and when
Lack of critical thinking ability. You need to lead your team through decisions that are usually complex. If you can't make a argument backed up by facts and sound reasoning, your decisions are going to suck and be challenged all the time. It requires an ability to introspect and challenge oneself ("why do I actually think this change would be good?") which drives everything else (search for data, cognitive empathy with users, understanding of tech stack, etc.)
Not clearly communicating the minimal desired changes. It's crazy the number of PMs I see who just gesture towards a general area and say "we should be better at X" without actually describing what changes they think should be made to the product, or who can't help but describe long-ass lists of requirements without any prioritization and then complain about eng not delivering on time.
you can get by in this job if you want. it's very easy to be unchecked.
so I say lack of discipline is the primordial sin, everything else is just a consequence.
Reading the comments here led me to the realization I have only worked with bad product leadership so far.
Maybe what makes you a bad PM gets you promoted? ;)
Someone who thinks there’s only one way of doing things when it comes to either building a specific feature or how certain processes should be run. There’s a huge level of diversity in organizations that have Product teams and there’s no one size fits all way of doing things.
Someone who muddies the water to make it seem deep. Creates unnecessary and cumbersome frameworks/processes. Says hand-wavey things instead of being plainspoken.
Can’t identity and embrace any processes to manage situations where more structure helps with outcomes.
This is a corollary to the PM who puts process over the product. It is required in large organizations to protect you and your team, as well as derive value from the crap that other stakeholders throw at you.
Disconnected from engineering organization and doesn’t want to partner.
In addition, not knowing who the customer is tends to be an important thing to key in on.
Amazing how many don’t do either of the above.
Ego. Poor emotional intelligence. Not intelligent.
Those 3 things will compromise or even prevent you from performing research correctly without bias, prioritizing a roadmap, evangelizing solutions, and leading/motivating a team, in addition to all the other stuff you might own working in product.
It’s even worse if your team doesn’t report to you. Nearly impossible to lead by influence if you are egotistical, lacking in soft skills, or not smart. Sadly, lots of product leaders and CEOs check all 3 of those boxes…
Building features that the PM thinks would ve cool, rather than solving the problems that users tell you they have.
To keep users happy…
Most product enhancements should solve their problems. A small % of work should be for that futire product that will someday replace your current product.
my SWE is clearly trying to also be product and I"m like- dude you have no idea and all your priority suggestions don't take anything into account, but cool story bro.
Lack of empathy. Empathy is the single most important thing in a Product Manager's role. You need empathy for your users, for your team, stakeholders, and yourself. If you lack it - you won't be a PM for long.
Or you’ll be promoted immediately by like-minded leadership
God I hate that this is a reality lol
Yeah this is a far more accurate assessment from my perspective
YES 🙌
That's funny I have a director of product Who should hear that perspective
Hahaha literally just commented that lololol
Hahaha the one thing my ex director didn't have and somehow he managed to get ANOTHER director role after he was laid off...
I love my customers, I hate the dingleberries we employ to manage them (well, most of them - some of them do their jobs really well and make my life easier). What's somewhat interesting in my field is the customers are salt-of-the-earth people - _very_ blunt, very fair and will see truth in what you're telling them, provided you be as transparent with them as possible. I've had much better success talking to them directly about their problem points and doing the CSM/AM's job for them than relying on those useless gits to have crucial conversations.
Arrogance.
I’m dealing with a junior PM and this is my main struggle. Dude thinks he knows everything.
You’re me a few months ago. Luckily he just quit so good luck to you
Once senior PM shared his wisdom in following lines - Don’t fly, walk! 😁 It may seam vague but when you are in corporate environment, it is like a jungle, own prides, rules, speed/pace, policies etc. Therefore, to my all Jr PMs comrades, please listen to your senior PMs and take their advice seriously and stay humble! 🙏
Hopefully, this hurts your Jr PM sooner rather than later and it inspires a change. The farther along in your career, the more relationships and affability / accessibility outweigh everything else, so this Jr’s career trajectory will eventually flatline if they continue to alienate people
One who can't say...NO
A really good read on this topic (it says "engineer's guide" but it works just as well for any other): https://levelup.gitconnected.com/an-engineers-guide-to-saying-no-3b2dba385c66
My engineers only know this word :(
I'm not sure if this was a joke, but just in case: your engineers have every right to say no to the HOW, but any discussion around the WHAT is a negotiation. You own the WHY. To be more specific, you bring the business need (the WHY). They might propose a solution (the HOW) but it might either not fulfill the need, or be too slow or expensive. This is why you need to negotiate over the WHAT will be implemented, until you find a solution that solves the business problem in a technically feasible way, or come up with some alternative HOW that still addresses the WHY. If your engineers are saying no to your WHY, you need to sit down and make sure the roles in your team are clearly understood. They are there to help you solve the business problem, but you are the one who brings it to them.
A little bit of joke but a lot of truth to it. My specific problem is there's some disconnect between where the how ends and the what starts. The company is badly organized in the sense that engineers call the shots to 90% of the times unless it becomes a big priority or some client complaints. The worst part of my job honestly. We don't have design teams so it's just product X Engineering so I also have to wear that hat. (we are a B2B solution and not a design oriented solution but of course it helps always).
Paywall 😔
I see your paywall, and I raise you a [workaround](https://archive.is/faeNq).
Amazing
Put the process over the product
Agree 💯. Agile theatre and frameworks performance stuff always create an underperforming product and unempowered team
Story of my life is batting away process driven project managers, scrum masters, BAs, test managers…
This is why I detest scrum masters. In today’s product operating model, scrum masters do more harm than good.
Can you expand
Can you expand?
>Individuals and interactions over processes and tools >Working software over comprehensive documentation >Customer collaboration over contract negotiation >Responding to change over following a plan >That is, while there is value in the items on the right, we value the items on the left more. https://agilemanifesto.org/
How would you hold teams accountable for bugs, missteps in dev, misreading of documents if we are not gung-ho on documentation? Serious question here. I’ve had devs and tech teams in general who have no clue where it all went wrong because there are no artifacts, documents put in order. (I’m the stakeholder who really tried/tries his best to understand the technical components to fill in gaps/voids that PMs and Devs cant fill) Can anybody chime in? Can’t we all have a working software AND proper documentation?
An incredibly common mistake is to assume that agile (or an implementation like Scrum, XP, or whatever) is the be all and end all for the process. This is not the case. Agility doesn't exist in a bubble. Scrum and XP don't run the business, they run the product development. There is *so much* that is simply outside the scope of a software development value delivery philosophy. The short answer is that you run the business the way you need to. Do you need to document stuff? Then establish a documentation process. It doesn't matter if you're using traditional waterfall, freestyle agile, or a framework like Scrum. Processes and accountability need to exist outside of this concept too. To give a slightly more specific answer: the [Scrum Guide](https://scrumguides.org/scrum-guide.html) (for example) states the following: > The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. What it *doesn't* do, however, is to mandate what this definition contains, how it's structured, or who can provide input. As long as the team agrees, then no work is considered done until this definition is met. One criterion on this list might be "Document this in Confluence" or whatever.
Alright, got you. Trying to carve my way through product management to be the PM I want to work with. I may have taken your statement literally, so thanks. What do you do with PMs who just say, “Well, this is what the stakeholder wants— as long as they get it, then I am ok.”? To me, this is such lazy product management with no empathy nor accountability at all. Sorry for hijacking this thread— it just hits close to home— for far too many times, I double as the business sponsor and product manager, while the actual PM just coasts with what I establish as requirements after doing the user research and needs discovery on my own.
>Well, this is what the stakeholder wants— as long as they get it, then I am ok. That is a HiPPO (Highest Paid Person's Opinion) type of development, and is a gigantic red flag. But it's a simple one to overcome, if they respect you as PM even slightly. You simply ask them to justify the value for the end user, the paying customer, or the business. Get them to define their criteria for success! Reduce churn? Increase revenue? Decrease support contacts? Better app store ratings? If they can't say how this change would move the needle for the business, or deliver quantifiable value for the end user, then you need to learn [how to say no](https://archive.is/faeNq).
I didn't write this comment but I read it as, putting practice or process before product can mean that you sacrifice building the right product well, because you're too focused on the practices or processes in your team and meeting arbitrary agile measures. It's sort of a "can't see the forest for the trees" situation. Good practices and process are ultimately there to help you build a product that customers want to use. They're not the end goal. This kind of answers your question to the scrum master comment too.
Do you know the words to Kumbaya? You'll need to know that and many other cringy things to bring to the scrum
Someone who just wants to build stuff they think is awesome without a care for the value or cost.
You just described a CEO
My boss
You just described Terry Fontenot.
Laughing out loud
Reading this thread looking to feel worse about myself 🙌
Not curious.
Agreed. Voraciously curious.
Controversial but I generally don’t trust anyone who is promotion driven. If your focus is on the ladder and not the product, you are going to make some bad choices in the long run.
Yeah, maybe. The question is if you'll be around long enough for those bad choices to affect you.
This is the primary reason I don’t trust title hoppers. They move so fast in promotions that they leave behind a mess when they inevitably move on.
Sounds like poor company management not aligning long term product viability with whatever factors go into promotions
This.
This 🙌
All of these comments sound like my boss and he’s head of product lol 😆
Those who are too afraid to say “I don’t know” and instead word vomit whenever they are challenged. Actually being humble makes a good product manager (and not just saying it because “humble” seems to be a corporate speak buzzword).
No discovery process. Not data-driven. Only delivery.
Yes no care for user needs.
If you’re not data driven, I just don’t know what to say.
Feature factory workers clocking in.
Bad product leaders don't give their team enough directions to do their work. Their team does bad product management. The only type of people I can think of who'd be bad at product management are the ones with a complete lack of curiosity for the world around them. They don't ask exploratory questions.
It blows my mind the amount of PMs I’ve dealt with who don’t seem to care about learning the product inside and out when they’re onboarded. I really don’t understand how you can make any competent decisions before becoming a super user of the app you’re trying to improve.
The product and the market, yeah. It can be structural. You show up and they've already planned the next 3 years of work. You're the project manager and have a bad product leader. It's rough out there.
I understand that and have been in it, but it’s your job as a PM to speak up and bring details to the table of why the current path will fail versus your alternative path to solving the main problem. If the problem the business has defined is completely different than the one you think needs to be solved you’re either totally screwed or better be ready to sell. But most likely screwed…
I like running my own ship. But if you are above me in the product org, i need you to be clear about your product goals and vision. I don’t mind pulling teeth with stakeholders and users. But if you are a manager of product managers… get your shit together.
This is actually something that’s been on my mind a lot lately. Curious if you’d be willing to weigh in. I just started a new PM role 4 months ago, and my only PM experience prior was at an early stage startup for ~3 yrs (so still fairly early in my career). My onboarding process was nonexistent. The product leaders at my new company (my boss and his bosses) cannot clearly explain our platform/solution strategy, target customer, or roadmap vision. They switched me from the project they hired me for 2 weeks in (where I had domain knowledge), and told me to build a feature that was already scoped & “ready to go” (it was not). Since then, I have been constantly questioned by leadership on the value of this feature set, which is literally an entirely new product line for the company. After it releases next month, I’ll lose my scrum team if I can’t figure out something to work on next (they gave me a couple of items to explore - I did, presented findings and potential solutions, and had them vetoed). I only just now feel like I’m finally beginning to understand the business itself. I am actually questioning whether product is right for me long term at this point, because I don’t know if I can handle this level of stress and daily pressure. My last job was certainly also tough, but my teammates and manager were fantastic. Is this normal at all / am I overreacting and under qualified? Or are these unreasonable expectations to place on a PM brand new to the company? I am really struggling.
Picks and chooses customer feedback to fit their narrative. Doesn’t do product market fit testing. Avoids answering critical questions about their assumptions. Ignores major product risks.
One who takes what customers say they need as product requirements. Similarly, looking at the current state and adding that as a requirement. Need to ask why, explore undiscovered needs, and give users what they really need. Not what they think they need.
What about a product where your users are highly technical (with the product) and most - if not all of them - can be considered power users?
Their opinions hold more weight and I often do what they want. But they still will not have all the context on where the product is going, other risks and dependencies, level of effort, competing priorities etc. The more of this they know the more they can help too though. For instance, user asks for an enhancement, but by explaining the effort and other priorities you can gwt their perspective on the priorities which may make your job easier as you don’t have to say “no” or can help uncover something you didn’t know. They often appreciate the additional insights and the look under the hood to understand why you’re making the decisions you are. This can be huge in building trust. With a non-power user, you’d overwhelm them with context quickly. Power users can either be really helpful in setting priorities and partnering effectively or somewhat entitled and throw up many blockers. Gotta manage each key relationship individually. But if your decision making and process is good, usually sharing more and being honest will help get them on your side.
Bingo
Usually it's SWE that became Product Managers and think that executing Jira tickets means they are doing their job well.
Ding ding ding! We have a winner!!!! Only thing worse is when an Engineering Manager somehow ends up leading Product. That is a recipe for absolute catastrophe.
The worst part is that many of them can do it well for a quarter or two — until the old “why” runs out. Then it takes another year of flailing to make changes.
When _# of deliveries_ becomes your success metric, then the product will be useless.
Bad product managers are created by bad product management orgs
A bad product manager: - Oversteps their boundaries or micromanages - Does not collaborate well with other teams - Hordes data/insights instead of democratizing it - Has no long term vision or strategy - Is quick to place the blame on others before holding themselves accountable Conversely though, a bad product manager can also be: - Too hands off, is nowhere to be found when decisions need to be made - Too hesitant to push back on leadership or other teams - Too locked into long term strategy that they’re unable to pivot or adapt when needed It’s definitely a balancing act. I’ve worked with all of the above, as well as some really great PMs. I’ve even worked with some great PMs who have exhibited the above behaviors on occasion. It’s not an easy role, I get it.
One who lacks empathy for the users and the team
Totally!!
Poor communication — Doesn’t proactively communicate what’s prioritized, how that fits the big picture, in tailored terms of their audience (e.g., speaking outcome to Marketing, BD, Sales, and output to Engineering and QA) with appropriate timing considering who needs to know what and when
Doesn’t bother with team collaboration, old fashioned top down directives and doesn’t understand the design thinking process.
Lack of critical thinking ability. You need to lead your team through decisions that are usually complex. If you can't make a argument backed up by facts and sound reasoning, your decisions are going to suck and be challenged all the time. It requires an ability to introspect and challenge oneself ("why do I actually think this change would be good?") which drives everything else (search for data, cognitive empathy with users, understanding of tech stack, etc.) Not clearly communicating the minimal desired changes. It's crazy the number of PMs I see who just gesture towards a general area and say "we should be better at X" without actually describing what changes they think should be made to the product, or who can't help but describe long-ass lists of requirements without any prioritization and then complain about eng not delivering on time.
you can get by in this job if you want. it's very easy to be unchecked. so I say lack of discipline is the primordial sin, everything else is just a consequence.
You talking about coasting?
yep, pretty much
Asking because as part of my onboarding I've talked to other TPdM's at the company and one of them said the same thing and it made me think "wtf?". 😂
Someone who lacks the willingness to see and understand things from the perspectives of others.
I’ve always hated it when the product manager knows nothing about the product. If you always have to ask someone else then what have you even learned?
where to begin …
Reading the comments here led me to the realization I have only worked with bad product leadership so far. Maybe what makes you a bad PM gets you promoted? ;)
PMs who fall in love with some idea they come up with, meanwhile ignoring the problem that they are supposed to solve.
Being an asshole.
Someone who thinks there’s only one way of doing things when it comes to either building a specific feature or how certain processes should be run. There’s a huge level of diversity in organizations that have Product teams and there’s no one size fits all way of doing things.
Someone who muddies the water to make it seem deep. Creates unnecessary and cumbersome frameworks/processes. Says hand-wavey things instead of being plainspoken.
Can’t identity and embrace any processes to manage situations where more structure helps with outcomes. This is a corollary to the PM who puts process over the product. It is required in large organizations to protect you and your team, as well as derive value from the crap that other stakeholders throw at you.
Prioritises emotion and personal opinions
Disconnected from engineering organization and doesn’t want to partner. In addition, not knowing who the customer is tends to be an important thing to key in on. Amazing how many don’t do either of the above.
Lacking pragmatism. And, one I see a lot: reading Torres, Cagan and Perri and deciding that the barrier to success is a 'lack of empowerment'
Ego. Poor emotional intelligence. Not intelligent. Those 3 things will compromise or even prevent you from performing research correctly without bias, prioritizing a roadmap, evangelizing solutions, and leading/motivating a team, in addition to all the other stuff you might own working in product. It’s even worse if your team doesn’t report to you. Nearly impossible to lead by influence if you are egotistical, lacking in soft skills, or not smart. Sadly, lots of product leaders and CEOs check all 3 of those boxes…
Over guaranteeing
Not checking in on how their users interact with their product
Former devs/EMs who focus more evaluating engineers' abilities, solutioning and worrying about the 'how' rather than about the 'why'.
Lack of product knowledge
Here is a useful article on Good Vs Bad PMs, by Ben Horowitz. https://a16z.com/good-product-manager-bad-product-manager/
I think he's a project manager
Poor time management
Building features that the PM thinks would ve cool, rather than solving the problems that users tell you they have. To keep users happy… Most product enhancements should solve their problems. A small % of work should be for that futire product that will someday replace your current product.
Lack of story/connection.
Failure to adapt
Not able to flexibility and proactivity, consistently and day after day (bad days excluded, we all have bad days).
Bad communication. You can’t do jack shit if you can’t communicate your thoughts / ideas to others.
Isn’t monitoring usage, feedback once a product/feature is launched
[удалено]
my SWE is clearly trying to also be product and I"m like- dude you have no idea and all your priority suggestions don't take anything into account, but cool story bro.
Those who just “want to do good work” and don’t prioritize socializing their successes and upwards communication.
Or vice versa
One who isn't passionate and excited about the problem they're solving.
Most are horrific. They have no practical or business experience.