Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I hope you have better experiences with product orgs in the future, because based on what you're saying, you have worked with some really bad ones.

Requirements gathering is the main job of the PM, and it's most definitely not technical (or at least not remotely to the level of technical knowledge required to actually write code).

For example, a PM at Twitter defined that Tweets should be 140 characters (at least in the olden days). That's a fundamental requirement of the platform, but it's related to the company's objectives, user engagement and other things that have nothing to do with writing the code. There's zero reason that engineers should have anything to do with that. Once it's been decided that Tweets are 140 characters max, then that requirement gets handed off to the engineers to actually do the development.

Obviously all oversimplified, but the point is that if you think requirements are technical, then you're probably dealing with bad PMs who aren't drawing them up particularly well. The irony is that when this comes up, it's usually because the PMs used to be engineers and don't have the experience to separate the two roles.



Wow. You probably have high dev turn over rate or extremely complacent ones. Mistake many pms and execs make is assume dev is only worth they’re coding skills. We are humans who also have a non technical creative side. But the assumption is someone has already done all the high level thinking so we don’t have to.


It's not about assuming that devs are only worth their coding skills, it's about recognizing that their coding skills are what they're hired for (and also what they're extremely highly paid for).

It's fine that you have a non-technical creative side, but it's frankly not what you're paid for. That's true of everyone in the organization - I'm really enjoy writing and am very good at it, but I don't believe I'm being mistreated or underutilized because I'm not asked to do copywriting. That's the purview of marketing, not product.

This is even true within engineering - if you have experience working on both iOS and Android apps, but you interview for and are hired for a role on the company's iOS app team, nobody is undervaluing you because they don't also ask you to work on their Android app.

Businesses benefit from specialization and focus of their employees. Product exists to gather requirements and define specs not because dev can't, but because that's not what developers are hired to do.


Alright, keep cooking up the ideas in an ivory tower and us lowely well paid devs will just code it up. Because that is how outsourcing works. Really, may as well outsource your in-house devs.


This view is a really poor understanding of what engineering is about. If what you are saying is true then we wouldn't be sitting here trying to encourage engineers to learn every layer of the stack. Each of those layers is significantly different and quickly falls out of the domain of a Software Engineer.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: