Hacker News Reader

Comment by bobthepanda | Hacker News Reader

Isn’t that the job of a product manager, though? To figure out what the product should actually do?

Ideally. When I started as a programmer companies had business analysts who had domain expertise and made sure software mapped to the domain and actual users. Now we have PMs, usually glorified project managers, too often with little or no domain expertise or technical understanding. I freelance so I don’t have PMs or analysts, I have to learn the domain and deal with the management/client/users directly.

Yes, but I don't think it's wise or effective to put the onus all on a PM. As a dev, we often can have great insights into how much work/effort/maintainability one feature or another is, and having a rough knowledge of the business domain allows us to make much better recommendations regarding what we should do.

Additionally, in my experience the best engineers have been part product manager anyway, just as the best product managers have been part engineers.

tacit knowledge especially in an hands-on field like medicine where patients are involved cannot be conveyed by a manager with a power point presentation.

This compartmentalisation in the name of efficiency is actively harmful. Developers should get out more and get first hand experience of the environments they develop software for.

Could not agree more. It's a bit like the game of telephone that many of us played as children. The more hops in the connection, the greater ability for knowledge loss and distortion.

I once had a PM tell us to do a feature a certain way, despite engineers saying we thought it was dumb. We shipped and had lots of user complaints, and lost millions of dollars ultimately in lost revenue due to cancellations that we think were at least in part to this. We eventually reversed course but much damage had been done.

Afterward there was a witch hunt (which I staunchly oppose, but I digress). It turned out that the PM had taken the word of another PM who in turn heard from another that had gone on location and misunderstood what the customer was saying. To save a few thousand bucks the company only sent one person and expected them to brief everybody else on their findings. In hindsight I'm sure that skinnier travel budget wasn't so worth it.

To be a true engineer, one should use technology to solve problems. PMs are suppose to help with that, but to be called an engineer, one should have that mindset. Otherwise, we're just code-monkeys.

Yes, but someone has to make sure engineers solve the right problem in a way useful to end users.

If a developer is relying only on the product manager without first hand experience. It's a recipe for failure. I am a huge promoter of making devs do CSR, hell even make them do sales calls on occasion. The insight to the end user pain points is important. Devs need to hear it first hand.

That's also be the job of the UX/Product Designer to learn about the users and business domain.

“So, you physically carry the specifications to the developers?”

“Well, no, my secretary does that...”

Of course there should be people who's primary concern is firguring out what to build, but the buck doesn't stop there.

If you're not solving problems you're just a medoicre code jockey. I want to work with people who build iseful things, not people who stop and understanding syntax and think that code is a goal into itself.

Reply on news.ycombinator.com