Hacker News Reader

Hacker News

Comment by HatchedLake721 | Hacker News Reader

Parent Full thread

HatchedLake721

Of course there is.

If not for the PM, who will speak with the customers, gather, analyze and understand their needs and problems?

There should be a person that drives the product in the right direction based on customer conversations.

In the early stages founder is the product owner.

But as the company grows, the role of the founder/CEO changes. You now build the people, and people build the business.

Engineers or CEOs building features no one asked for is IMHO one of the major reasons lots of tech startups fail.

Awesome idea, cool product, but no one asked for that feature you were building for 2 months. (guilty here myself)

View on HN

> If not for the PM, who will speak with the customers, gather, analyze and understand their needs and problems?

The engineers? i.e. the people who will actually be fixing those problems?

> Engineers or CEOs building features no one asked for is IMHO one of the major reasons lots of tech startups fail.

So why put another layer (the PM) in between the engineers and the customers? Sounds like an unnecessary game of telephone to me.

Yes, I continually dislike why engineers are so discounted in terms of parsing customer problems... we build the damn things, we also happen to know how to use the mobile apps, web apps, and desktop apps we build. I'm likely heavily biased and bitter at this point, but I've yet to work with a good "product manager" - and I still don't know what a good one would look like or do.

Sounds like you should work for a company that has only engineers and no PMs or middle managers. Maybe someone on HN can suggest a good one?

The same reason when every year a new iPad comes out, you have a thread on Hacker News with engineers complaining they can’t run Kubernetes cluster on it even though it has the technical capability to do it.

Engineers don’t understand iPad’s product positioning, that it’s not built for them and they’re not the target market.

Want to get a portable Docker developer machine?

MacBook Air is cheaper and lighter than a 12.9 iPad + keyboard.

However, given the chance they’d be happy to ram the iPad with never ending list of features.

Companies did that before the iPad and failed, because they couldn’t say no to ideas that sound great and focus on what’s really important.

More often than not, engineers lack the people skills and business experience to know what questions to ask and how to dissect the answers they receive.

The “Mom Test” is a great example of that.

Apple famously manages to do this with no Product Managers in its hardware or core software development organizations.

Open ecosystems foster growth and innovation though. Yes, companies have tried making something hackable and failed but other companies have tried closed eco systems and failed.

There is a reason I have a PineWatch instead of an Apple watch or Fitbit and Wyze cams instead of Nest or Ring.

I want to build an encrypted local mesh network with my iPhone for emergencies, I'll probably just do it on Android and have a few spare phones for family though.

I guess it is a profit incentive vs building the future. Running a Kubernetes cluster on an iPad would be cool, like that poster who leveraged an iPhone for OCR'ing memes. [1]

1. https://news.ycombinator.com/item?id=34315782

But docker works better on linux… if you want a docker machine a macbook air is not the best choice.

Side issue but the iPad is a bad example. People first complain when it comes to the iPad especially the top of the range is that it is artificially gimped to protect the MacBook sales contrary to what customers actually want.

I can tell you that easily because I am currently as far from an engineering position as you can be and see people all around me who like the iPad form factor but are annoyed that you can’t properly run Office on it.

The bit about most engineer not being able to talk to customers is spot on however.

I think you’re getting bad answers here. It’s not just about talking to customers and understanding what they want, it’s about taking that and matching it against bigger business goals, budgets, and priorities plus making sure you’re not duplicating or messing up things other teams are planning plus prioritizing within all the features all the customers want. If you have time to do all that then why is the company paying you an engineering salary to write code?

If you’re doing all that, the company could be paying you staff engineer or senior manager salaries?

It's not about being able to do all of it -- it's about being able to do it in a sustainable number of hours a week. Otherwise, you just have someone with the programmer title but actually doing PM work, and not doing it as well as someone who is specialized in the role.

The arguments in the thread are that aligning the product as built and architected with the goals of the company is actually engineering work and not PM work.

You still need to aggregate and contextualize these in terms of overall business and product strategy. Yes, engineers can do that too and some percentage of engineers are good at this as well - and being able to understand and formulate product strategy can be an important part of an engineering leader's skill set - but that's not that common and ultimately you need some level of specialization and you can't run an org expecting everyone to be able to do everything.

I've done both Eng and Product and most engineers don't have sufficient understanding or appreciation for the importance of product strategy. It's also important to be able communicate strategy coherently at some scale, especially if execution isn't expected to be completely top-down. At some point, engineers just have too much else to do and you need coordination.

Edit: I'll also add that engineers aren't the only ones doing work - Product Managers are expected to be able to coordinate across functions and get everyone on the same page, not everything is about just providing input to engineers.

You could, and probably should. The challenge is with the fad of scale. Every company wants to be the big guy hence bunch of hiring bunch of initiatives. It is common for people to subscribe to the ritual that a proper team should have some combination of PM, UI designer, UX designer, frontend, backend, devops (which is actually ops), QA, scrum master, customer success, support, data engineer, etc. Like graft different sticks together to call it a tree. OR you could grow a tree organically, naturally. Someone in your team is good at empathizing with customer? Good, do more talking with customer. Good with motivating colleagues? Good, do more motivating. It just doesn't quite fit the narrative of scale

Office Space had a whole bit on this two decades ago: https://m.youtube.com/watch?v=hNuu9CpdjIo

Reply on news.ycombinator.com