Hacker News new | past | comments | ask | show | jobs | submit login

A number of these PM tasks go deeply into the development world: defining development processes, architecture, and managing developer checklists.

I've worked with a number of product managers who've grossly overestimated their competence in these areas, and who've been mocked and ignored as much as possible by the development team as a result. I'm familiar with a large, well known software company that uses such a job description. I worked with a product manager who left that company for mine. He was awful. He never gave customer-focused requirements. Instead he'd define implementations as if he knew what he was talking about, and I'd have to play 20 questions to figure out what problems he was trying to solve.

The best product managers I've worked with have leveraged their strengths and trusted others on their team to do what they're best at. In my experience, these product managers have always had a very strong customer/user focus. My favorite product manager was at a medical imaging company. He had been a tech before he moved into product management, so he knew deeply what our users needed from our product, he had many connections in the user community, and he knew how to listen. We'd challenge and ask questions, but at the end of the day we deferred to him in his area of expertise, just as he challenged and asked questions but deferred to us in our area of expertise.




This is a good point and something I should have made clearer. As PM, you ar first and foremost the customer advocate. Drop the ball here and you fail.

Engaging at a more technical level needs to be about ensuring focus, not meddling where you don't understand. For example, cootdinating architectural decisions does not mean designing the solutions (your senior devs do that) but it does mean infusing those discussions with customer centric decision making. The worst thing a PM can do is act like they know something without actually doing so--as others have noted, you need to listen and learn.

My experience may be a bit different; when I started, my boss was checked-out and looking for a career change. To learn the role, I got to know our developers really well (in the end, they have lots of power) and asked them what the PMs did well and didn't do well.


Well put. I'm currently in a situation where my PM has started to believe he knows more than he does (thanks to the assistance of me and the developers in the office).

Then PM made the mistake of talking within earshot about how he was going to decide the timeline and budget for my team without talking to me. My attitude toward the guy instantly went from "whatever it takes" to "do your own homework next time, buddy".

This is a small startup. We need every win possible to succeed. And I just don't give two shits about the guy anymore. Am I wrong to think this way?


The bozo bit is starting to flip... Give the PM the benefit of doubt; I'd be direct with him about why you don't think his actions are right--tell him what you expect from him and why the way he's behaving isn't constructive. If he doesn't listen, do your job, watch your back, and communicate to your boss how this guy isn't healthy for your team.


Yeah, I'm trying, but unfortunately politics are getting in the way...the PM and CEO are best friends from way back at previous companies. PM was laid off from his last job and sometimes I wonder if he got the job only because he needed one. It's tricker than it looks.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: