Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More product, fewer product managers

kitemaker.co

Post reply on HN
Print view View original

121–130 of 314 posts

Re: More product, fewer product managers

#121

Post by growse »

bingemaker wrote: post #99
lol768 wrote: post #94

Earlier quoted context omitted.

> The developer teams, who else? You build it, you need to know what you are building, right? I find it fascinating that the dev community that gobbled so easily "You build it, you run it", doesn't question why we are not being trusted with knowing and determining what to be built in the first place. Absolutely this. And the engineering teams should have visibility of customer support and other functions to understan…

This. Most of the developer teams are nothing but feature factories. There will be a point where what developers want to build and what the product needs will diverge. It is very hard to strike a balance IMO.

This tension is why it's a good idea to align everyone's incentives.

Bonus the product team on reliability (as well as velocity), and the ops/sre team on feature velocity (as well as reliability), and it'll balance itself out.

Re: More product, fewer product managers

#122

Post by marcosdumay »

tomrod wrote: post #100
lol768 wrote: post #95

Earlier quoted context omitted.

If I consult a solicitor about data protection regulation and they tell me what I need to build to satisfy the requirements of soft opt-in under PECR, that does not make them a product manager!

No, but it's something a good product manager does for you, and with the economy of comparative and potentially absolute advantages. This let's you focus on the craft of delivery without encumberance of spending research into compliance.

If the PM does that, the developer has no idea what part of the requirements is important, and won't be able to deal with it when the requirements unavoidably break each other or reality. The developer has to be there too.

Re: More product, fewer product managers

#123

Post by growse »

ath3nd wrote: post #109
tomrod wrote: post #100

Earlier quoted context omitted.

No, but it's something a good product manager does for you, and with the economy of comparative and potentially absolute advantages. This let's you focus on the craft of delivery without encumberance of spending research into compliance.

I don't consider the engineering having a deep understanding of the domain and compliance to be a "encumberance". The more engineers get into the domain themselves, the more they can make deep decisions about how to build the most effective solutions. > This let's you focus on the craft of delivery I don't give a rat's ass about the craft of delivery! What a reductionist thing to think of engineers as "delivery machi…

> I care only about one thing: solving the problem!

Who prioritises the problems?

Re: More product, fewer product managers

#124

Post by tashoecraft »

ath3nd wrote: post #85
alistairSH wrote: post #75

Earlier quoted context omitted.

In that scenario, who is driving product requirements? For example, in an area with strict financial/regulatory compliance laws, are you expecting every engineer to be an expert in those laws? And have contacts at the government agencies implementing those policies?

> In that scenario, who is driving product requirements? The developer teams, who else? You build it, you need to know what you are building, right? I find it fascinating that the dev community that gobbled so easily "You build it, you run it", doesn't question why we are not being trusted with knowing and determining what to be built in the first place. > For example, in an area with strict financial/regulatory comp…

Sounds like you haven’t had a good PM or a job that supports having one.

Saying it’s often some new grad is like saying there’s no point having an on shore dev team because the devs are often fresh out of university. If you continually hire terribly you’re going to have a bad result.

A PM should become the subject matter expert in the product they are developing. They should be able to field questions on most every part of it, and be able to build a roadmap of features. Communicate with all teams associated with it. Having the programmers plan all features is a recipe for disaster if your product isn’t designed for developers. It’s like saying you don’t need a qa team because the developers tested it.

Re: More product, fewer product managers

#126

Post by andruby »

ath3nd wrote: post #70
bjornsing wrote: post #63

I've spent some time interacting with product managers as an engineering manager, or head of a functional area. I've also been "acting" PM for an internal product at a medium size tech company. I think product management entails some of the most important things a company does. But it's really hard work, and many less capable PMs gravitate away from it and more towards either "driving" (i.e. micromanaging) the engine…

I don't believe in Product Managers or Project Owners as a net good towards building a better product or a better company. The most successful teams I have been in had no dedicated product role, instead, all decisions were made by the developers. My current view is best to remove all type of non technical people or even mildly technical people from the developers' way and let them build in peace.

What type of product was that successful team working on? I believe this can work wonderfully if the developers are close enough to the user, eg: building a tool for devs like github.

But if the product and the users are alien to the developers then this is a recipe for poor UX and value (eg: building an accounting product)

Re: More product, fewer product managers

#127

Post by jack_riminton »

Hippocrates wrote: post #112

The problem with most PMs is that they are not doing boots-on-the-ground work. A good PM should be constantly bridging the gap between engineering and the user. 1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launc…

Having been a PM (now developer) the problem I faced was half the time I was having to provide documentation, communications and evidence for my managers. Which is of course fine but when you have HIPPO syndrome (HIghest Paid Person in the Office) who likes to make product decisions then you have to spend most of your time covering your back and managing up

PMs get a lot of stick, sometimes justified, but they're just having to play office politics in order to get stuff done

Re: More product, fewer product managers

#128

Post by jack_riminton »

epgui wrote: post #69
demondemidi wrote: post #67

Earlier quoted context omitted.

“Politics” 35 years in the semi industry. I must be stupid. I really don’t see politics. I see people trying to argue for their option and get support. But I’ve never seen this politics that people complain about. I’m so lucky I guess. Is politics just someone making a better argument that is the wrong technical decision? What is “politics”? Or am I just not at a high enough level (senior principal)?

Politics is what happens when you have limited resources and you need to decide where to allocate them. Politics are everywhere humans are.

This is the grown-up answer that this thread is clearly lacking

Re: More product, fewer product managers

#129

Post by nf3 »

I guess I belong to the tiny minority of self-employed software developers, so my point of view is somewhat unique. In all of the projects where I had to deal with people representing big companies, I was always struck by the sheer amount of wasted time spent on meetings, political machinations, and bike shedding, instead of doing actual work that solves the client's problems.

I'm really glad to be my own boss and to not have a PM over my head.

Re: More product, fewer product managers

#130

Post by fl7305 »

wruza wrote: post #65
fl7305 wrote: post #56

Earlier quoted context omitted.

Writing GUI applications, there's nothing as valuable as standing behind a user who tries to do something for the first time with my application. Just seeing the moments of hesitation, how the mouse is moved while searching in menus, etc gives me a lot of information.

Watching what and how they do after a month is as valuable. User interfaces have two sides in this regard: initial experience and boring repetition experience. You can optimize for the former, the latter or both.

Good point. My experience is also that most users don't learn many of the neat features I have built in to speed up their work.

Even if I show them a couple of times, it is often quickly forgotten.

Post reply on HN