Hacker News Reader

Comment by kylecazar | Hacker News Reader

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.

View on HN

That’s what happens when you hire a full time person to do what should amount to 8 hours a week. They go looking for ways to show value, and often that just causes everyone else to have more work too.

Usually it’s places where the projects are plenty small enough for the normal manager to handle it but they’re lazy and want the TPM/PM to be their secretary.

> they're unable to communicate with their teams on the detailed technical matters on a daily basis

Yeah, I've had PMs who've ground backlog grooming sessions to a halt so engineers can explain in detail what each one is, or shared incorrect information about a bug fix or new feature to a technical writer for release notes because they were so confidently incorrect.

The PMs with enough aptitude to understand and explain what the engineers are doing, even if they're not actively participating in implementation because they're applying that knowledge to broader strategic/roadmap decisions and cross-team coordination, are the best to work with.

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

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.

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.

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

Reply on news.ycombinator.com