I am a software engineer, most of the time, PMs are just make my work harder.
More product, fewer product managers
161–170 of 314 posts
Re: More product, fewer product managers
#162Earlier quoted context omitted.
We are not talking about a good manager here. We are talking about the one who can program manage to the level of lowest jira issues.
That’s not product management. That’s an under-qualified person misunderstanding their role. Product management is mostly a people job, understanding internal stakeholders, understanding customer, understanding the market, understanding the solution options, formulating and understanding strategy for the product, coordinating product marketing and documentation for the product. If someone can do all that well, there’…
Even if they have the time, my rule is that nobody who does not understand the complexity of the solution (not the problem or the what) should be allowed anything more than watch rights in jira and standups. I would love to hear one non coding product manager who does not run jira in their org of more than 100 people.
The problem is that it is hard to be a product manger and own those tough customer metrics. It is easy to do jira and get credited for engineering work.
Re: More product, fewer product managers
#163Earlier quoted context omitted.
> As a developer, and a development manager, the best product managers I've worked with rarely got involved in the "how". My experience is completely the opposite. PMs that don't understand the how, that is, they don't know how their product works, are the worst. Best PMs that I worked with had a technical background.
I believe OP meant « implementation » with « how ». You want a PM that knows the product (really) well and brings new work to the developers in the form of well documented problems, not solutions. You don’t want your PM to get involved in the technical details.
Careful here!
> not solutions
Often yes, solutions. When you're still in the "what are we building" phase you want a good PM deeply involved in the process. I think you may have implied that, but solution creation happens before code gets written.
You also sometimes want a PM to get involved in technical tradeoffs when they impact the user experience. I've found that this happens more often with a technical product (API capability or SDK interface) than a UI screen, but it comes up. When your PM is the expert in your userbase and how they expect to use something, they need to be involved a lot.
Re: More product, fewer product managers
#164The problem with most PMs is that they are not doing boots-on-the-ground work. A good PM should be constantly bridging the gap between engineering and the user. 1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launc…
[deleted]
Re: More product, fewer product managers
#165Not related to number of PMs, but rather the type that I prefer to work with:
I’ve worked at 4 different companies in the industry, ranging from I reject the idea that “technical” folks are smarter than “non-technical” folks - in fact, as an engineer I often get caught in the weeds and lose sight of the big picture, and need a PM to help pull me out.
However, in my experience, the easiest PMs to work with as an engineer are ones who have at least __some__ actual exposure to code. Nothing fancy, it could have been building a website with HTML and CSS many years ago, writing some ad hoc SQL queries, or taking a Python class while doing a Master’s degree. __something__ that helps a PM understand that writing code is neither an exact science nor outright wizardry.
These PMs tend to advocate for the engineers they work with, or at least try to strike a balance between business demands and engineering realities. Those who get into PM with zero technical exposure tend to be more “business-oriented”, which may be exactly what a business needs at a given time, but not all the time, and as an engineer I would rather work with someone who has a better understanding of my perspective as well.
Re: More product, fewer product managers
#166Earlier quoted context omitted.
Every time I’ve worked on financial aid, HR, or financials, the PM has been an expert in those areas. I couldn’t do my job otherwise (or, I have to fill their shoes).
I work in the medical field which is fairly heavily regulated as well. My teams have been able to do our job without having a dedicated medical compliance expert as their PM. We just have a medical compliance team and ask them for input, but they most certainly don't tell us what to build nor drive the product direction. In short, I question the need of a PM, not the need for domain experts (law,financials,etc).
If you've had good results without a PM you probably had someone who was doing that work, but under a different job title. Or the results weren't as good as you thought.
Good PMs are often engineers or ex-engineers themselves. But a good PM will do a much better job than just sticking a bunch of engineers in a room and asking them to manage the product. A lot of developers really hate tasks like:
- Designing UIs
- Thinking through complex workflows to simplify them (unless they're developer workflows)
- Writing documentation
- Often also, identifying and fixing small quality issues like bad error messages
- Figuring out what the customer's actually need vs what they say they need
Some devs are naturally talented and capable of doing all the above, plus banging out the code too. That's great, maybe they don't need a PM or more likely maybe they will become one themselves in future. But left to their own devices a lot of dev teams will rapidly lose the plot and start producing features nobody cares about, or doing endless refactorings, or produce something that's too hard to use.
Re: More product, fewer product managers
#167The problem with most PMs is that they are not doing boots-on-the-ground work. A good PM should be constantly bridging the gap between engineering and the user. 1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launc…
My team was product managed by a gutless PM who essentially made senior devs & tech leads do all the legwork.
Requirements gathering, mean user upset about a bug, weekly status call, need to break some bad news re: priorities? - send a senior dev or tech lead. Skipped most of the agile ceremonies too, busy guy. Never wrote or edited a JIRA ticket, that was for tech org to manage. He PMd 2 other tech teams the same way.
Tech leads/senior devs knew our PM was bad news from his first week but he outlived all of us until finally getting hit with a RIF after 4 years.
Management worshipping at the throne of agile become really enthralled with these guys and can derail an org for years. In theory a PMs stakeholders are the users, but in practice it is buffing the egos of the senior management that hired them. Can become a self reinforcing closed loop between senior management / agile consultants / PMs.
Re: More product, fewer product managers
#168I’ve worked with a number of Fortune 500 companies and seen many examples of a disfuncional culture. I’ve seen in those places that PMs solve most problems with the one tool at their disposal: meetings. Incentives for promotions are such that the bigger your meeting the more important you are. I’ve been in hi dress of hours of cross functions team meeting where 1-2 people did any work, and usually the PM talked the whole time, while 10-20ppl are on mute and only sign off at the end to show they indeed exist. The end result see teams of dejected engineers that don’t have time for actual technical work, and are asked to give estimates or commitments on the spot without any research or even understanding of the code. I’ve seen PMs reject technical designs because they didn’t like the number or “points”, and engineers just had to reformat the same ideas into different “tickets” to satisfy some inscrutable PM aesthetics. Entire projects delayed and derailed because of lack of understanding and pointless status signaling rituals. On the other hand I’ve worked with brilliant PM who protected the team from such nonsense and helped them stay focused on the right goal. These people are invaluable as much as the others are detrimental.
Re: More product, fewer product managers
#169The problem with most PMs is that they are not doing boots-on-the-ground work. A good PM should be constantly bridging the gap between engineering and the user. 1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launc…
A great way to solve for this in B2B, is to hire a customer and train them as PM. They will hit the ground running much faster to bridge the gap.
My org tried this, but being in financial services no one thought through this problem - our customers are much better paid than any PM we could hire.
That is to say, the only customer we could convert to a PM was one who was fundamentally bad enough at his existing client side job that he was OK capping his income at 25-50% of his potential.
Re: More product, fewer product managers
#170The best product manager I worked with was just an exceptionally bright person, they were able to understand complexity of implementation (and even have a reasonable chance of doing it themselves) vs understanding the business need. Just basically a value add to the company without being an engineering manager. Unfortunately most product managers are just people who sit in the role. They are just gatekeepers who take…
> Overall, if you have a product management organisation, you're doing it wrong.
Agreed, the best (and most successful) products I've worked on have all had product ownership by actual implementers (engineers, designers, customer success, etc). I loved being on the support rotation as an engineer because it closed the gap of abstraction between my work and the real humans who were using it every second.
Very rarely, I have worked with PMs who add net positive value, and in every case they would have made okay engineers as well.