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

Master the Art of the Product Manager 'No'

letsnotdothat.com

Post reply on HN
Print view View original

51–60 of 173 posts

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

#51

Post by wbl »

elevatedastalt wrote: post #37
p1necone wrote: post #26

Earlier quoted context omitted.

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…

Usually most engineers have some slack time and can pick things up to fix. The problem is not in them doing that. The issues arrises in one of two things— [1] They either use the fact that they are fixing that thing as an excuse to not work on or deliver on time a different, more important task. If that happens, obvious questions about prioritization occur. [2] They want a substantial amount of credit or recognition…

3: the fix is easy but the integration testing and deployment cannot happen without allocated time.

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

#53

Post by ungreased0675 »

idopmstuff wrote: post #7

"Please fill out the feature request form - that will create a ticket." Mark ticket P4. In all seriousness, the best thing is to have management that clearly communicates what the high level company goals are on a quarterly (or whatever cadence is appropriate for your business) basis. People don't like to hear no, but they understand "the main objective for the quarter is to close $X in new deals in Y market segment,…

In my PM work I haven’t had an issue with being transparent with feature requests. I’ll straight up tell people “just because it’s in the backlog doesn’t mean we’ll ever do it.” Most of the time people just want to be heard. People understand you can’t build every feature that crosses the desk.

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

#54

Post by JohnMakin »

Etheryte wrote: post #38
JohnMakin wrote: post #34

Earlier quoted context omitted.

On climate change, are we somewhere between step 3 and 4? It sure looks a lot that way to me. Maybe closer to 4 soon. That conversation is exhausting, or kind of the inverse of this, overwhelming confidence in the success of future technologies that do not really exist yet.

I think whether you're at 3 or 4 depends largely on what latitude you live at. I have many colleagues who are seriously considering moving because the weather is getting too extreme where they're at. Meanwhile people in mellower climates don't even see there's a problem, they're happy there's somewhere warm they can take a holiday in the cold months.

I live in LA - I am born and raised, never even left the city until I was an adult - I think it’s the best place on earth, but the recent natural disaster has made up my mind for me. I’m still grieving a little in my head about it, but long suspected this day could come - my home is losing fire insurance. I’m not sure I can even sell it if the market goes into a downturn, I don’t really even have a hard decision. the question to me is, what area will weather natural disasters the best in the next 40-60 years? I don’t honestly know. I think parts of northern alaska could become pretty temperate and is reasonably cheap/undeveloped, but I have infrastructure concerns and am not so much interested in remaining in the united states.

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

#55

Post by iamleppert »

I had a week long argument with a PM once about preview icons appearing in a list. Although it was in a design everyone already agreed on, and I had finished implementing it, after she saw it she pushed back and said it “added no value”. I asked her to explain how she determined that, to which she said, “it adds no product value”. From that point on, I’ve hated PM’s and run them out of every company I can.

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

#56

Post by mystified5016 »

gorfian_robot wrote: post #21
gatkinso wrote: post #14

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?!!!!!!!

Project managers that behave this way is what's wrong with people.

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

#57

Post by dyarosla »

ryandrake wrote: post #25
asoneth wrote: 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…

Also, but rarely:

Some engineer wants it bad enough that they just build it -or some version of it- and then some executive gives the go-ahead to invest more into it.

At the end of the day, ideas are just ideas. Execution is everything.

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

#58

Post by NortySpock »

karaterobot wrote: post #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 th…

It depends on the audience and context. If it's a stakeholder or key person, or you're in mixed company with people on various levels on the totem pole, then you need a few phrases grease the skids, placate feelings, and get the meeting participants' attention back to focusing on the most important issues.

You often still need people to feel like their ideas are being considered so they don't just shut down and contribute nothing in future meetings, or consider you to be railroading every meeting.

Granted, after the meeting, I'll often joking-but-only-serious point out "Look, our backlog is really long -- let's be honest, we're not going to revisit for months at this rate, so I hope you realize it's not a priority and probably won't be unless the priority changes. If we need it on a shorter timeline, talk to ."

I have very occasionally used hard-shutdowns of ideas or requests, but I think I have only used it when an idea was threatening to balloon the scope far beyond any hope of success. Maybe twice in the last few years.

("No, I'm not going to implement it that way -- it's needlessly complicated" or "I will not discuss timelines for phase 2 of this project until phase 1 is complete -- let's get back to closing out the outstanding issues with phase 1.")

There's a time to be frank, and other times you need to smile and gently redirect just to get things moving again before you waste an hour sparring or circling an endless unresolved debate.

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

#59

Post by asoneth »

psunavy03 wrote: post #41
ryandrake wrote: post #25

Earlier quoted context omitted.

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…

Or you work at a non-software company where the technical folks ultimately report to a non-technical boss, or are outnumbered by nontechnical executives. In which case, there's the real danger of a bunch of 0 getting shoved down your collective throat to the tune of "it's all a priority, get it done."

> "it's all a priority, get it done."

Reminds me of a product owner I had who abused priority categories by insisting that the majority of his tasks were "top priorities" because he had discovered that any time he didn't mark a task as a top priority it wouldn't get done.

Every team ended up sorting his tasks as a flat list so that when he asked people to "make this a top priority" it was up to him to decide where it went in the list and which of his other requests would get bumped.

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

#60

Post by thaumasiotes »

ryandrake wrote: post #25
asoneth wrote: 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…

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

Is it really true that your company cannot implement any idea that could potentially be done by more than one team?

Post reply on HN