5 ms·

As a developer, and a development manager, the best product managers I've worked with rarely got involved in the "how". Sure, they may generate epic-level tick

• antupis 3y ago
  Or they are super into weeds polishing stuff in code level but it is never between those two approaches. Also very good pm can be kinda shackled if there is lots of mediocre pms running around.
• anon23432343 3y ago
  On the other side I have worked with PM/POs who have no clue and the developers are just telling them: "Oh this is super complicated you would not understand" or "This will take a long time to implement" and its a small feature. There must be a balance. There must be some basic understanding by the PM/POs. They cant be the person that barley can use a computer.
  • Wurdan 3y ago
    It also helps to be able to understand the tech enough to know if a certain approach is going to impact other initiatives which are further down the roadmap. One of my favourite questions I've been asked by a PM is "Will any of this work become easier to do if we change the order of these work items?"
    • radiator 3y ago
      I would have thought every manager asks such questions either to himself or to the team quite often.
      • Wurdan 3y ago
        Not in my experience - juggling priorities is usually difficult enough when you're just trying to manage the C-suite's favourite ideas, or feature requests from the highest revenue customer, etc. Factoring in synergistic engineering efforts is out of reach for a lot of PMs that I've worked with.
• gabrieledarrigo 3y ago
  > 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.
  • nip 3y ago
    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.
    • phillipcarter 3y ago
      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.
      • nip 3y ago
        Agree on all counts!
  • aurareturn 3y ago
    >Best PMs that I worked with had a technical background. Best PMs I worked with just figured out what users wanted and organized the team to build it through good communication. That's it. Sometimes the technical PMs can be an issue because they care too much about the how and not enough of the why and what. If your product is selling devtools to developers, then yes, it helps to have a technical PM. Case by case.
• PaulRobinson 3y ago
  Product managers own the "Why?" and the "What?". Project managers own the "When?". Engineering managers own the "Who?". Engineers own the "How?". When people try treading on other patches, it always ends in disaster. That works both ways: engineers are lousy at the "Why?" and the "What?" because they think too much in terms of "How?"; and yes, product managers need to step away from the "How?" unless it's to clarify the "What?" or the "Why?".
  • hehhehaha 3y ago
    Hard disagree, cross role context is critical for intuition on getting stuff done. A designer with no insight on engineering will create shitty designs that take forever to build, create patterns that arent reusable, etc. Engineers with no insight on product will not be able to balance the debt/product ratio properly. You can say that all of this gets sorted out with proper communication, but knowledge and intuition will always beat leaky bucket cross role comms
    • PaulRobinson 3y ago
      "Having context" isn't the same as "having ownership or accountability". Of course there needs to be communication and context, but when engineers start to try and direct the "what" or the "why", it becomes as absurd as PMs trying to dictate the "how".
  • mewpmewp2 3y ago
    If this is the ownership and Engineers ask "How?", there's no one overall to connect the dots. For instance with this ownership dynamic product managers will come up with what and why, and engineers will come up with "how", but no one validates whether the whole thing is worth it considering the technical complexities involved. So scenarios where PMs come up with this and Engineers just ask "How?" there will be initiatives that take a lot of resources, while not giving enough in return. There's no one to balance the complexity of building this vs the gains achieved. I think best engineers would be people who also use the product and can give their own insights on this, as well as best PMs are someone who have good knowledge of the technical background and context.
• andromeduck 3y ago
  That only works when the people under them are competent and business interests are reasonably aligned with reward structure.