[HN Gopher] Master the Art of the Product Manager 'No'
___________________________________________________________________
Master the Art of the Product Manager 'No'
Author : mikhaill
Score : 92 points
Date : 2025-01-20 18:02 UTC (2 days ago)
(HTM) web link (letsnotdothat.com)
(TXT) w3m dump (letsnotdothat.com)
| datadrivenangel wrote:
| There is a difference between a hard no (We are not doing that)
| and this softer no (We are not doing that but we are not
| committed to not doing that), and in less mature organizations
| that difference is important and very useful.
| kjellsbells wrote:
| 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 lumped with
| revenue thats unrecognize-able until some feature ships in who
| knows when.
| code_biologist wrote:
| 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 quality over quick and
| dirty software. Though I understand and agree with the
| sentiment, the unused features were much more difficult to
| remove because of their "quality" (as measured in the eyes of
| the dev team).
| ryandrake wrote:
| 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.
| gopalv wrote:
| This sort of advice is parodied in "Yes, Prime Minister" as the 4
| step strategy for "crisis management"
|
| 1: Don't worry, nothing's going to happen.
|
| 2: Something may be happen but we should wait and see
|
| 3: Maybe we should do something about it, but there is no clear
| action
|
| 4: Maybe there was something we could've done, but it's too late
| now
|
| Stringing along a bunch of people who think they are being heard
| and listened to when you are not is a morale killer when the tide
| goes out & we see who's been swimming naked.
| senkora wrote:
| The delivery in "Yes, Prime Minister" is very good. Here's the
| clip: https://www.youtube.com/watch?v=HSD1d-6P6qI
| gooseus wrote:
| This is also the story of my political discourse for the last
| four years, and will almost certainly continue for the next
| four.
| roenxi wrote:
| The _Yes, Prime Minister_ advice is different. That 4-stage
| formula is for ignoring a crisis. The PM 's No is advocating
| for working on tickets in priority order which will result in
| following the plan under a remarkably large number of
| situations. The two major differences are firstly that the YPM
| steps don't involve priorities at any stage. And secondly, the
| PM's No is a straightforward but a polite way of pointing out
| that the work being asked for is very low priority and so is
| unlikely to ever get time assigned to it.
| extr wrote:
| I don't even really feel like this is a PM-specific trait. The
| best engineers I know stay focused on immediate priorities and
| what needs to happen to see particular outcomes. The worst PMs I
| know derail meetings with suggestions/changes/tweaks with dubious
| ROI.
| make3 wrote:
| Prioritization is the #1 thing (I feel like this is a
| tautological statement). Spending a million hours doing
| something useless is just so obviously bad and expensive.
| idopmstuff wrote:
| "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, and since this isn't going to directly contribute
| to that, it's not going to be a priority in the near future."
| mr3martinis wrote:
| This is great, can you make it into a slack app?
| AcerbicZero wrote:
| That's a good thought, but let's revisit it later
| asoneth wrote:
| 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
| priority.
|
| 4. This idea is good, and while it is not a high-enough priority
| to displace our current tasks, we will actively discuss including
| it when we plan our next sprint/release.
|
| Depending on who you work with these may need to be gussied up
| with manager-speak to let people save face or to prevent people
| from hijacking the agenda to turn the meeting into a
| brainstorming session. But treating all of them as synonymous
| with "no" loses useful nuance.
| ryandrake wrote:
| 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.
| stalfosknight wrote:
| What's wrong with just saying "no"?
| blmarket wrote:
| with "no", there might be additional reason why. But this
| office jargon allows you to just defer (indefinitely).
| gatkinso wrote:
| How about a "no" to having product managers?
| gorfian_robot wrote:
| 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?!!!!!!!
| pm_details wrote:
| The PM: "practice radical candor!" The PM the very next week:
| "Let's gather more data before moving forward"
|
| In practice, there is no easier way to annoy these types than by
| taking these platitudes at face value. _Don 't_ go gathering the
| data.
|
| (I get why this style of communication has become common in
| business settings, especially in large orgs. It still rubs me the
| wrong way.)
| kylecazar wrote:
| In the smoothest operation I've worked at thus far, teams were
| instructed not to even _try_ to mess with already planned
| priorities and work.
|
| Food for thought, don't make someone say no as often.
| anticorporate wrote:
| This encapsulates why I hated being a product manager. You become
| the "no" person. It's your job to kill creativity and the ideas
| that actually motivate people to want to work on them.
|
| Blah blah blah the interests of the business. Fuck that.
| Capitalism sucks the joy out of software.
| baazaa wrote:
| 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.
| flappyeagle wrote:
| I had someone at work say "this is illogical" and it was great.
| Because we could actually come together to figure out exactly
| what the disagreement was. We didn't need to beat around the bush
| 10 times before getting to the point.
___________________________________________________________________
(page generated 2025-01-22 23:00 UTC)