4 ms·

problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they ar

problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they are working with). this is a very horrendous situation to be in both as PM and as an engineer working with a PM. >5. Decisions, and what you prioritize, need evidence This. In my experience PMs' features are driven by not evidence but "lets try this stuff out" and "hypothesis" causing a ball of mud on the engineering side to ship stuff fast to impress the stakeholders. I don't generalise and I also have seen PMs to be brilliant - but is more an exception than the rule - some PMs I've worked with they had very strong analytical skills, engineering knowledge and domain knowledge + skin in the game - if a feature has turned out to be crap they have the guts to kill it

ozim 6y ago
I think biggest problem is: not killing enough features. It goes let's try that stuff or some customer "really really needs this" but then no one uses that feature for 2 years. If I would have some PM that looks into stats and kills not used stuff it would be better. Unfortunately mostly it looks that removing feature is negative value, firstly you already spend time/money building it, second removing is not free where leaving feature there seems like it is free. It is hard to explain that application maintenance costs more when we have bs features in code.
- falcor84 6y ago
  Removing a feature can be a really negative experience for the users. If literally no one uses it, then that's ok, but if even just 0.01% use it, then removing it can break their faith in the product. If instead you can spin the feature out into a plug-in/extension and possibly even open-source it, you'll do much better by your users.
lliamander 6y ago
> problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they are working with). this is a very horrendous situation to be in both as PM and as an engineer working with a PM. I don't think the PM needs to be particularly knowledgeable about technology so long as they sanity check their ideas with engineering first. The roadmap needs to be the result of a conversation. > >5. Decisions, and what you prioritize, need evidence This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc.
- secondcoming 6y ago
  > This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc. Ok, I take it you're not a developer then!
  - lliamander 6y ago
    Au contraire! I am a developer. As a developer, one of the biggest issues I've seen with product management is a constant shifting in product direction. Each time there are great power point slides defining a new product vision, but rarely ever is any justification for this new vision, nor do I often see evidence that the change increased revenue. By requiring evidence for a particular prioritization, not only does that increase my confidence that what I'm working on will actually matter, but it makes changing the prioritization harder, and hopefully means that it will happen less often, and that perhaps I can actually ship something before the PM changes the vision (again).
    - designium 6y ago
      I think if you are building something extremely technical such as products for devs, or Fintech stuff, you have to understand some APIs just to know enough that you know what you are able to deliver.
      - lliamander 6y ago
        Some level of technical competence is necessary, but not always as much as you might expect. For example, in designing an API, sequence diagrams and data payload definitions are things you can use to communicate the essential aspects of an API to less-technical PMs.
    - secondcoming 6y ago
      You're doing the Product Manager's job, in my opinion. They're the ones who have to justify to senior management why something is being done, and when. The devs really should just get on and do it once it's been agreed.

ozim 6y ago

I think biggest problem is: not killing enough features. It goes let's try that stuff or some customer "really really needs this" but then no one uses that feature for 2 years. If I would have some PM that looks into stats and kills not used stuff it would be better. Unfortunately mostly it looks that removing feature is negative value, firstly you already spend time/money building it, second removing is not free where leaving feature there seems like it is free. It is hard to explain that application maintenance costs more when we have bs features in code.

falcor84 6y ago
Removing a feature can be a really negative experience for the users. If literally no one uses it, then that's ok, but if even just 0.01% use it, then removing it can break their faith in the product. If instead you can spin the feature out into a plug-in/extension and possibly even open-source it, you'll do much better by your users.

lliamander 6y ago

> problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they are working with). this is a very horrendous situation to be in both as PM and as an engineer working with a PM. I don't think the PM needs to be particularly knowledgeable about technology so long as they sanity check their ideas with engineering first. The roadmap needs to be the result of a conversation. > >5. Decisions, and what you prioritize, need evidence This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc.

secondcoming 6y ago
> This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc. Ok, I take it you're not a developer then!
- lliamander 6y ago
  Au contraire! I am a developer. As a developer, one of the biggest issues I've seen with product management is a constant shifting in product direction. Each time there are great power point slides defining a new product vision, but rarely ever is any justification for this new vision, nor do I often see evidence that the change increased revenue. By requiring evidence for a particular prioritization, not only does that increase my confidence that what I'm working on will actually matter, but it makes changing the prioritization harder, and hopefully means that it will happen less often, and that perhaps I can actually ship something before the PM changes the vision (again).
  - designium 6y ago
    I think if you are building something extremely technical such as products for devs, or Fintech stuff, you have to understand some APIs just to know enough that you know what you are able to deliver.
    - lliamander 6y ago
      Some level of technical competence is necessary, but not always as much as you might expect. For example, in designing an API, sequence diagrams and data payload definitions are things you can use to communicate the essential aspects of an API to less-technical PMs.
  - secondcoming 6y ago
    You're doing the Product Manager's job, in my opinion. They're the ones who have to justify to senior management why something is being done, and when. The devs really should just get on and do it once it's been agreed.