29 ms·

The 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.

The 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 launch, watch for snags, provide support and solutions to users. 2. Communicate gathered feedback to engineering, and do so with an understanding of where the project is engineering-wise, where it is going, what needs to change. Give engineering the "why. Convey the priority of everything the project needs vs what it has and what is being worked on. Repeat this feedback loop. But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead.

deleted 3y ago
[deleted]
jack_riminton 3y ago
Having been a PM (now developer) the problem I faced was half the time I was having to provide documentation, communications and evidence for my managers. Which is of course fine but when you have HIPPO syndrome (HIghest Paid Person in the Office) who likes to make product decisions then you have to spend most of your time covering your back and managing up PMs get a lot of stick, sometimes justified, but they're just having to play office politics in order to get stuff done
- bhpm 3y ago
  Yep. And then you leave and the engineers start complaining they have to play office politics to get things done. :)
- hilux 3y ago
  PM->Dev is not the typical trajectory, although it's one I'm considering. How do you feel about the transition?
martin_drapeau 3y ago
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.
- possibly_not 3y ago
  Just so I understand, the best way to hire a product manager in B2B is to poach the employees of your customers?
  - throwawaysugar 3y ago
    A more charitable interpretation is poaching ONE such employee out of all your customers. It's not a criminal act, IMHO. Managers of any company that think they can't afford to lose a single employee are doing something wrong and should google "key man risk"
- steveBK123 3y ago
  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.
  - Kinrany 3y ago
    Doesn't it go in the other direction too? Any PM you can hire can probably make more in finance?
    - steveBK123 3y ago
      Well yes but that's why I think "we'll just hire a typical user as a PM" isn't really a solution. It also doesn't give them any training in how to PM. They should just be someone technical enough with enough people skills and familiarity with user use cases to bridge the gap.
blehn 3y ago
My experience (FAANG) has been the opposite. PMs want to dream up features and put together a roadmap and then they think their work is done. A great PM is both creating a vision or plan and guiding the execution and iteration. The plan is the 20%.
kylecazar 3y ago
I'm a PM (I now exclusively look for the 'technical' qualifier before any role I consider) -- I could not agree more with what you wrote. The last paragraph particularly. Lately, I've been responsible for mentoring other PM's. Sure there's the widely shared roadmap, but also -- I can't tell you how many documents and sheets are created that are literally never seen again by anyone other than me, and I get the feeling were created to demonstrate that they are working. It's a habit I try to break. The reason I advocate for technical product management so strongly is I've (over)simplified the problem in my head to be that some PM's are stuck at that high level of abstraction because they're unable to communicate with their teams on the detailed technical matters on a daily basis. So they end up in a weird grey area of project/product management.
- intrasight 3y ago
  > documents and sheets are created That sounds terrible and predictable. Data managed by a PM should be managed and presented in the same product dashboard used by everyone else.
  - starkparker 3y ago
    When they can't use git and find project tracking software too complex to understand, this is what regularly happens. Either this or charts and tables in Miro/Figma boards.
    - ethanbond 3y ago
      This is too cynical IMO. Documents are actually the correct tool for some kinds of thought and communication. Issues are different, Miro/Figma boards are different.
      - starkparker 3y ago
        > Issues are different, Miro/Figma boards are different. In practice over the last year, I've seen product managers make Gantt charts in Miro as the source of truth for a project and run backend engineering retros in Figma. These were done redundantly with our issue tracking system; my cross-functional team had to create issues in our tracker based on the Miro and Figma boards to actually manage our own work, then duplicate the updates on those boards to communicate them up to product.
DanielHB 3y ago
> But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead. They are not managing product, they are managing stakeholders
- smcin 3y ago
  Mainly internal stakeholders, I take it. Isn't all that entirely big-company politics? Whereas a PM in a small company can devote more attention to the product, customers, market, metrics. What's a good question to ask to find out which sort of animal you're dealing with?
