Live data from Hacker News

Master the Art of the Product Manager 'No'

letsnotdothat.com

21–30 of 173 posts

Re: Master the Art of the Product Manager 'No'

#21

How about a "no" to having product managers?

Well, look, I already told you. I deal with the goddamn customers so the engineers don't have to!! I have people skills!! I am good at dealing with people!!! Can't you understand that?!? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!!!!!!!

Re: Master the Art of the Product Manager 'No'

#22

Earlier quoted context omitted.

Yes, but here be dragons, especially in front of customers (B2B sales). Sales Engineers for example are trained never to give the hard No to a customer request. Sometimes, they think they are saying no but the customer hears, "maybe". For example, "we'll consider adding that to the roadmap". Now the PM is stuck developing a single feature, the customer just got handed a stick to beat you with, and your CFO just got l…

Yep, I worked on a B2B product riddled with features that were there to make a sale. The success rate of those features converting to a sale was less than 20%, and none of those conversions were the whale clients. The features were typically well implemented and integrated with the rest of the product, and totally unused. The features added substantially to the complexity of the code base. It's funny to see HN defend…

Just thinking back, so many features I've written over my career were each done for a single sales prospect that never materialized into a sale. So much tech debt and wasted effort generated over so many years.

Re: Master the Art of the Product Manager 'No'

#23
I work in government and middle-management morons are continually pushing for the dopiest projects imaginable (e.g. we have no good data and everyone who can fix this is being told they should work on AI instead which will query the data - data we don't have - so analysts don't have to learn SQL).

One reason they persist in their insanity is everyone is an expert in giving excuses why their own team is too tied up with work to assist. Sure this reduces conflict over telling middle-management why their ideas are stupid, but in the long-run it's detrimental to the organisation to avoid explicitly hashing-out disagreements. Creating a culture where everyone lies to avoid hurting one another's feelings is not good.

Re: Master the Art of the Product Manager 'No'

#25
post #11

There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a pri…

In most companies I've worked, in order to actually implement an idea, you need to prove a few things, whether the person proposing it is the PM, an engineer, or any other person involved in the product:

1. The idea is technically feasible

2. The idea aligns with company's business goals

3. The idea is our team's responsibility and cannot be done by another team

4. The idea is more important than the other things our team plans to work on in the future

5. The idea is more time critical than the other things our team is working on now

If any of these cannot be proven, then it goes on the backlog as a P4 and nobody realistically will ever look at it. It's just the reality of corporate software building. There are always 10-50x more ideas than there are staff/time to work on.

Of course, all five of those can be, and often are, overridden by the Prime Directive:

0. One of the executives (often one of your grand-bosses high up on the totem pole) wants it.

Re: Master the Art of the Product Manager 'No'

#26
post #11

There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a pri…

In most companies I've worked, in order to actually implement an idea, you need to prove a few things, whether the person proposing it is the PM, an engineer, or any other person involved in the product: 1. The idea is technically feasible 2. The idea aligns with company's business goals 3. The idea is our team's responsibility and cannot be done by another team 4. The idea is more important than the other things our…

In my experience the more fine grained an organizations issue tracking/planning is the more this is a problem vs a reasonable process.

If you have to convince someone of all of those things in order to build some reasonably large thing over the space of a few weeks, that's probably reasonable.

If you have to convince someone of all of those things in order to allocate a few hours to fixing some tech debt or minor bug then your codebase is going to slowly deteriorate until the same someone is asking you why there's so many bugs and everything takes so long to develop.

Re: Master the Art of the Product Manager 'No'

#27
I kind of wish the answer would just be "no, we're not doing that". The lines in this website all strike me as a way to toy with people's expectations. If I had an idea, and presented it, and a PM told me "let’s keep this in mind for future consideration" or anything like that, I'd either take them at their word, or not. If I take them at their word, I'll either keep believing my input was considered valuable, and that we'll actually return to the idea later, then feel it all the harder when it never gets mentioned again. Or, I'll understand that the PM is lying to me, and I'll lose trust in them. I get that, at some level, this website is a joke, but I think you owe it to teammates to be polite but honest, friendly but frank.

Re: Master the Art of the Product Manager 'No'

#29
I'm a PM and I assumed that this was parody at first. I've been guilty of using terms like this with customers ("Not something we can do at the moment, but certainly something to think about down the track."), but always with a sense of discomfort -- or an attempt to make it clear that it's a "nice no".

Inside a company, I don't think there should be space for these sorts of responses. I can see these only being necessary/used where people are disenfranchised and not involved in setting or understanding the overall product priorities. But then I've always seen the PM's prioritisation role more as an expert mediator than a dictator...

Re: Master the Art of the Product Manager 'No'

#30
post #11

There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a pri…

"Add it to the backlog for review, we're not saying it'll be done, but it will at least be looked at an considered when we have bandwidth"

Just be direct and realistic. If it's to a customer, "we'll add it to our backlog for review" and tag it as customer suggestion so it doesn't just sit there forever.

Post reply on HN