4 ms·

> What skills must be demonstrable? Have the balls to stand up to management. You are often under significant pressure to adjust timelines and somehow get "9 w

> What skills must be demonstrable? Have the balls to stand up to management. You are often under significant pressure to adjust timelines and somehow get "9 women to have a baby in a month." The PM I have now is excellent and is happy to say things to management like: "Assuming everything goes well, we estimate you will have your project on dd-mm-yy. Remember that's an ESTIMATE." "I don't think it's a good idea to try and force our devs to work overtime/weekends. We're more likely to stress our workforce and possibly lose devs eventually if we do that." "No I'm not changing my estimate." "No really, I'm not changing my estimate." You get the idea. Thing is, after a number of projects he actually has the respect of management because they know he will give them the real numbers no matter what the pressure.

ernestbro 10y ago
That's project management- not product management
- philbarr 10y ago
  Oops, sorry!
- zzalpha 10y ago
  Eh, that line is fuzzier than it looks from a distance. Product managers are responsible for dealing with roadmaps and timelines. Managing expectations is necessarily part of that job. Add in agile practices where the PM may also be a PO directly managing a backlog and the line gets fuzzier still. It's part of what makes that job so challenging, as you have to wear so many hats. It also makes the job very difficult to define, and I think, makes the question itself a little tough, since a PM in one org might be a very different role from a PM in another.
  - gcb0 10y ago
    all fortune 500 companies I worked on that had only PM doing both jobs it went like: PM promises some project worked out with a designer that only knows the how to wireframe generic screens, both lack understanding of the product and tech. usually because the PM just moved from another place 3 months ago. PM show up every day at standup and fail to understand the current priorities, push the new project, the enginners see how pointless but easier than real priorities it is. Then remember it is a fortune 500 company so the easier the better. Everyone works on the useless project, try to explain the product to the PM but he will have none of that, after all the wireframes are done! Agile is actually used as an excuse "don't worry, we will iterate later". The PM will now disappear until close to the deadline when you will get constant meeting invites to assess progress, which will never be the standup. Project goes live shoved into actual product and it is a complete failure but everyone mentions it on their accomplishments so management starts to see it as a success. Everyone involved gets a promotion. PM moves over to help troubled team. Some engineers stay and are tasked with maintenance. A year later execs see the numbers and blame the current team, labels them as a troubled team so they get a new PM (remember they had none because the other one left to help another team labeled troubled). And that's the circle of life in a fortune 500.
    - zzalpha 10y ago
      Well, on the bright side, all you aspiring PMs out there, take note: see how low the bar is?? Speaking as a PM/PO that, I hope, doesn't suck, if you simply take the time to: 1. Understand the market. 2. Understand the product. 3. Understand the user. 4. Actively engage with and converse with developers and negotiate requirements rather than acting as a lofty dictator, and listen when the engineers raise concerns. 5. Be engaged in the process so the product can truly evolve as market and technical requirements are uncovered. 6. Own failures. 7. Share successes. I'm sure I've left lots off the list, but it's pretty basic stuff (which, I suppose, all starts from the same basic place: humility)...

ernestbro 10y ago

That's project management- not product management

philbarr 10y ago
Oops, sorry!
zzalpha 10y ago
Eh, that line is fuzzier than it looks from a distance. Product managers are responsible for dealing with roadmaps and timelines. Managing expectations is necessarily part of that job. Add in agile practices where the PM may also be a PO directly managing a backlog and the line gets fuzzier still. It's part of what makes that job so challenging, as you have to wear so many hats. It also makes the job very difficult to define, and I think, makes the question itself a little tough, since a PM in one org might be a very different role from a PM in another.
- gcb0 10y ago
  all fortune 500 companies I worked on that had only PM doing both jobs it went like: PM promises some project worked out with a designer that only knows the how to wireframe generic screens, both lack understanding of the product and tech. usually because the PM just moved from another place 3 months ago. PM show up every day at standup and fail to understand the current priorities, push the new project, the enginners see how pointless but easier than real priorities it is. Then remember it is a fortune 500 company so the easier the better. Everyone works on the useless project, try to explain the product to the PM but he will have none of that, after all the wireframes are done! Agile is actually used as an excuse "don't worry, we will iterate later". The PM will now disappear until close to the deadline when you will get constant meeting invites to assess progress, which will never be the standup. Project goes live shoved into actual product and it is a complete failure but everyone mentions it on their accomplishments so management starts to see it as a success. Everyone involved gets a promotion. PM moves over to help troubled team. Some engineers stay and are tasked with maintenance. A year later execs see the numbers and blame the current team, labels them as a troubled team so they get a new PM (remember they had none because the other one left to help another team labeled troubled). And that's the circle of life in a fortune 500.
  - zzalpha 10y ago
    Well, on the bright side, all you aspiring PMs out there, take note: see how low the bar is?? Speaking as a PM/PO that, I hope, doesn't suck, if you simply take the time to: 1. Understand the market. 2. Understand the product. 3. Understand the user. 4. Actively engage with and converse with developers and negotiate requirements rather than acting as a lofty dictator, and listen when the engineers raise concerns. 5. Be engaged in the process so the product can truly evolve as market and technical requirements are uncovered. 6. Own failures. 7. Share successes. I'm sure I've left lots off the list, but it's pretty basic stuff (which, I suppose, all starts from the same basic place: humility)...