lp4vn 3y ago
>But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead. Ok, maybe I came to the wrong place to say what I'm gonna say because I guess that a sizable part of the demographics here works in hot, meaningful projects, but as a corp worker for the last 8+ years, it has been my experience that a lot of companies have products that are used either internally by their own employees or by another corporate client that still pays for them out of inertia or because there is just too much custom business logic that now it's too costly to replace them. In both of these cases we're talking about uncompetitive products that are probably going to remain so before being discontinued. And in both of these cases companies will try nonetheless to create a SCRUM-like arrangement with PMs and POs and behave like they are building a revolutionary product, urgent taks and pressure for results included. It has also been my experience that in this kind of environment normally PMs and POs will be fully invested in doing politics to try to climb up the corporate ladder without much concern about what makes a good or usable product. They will steer the project in whatever direction makes them look good to the administration or the client at the cost of creating a fragmented product that many times looks like it's doing a random walk in terms of functionality and improvements. I'm not old enough to know how things were built in the 60's/70's/80's(no SCRUM/PM's/PO's I guess) but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception.
- dan_mctree 3y ago
  >but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception. Mine too. Any ideas why productivity has slowed down so much? Is this a software online observation, or more of a wider pattern With software I guess part of the problem is that there's a lot of diminishing returns, with it being much easier to just crank out some initial prototype that does a lot, then it is to adjust some spaghetti mess that users deeply rely on. But that should only really affect individual projects, not necessarily the industry as a whole
deleted 3y ago
[deleted]
steveBK123 3y ago
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.
- ath3nd 3y ago
  > 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. Beautifully put!
  - ryandrake 3y ago
    This was the way in almost every place I've worked. If you did a good job at managing upward and schmoozing and stroking the senior management's ego, and had those smooth "ivy leaguer" mannerisms, then it didn't even matter if you did your job. You were the Golden Boy and destined for greatness. But if you were too busy actually doing your job and didn't properly pet your management chain, you were setting yourself up to be the scapegoat.
    - aperson_hello 3y ago
      This is exactly the problem. If you do your job as a PM, you get pushed out because doing your job means you'll be ruffling feathers in senior management. So to stick around, you schmooze instead of doing your job because doing your job properly invariably pisses off management at some point
boredtofears 3y ago
I've always found PM's that come from a UX/Design background to be more willing to engage with the actual people we are building software for. IME, it's always been BA/MBA types that want to draw up documentation and then chuck it over a wall (development) and call it a day.
JyB 3y ago
That's why the best PMs have some kind of engineering background or are former eng. As small as it may be it is a requirement nowadays.
mushbino 3y ago
I've worked with dozens and dozens of PMs over the years and almost zero of them do this. Most of this is always done by product designers.
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

jack_riminton 3y ago

Having been a PM (now developer) the problem I faced was half the time I was having to provide documentation, communications and evidence for my managers. Which is of course fine but when you have HIPPO syndrome (HIghest Paid Person in the Office) who likes to make product decisions then you have to spend most of your time covering your back and managing up PMs get a lot of stick, sometimes justified, but they're just having to play office politics in order to get stuff done

bhpm 3y ago
Yep. And then you leave and the engineers start complaining they have to play office politics to get things done. :)
hilux 3y ago
PM->Dev is not the typical trajectory, although it's one I'm considering. How do you feel about the transition?

martin_drapeau 3y ago

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.

possibly_not 3y ago
Just so I understand, the best way to hire a product manager in B2B is to poach the employees of your customers?
- throwawaysugar 3y ago
  A more charitable interpretation is poaching ONE such employee out of all your customers. It's not a criminal act, IMHO. Managers of any company that think they can't afford to lose a single employee are doing something wrong and should google "key man risk"
steveBK123 3y ago
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.
- Kinrany 3y ago
  Doesn't it go in the other direction too? Any PM you can hire can probably make more in finance?
  - steveBK123 3y ago
    Well yes but that's why I think "we'll just hire a typical user as a PM" isn't really a solution. It also doesn't give them any training in how to PM. They should just be someone technical enough with enough people skills and familiarity with user use cases to bridge the gap.

blehn 3y ago

My experience (FAANG) has been the opposite. PMs want to dream up features and put together a roadmap and then they think their work is done. A great PM is both creating a vision or plan and guiding the execution and iteration. The plan is the 20%.

kylecazar 3y ago

