Hacker News Reader

Comment by aldebran | Hacker News Reader

This is one of those rare articles that points to the need of good Product Managers.

As a PM I’ve seen my fair share of “PMs are useless waste of space”.

The article doesn’t directly talk about PMs but the role of gathering AND properly unambiguously articulating them is extremely important. It happens to be the primary job of a PM.

The challenge is that the difference between bad or poorly written requirements and well written ones isn’t immediately obvious. And the skill and effort required to go from writing okayish requirements to good ones is high. You need to take in to account: actual customer problems, business need, future roadmap, market and cultural shifts amongst other things. Heck, deciding whether this is a problem worth solving itself isn’t easy and frankly a step many people skip.

View on HN

The most dysfunctional engineering organizations I have seen are ones where product managers are embedded at the deepest levels of the team and do everything from defining requirements and handling cross team collaboration all the way to planning and running sprints, bug triage and release management.

On the other hand, the effective ones have always had way fewer product managers with a lot more individual authority, who are in charge of the overall product direction but will let the rest of the team execute it to completion.

Microsoft does this and IMO is one of the reasons their products are lackluster at times. There are other reasons but this is definitely one of them. The PM role is spread so thin they don’t have enough time to boil down seemingly related pain points or customer rants in to a coherent story. Even with perfect execution the product tends to have a broken UX.

I've done this and it fail horribly, I'm the product manager as well as the implementor.

The problem is usually I choose solution which is easiest to implement and usually the scope is too tight because I need to also design the lower api and libraries.

I too feel like i've learned through experience that the product manager (whether with that title or just effectively being the one doing it) should never be the same person as the implementer/tech lead. It just doesn't work. And as an implementer/engineer, it ends up being so much less stressful when there is a product owner who you collaborate well with, but who is someone else. And you get a much more succesful product too.

Even though I think I am someone who understands the customer/domain pretty well, and is good at empathizing with the user, you're just too close to the implementation to effectively product manage.

In the domain I work in, I think people are used to the "head implementer" being the effective product manger (although without that title), and it takes some work to try to convince decision-makers, please, let's not do that.

Agree 100%.

Product managers are really business managers. Their goal is to ensure the software meets a business need that can help the firm developing it translate the value it delivers into $ by application of a commercial model.

Put another way - they define the WHAT and WHY, the HOW should be managed by their colleagues in Engineering.

You’re describing an analyst position. Product Management is a misnomer, IMO.

The best PMs I knew were amazing analists. They wrote logs quiery processing code themselves to understand the product better instead of asking other engineers to do it. The only problem with them is that they don't stick around, but start their own startups.

I keep ending up in that kind of a role. But since I’m higher paid than project managers I always get forced into doing development instead. So either I have to do my actual job after hours so I can help the company out. Or just do what I’m told and ignore the big picture.

Would be nice to do it in a formal way about taking a massive pay cut

The thing is he wasn’t forced into a role of writing code. He was an APM at Google when Google didn’t have many PMs, and he was in a supporting role of helping teams to be organized and decide on the future of the product when we didn’t know whether some non-technical ideas should be executed upon or not and help with the non-technical part of the execution.

Nowdays I felt just the opposite happening when I worked in Google Ads: PMs getting new feature requests from sales people and pushing down on us with strict timelines, even if we feel that that feature is not the best way to deliver better ads targeting for our customers.

Probably you should just go to a smaller company with less PMs, where the PM/Eng ratio is optimal or too small (or go into higher management)

That's a pretty good observation, too often Product owners are acting like project managers, not much vision lots of detail management.

Hell yes and hell no.

My take is that a good Product manager is worth their weight in any ridiculously rare metal you care to name. They will act as a force multiplier for the dev team.

But a bad product manager will poison the well, make bad products and be out of sympathy with the code and tech.

And as it is very hard to tell the difference, well why not play it safe?

It’s not hard to tell the difference. It just either takes a while, or you have to spend a few months without a PM.

I had a PM leave on me at my last job. It took 3 months to get a new PM. That meant all the PM work fell on devs for a while. Believe me, I could tell that both my old PM and the new one were good PMs after that experience.

> My take is that a good Product manager is worth their weight

A good X is worth their weight. Sure, any good professional is always welcome, but in regular team in a regular company, regular PMs are mostly dead weight (in contrast, regular devs are just good-enough devs).

Absolutely 100%. As a senior dev, I’m fairly decent at considering actual customer problems, business need, and the product roadmap for the near future. Start talking about the market as a whole, cultural shifts, and all that jazz, and I’m in very deep and probably reduced to treading water. I suppose that makes me an okay-ish ersatz PM, which has been good enough for me thus far. Unfortunately, the career path of a dev doesn’t seem to reward going very deep into PM type stuff, so I’m probably going to progress fairly slowly on that axis. :/

If you enjoy that part of the business you can always just apply for a PM/PO role. Thing is, it's a really hard job, and most people don't enjoy being the business whipping boy. Much of my job is saying no to things which have demonstrable value, because there are many other things which have demonstrably higher value. Said stakeholders see the world through their departmental lens, and expanding their vision takes a lot of effort. Often it doesn't work at all. This makes me the bad guy.

On the flip side, I've worn many hats and it feels like one of the most impactful places to be in a business. I get to shape what we build, and see it to completion. Very satisfying, but not easy.

Well PMs who used to be devs like you end up being very effective in my experience. They really ‘get it’. Add in high agency and you get a very potent person the team can rally behind.

PMs are important, but for many projects it's not a full time job (having a PM that can write out things to build doesn't directly mean there's enough people to build those things). In some orgs this leads the PMs to take on a half marketing role; that can end badly if this leads to the PM chasing whatever thing their latest customer / prospect interaction mentioned, rather than sticking to plans for long enough to get things to stabilize. Additionally, some times they can end up promising features and fixes on a schedule that isn't sustainable for engineering (but that largely depends on how the organization manages the work; this may not be in scope for a PM, in which case they're shouldn't be promising any sort of timelines).

I think this is ideal, but in my experience PMs are given the responsibility of building Gantt charts and managing swim lanes, instead of articulating requirements or verifying requirements have been met. Thus attracting people who want to manage resources instead of requirements. I then end up taking on requirements as part of the building it process... which to be honest works well at least on smaller builds.

I've always felt that having the dev experience helps. As you're walking through requirements with a client you're also piecing together how it should work.

PM’s are their own worst enemy. Only a couple I’ve worked with aren’t a waste of space. Sometimes that’s due to the problem space not needing a PM but often PMs earn their poor reputation.

According to the Gervais principle, managers are "clueless", and sit between "sociopath" leaders, and "losers" (engineers like me, I guess).

https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

Having discovered that it's easier to be self-effacing, the quick way to the top is just to directly contact the sociopaths (who usually just say "yes" to everything).

As for requirements specifically, I believe that to make it easy, they should all be 0 or ∞, which makes it easy to test. In practice, laws of physics will add other limitations, but having a grasp of those will make it easier to articulate the design decision (e.g. we can't make that faster because it's already at the speed of light).

Reply on news.ycombinator.com