[hnthrow0287345]

>The most common reason companies fail is creating products that don’t deliver value to users, causing them not to pay.

>“Oh, but I have a PM for that,” you might say. But having a PM is not enough.

It should be, that's literally their job. Developers and EMs shouldn't be doing that part for them.

In the same way developers need to know how to ifs and loops, Product Managers need to find out which features to build and user pains to fix.

Maybe, just maybe, we need to stop raising the bar for interviewing developers and start raising the bar for the other people working with developers, instead of getting developers to compensate for shortfalls.

[derwildemomo]

I was wondering about that for a while now - it feels in my last few jobs as an EM, the major part of my work (or rather the most influential one?) was managing, coaching and guiding product. The realization was actually quite simple for me: while hiring in engineering is defined by an sometimes absurd number of interviews, code challenges and so on, product is a case study and you're good: and that doesn't seem to be doing the trick.

[Aurornis]

I think dividing responsibilities across so many different managers has become too much of an anti-pattern for small and medium sized companies.

The least productive tech companies I worked for in the past decade had a nearly 1:1 ratio of engineers to different manager types. Our teams of 3-4 engineers had to work with our engineering manager, a product manager, a project manager, and a program manager at minimum. If you did UI work you would work with another UI/UX manager.

The minimum timespan to get anything done was measured in quarters. You could expect to have to spend more time scheduling meetings and following up with all your different managers by a factor of 10X or more than time spent doing anything related to code.

Contrast this with another employer I had who was very clear about the fact that we were not a big tech company and we were not going to structure our teams like one. We kept team units small and made them work together as a unit, not a disparate collection of managers that had to be appeased. We shipped a lot and we shipped fast.

We need to stop trying to use complicated and divided management structures everywhere. Companies with small teams and clearly unified management structures will always perform better than the management styles where responsibilities are divided across 5 different people and even basic work requires coordinating all of them through meetings

[AndrewKemendo]

There’s a reason you never see posts like: “My jump from BD to software engineer”

I’ve never met a sales person as broadly capable as your average engineer.

The curse of competence is organizational as well

[ghaff]

Because your average engineer is so good at creating customer relationships and generating revenue.

Customer relationships are certainly more important in some categories than others but sales is certainly key in a lot of B2B organizations.

[AndrewKemendo]

I guarantee I’ll be more successful with a group of engineers doing sales than I would a group of sales people trying to do engineering

[ghaff]

Both would generally be crap in isolation. (Assuming non-overlapping skill sets such as solution/system engineers.)

[gedy]

This is one of the reasons I think the "replace developers with ai" doesn't really fly in reality, as devs/engineers are typically the smartest people in any company I've worked for in a few decades. I don't see how the other folks could pull the weight via prompting.