I'm a PM (I now exclusively look for the 'technical' qualifier before any role I consider) -- I could not agree more with what you wrote. The last paragraph particularly. Lately, I've been responsible for mentoring other PM's. Sure there's the widely shared roadmap, but also -- I can't tell you how many documents and sheets are created that are literally never seen again by anyone other than me, and I get the feeling were created to demonstrate that they are working. It's a habit I try to break. The reason I advocate for technical product management so strongly is I've (over)simplified the problem in my head to be that some PM's are stuck at that high level of abstraction because they're unable to communicate with their teams on the detailed technical matters on a daily basis. So they end up in a weird grey area of project/product management.

intrasight 3y ago
> documents and sheets are created That sounds terrible and predictable. Data managed by a PM should be managed and presented in the same product dashboard used by everyone else.
- starkparker 3y ago
  When they can't use git and find project tracking software too complex to understand, this is what regularly happens. Either this or charts and tables in Miro/Figma boards.
  - ethanbond 3y ago
    This is too cynical IMO. Documents are actually the correct tool for some kinds of thought and communication. Issues are different, Miro/Figma boards are different.
    - starkparker 3y ago
      > Issues are different, Miro/Figma boards are different. In practice over the last year, I've seen product managers make Gantt charts in Miro as the source of truth for a project and run backend engineering retros in Figma. These were done redundantly with our issue tracking system; my cross-functional team had to create issues in our tracker based on the Miro and Figma boards to actually manage our own work, then duplicate the updates on those boards to communicate them up to product.

DanielHB 3y ago

smcin 3y ago
Mainly internal stakeholders, I take it. Isn't all that entirely big-company politics? Whereas a PM in a small company can devote more attention to the product, customers, market, metrics. What's a good question to ask to find out which sort of animal you're dealing with?

lp4vn 3y ago

>But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead. Ok, maybe I came to the wrong place to say what I'm gonna say because I guess that a sizable part of the demographics here works in hot, meaningful projects, but as a corp worker for the last 8+ years, it has been my experience that a lot of companies have products that are used either internally by their own employees or by another corporate client that still pays for them out of inertia or because there is just too much custom business logic that now it's too costly to replace them. In both of these cases we're talking about uncompetitive products that are probably going to remain so before being discontinued. And in both of these cases companies will try nonetheless to create a SCRUM-like arrangement with PMs and POs and behave like they are building a revolutionary product, urgent taks and pressure for results included. It has also been my experience that in this kind of environment normally PMs and POs will be fully invested in doing politics to try to climb up the corporate ladder without much concern about what makes a good or usable product. They will steer the project in whatever direction makes them look good to the administration or the client at the cost of creating a fragmented product that many times looks like it's doing a random walk in terms of functionality and improvements. I'm not old enough to know how things were built in the 60's/70's/80's(no SCRUM/PM's/PO's I guess) but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception.

dan_mctree 3y ago
>but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception. Mine too. Any ideas why productivity has slowed down so much? Is this a software online observation, or more of a wider pattern With software I guess part of the problem is that there's a lot of diminishing returns, with it being much easier to just crank out some initial prototype that does a lot, then it is to adjust some spaghetti mess that users deeply rely on. But that should only really affect individual projects, not necessarily the industry as a whole

deleted 3y ago

[deleted]

steveBK123 3y ago

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.

ath3nd 3y ago
> 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. Beautifully put!
- ryandrake 3y ago
  This was the way in almost every place I've worked. If you did a good job at managing upward and schmoozing and stroking the senior management's ego, and had those smooth "ivy leaguer" mannerisms, then it didn't even matter if you did your job. You were the Golden Boy and destined for greatness. But if you were too busy actually doing your job and didn't properly pet your management chain, you were setting yourself up to be the scapegoat.
  - aperson_hello 3y ago
    This is exactly the problem. If you do your job as a PM, you get pushed out because doing your job means you'll be ruffling feathers in senior management. So to stick around, you schmooze instead of doing your job because doing your job properly invariably pisses off management at some point

boredtofears 3y ago

I've always found PM's that come from a UX/Design background to be more willing to engage with the actual people we are building software for. IME, it's always been BA/MBA types that want to draw up documentation and then chuck it over a wall (development) and call it a day.

JyB 3y ago

That's why the best PMs have some kind of engineering background or are former eng. As small as it may be it is a requirement nowadays.

mushbino 3y ago

I've worked with dozens and dozens of PMs over the years and almost zero of them do this. Most of this is always done by product designers.

deleted 3y ago

[deleted]