13 ms·

Master the Art of the Product Manager 'No'

423 points by mikhaill 2y ago

datadrivenangel 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
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 2y ago
  The delivery in "Yes, Prime Minister" is very good. Here's the clip: https://www.youtube.com/watch?v=HSD1d-6P6qI https://www.youtube.com/watch?v=HSD1d-6P6qI
- gooseus 2y ago
  This is also the story of my political discourse for the last four years, and will almost certainly continue for the next four.
- roenxi 2y ago
  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.
  - tsunamifury 2y ago
    You haven’t worked in tech long enough have you. PMs priority more often than not is based on their perf and their ego. Rarely have I met one that can define actual priorities outside of this.
- JohnMakin 2y ago
  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.
extr 2y ago
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 2y ago
  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 2y ago
"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."
- ungreased0675 2y ago
  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.
- Cthulhu_ 2y ago
  This is what we do at my current job, they follow "safe" (scaled agile framework - don't look it up if the scrum inforgraphic already gives you shivers), but it boils down to two weeks of tidying, innovation and learning (in practice it's just more regular work) and two days of intensive planning, where from top the main priorities for the quarter are outlined and all the teams figure out what they are going to do and more importantly what dependencies they have on each other so every team can plan that.
  - psunavy03 2y ago
    The most abused concept in SAFe, because people fail to use it as intended (get a snapshot of the next quarter and be ready to pivot if things change) and use it to "lock down the plan," have teams refuse any new requests, and have management judge your "predictability score." It's a great idea in theory until you see how much two full days of timeboxed planning every quarter beats down dev morale in practice. It's great for teams that literally don't know what they're doing and don't know their dependencies, because it forces them to confront their mediocrity. But you have to move beyond it eventually.
mr3martinis 2y ago
This is great, can you make it into a slack app?
- AcerbicZero 2y ago
  That’s a good thought, but let’s revisit it later
asoneth 2y ago
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 2y ago
  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.
  - p1necone 2y ago
    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.
stalfosknight 2y ago
What's wrong with just saying "no"?
- blmarket 2y ago
  with "no", there might be additional reason why. But this office jargon allows you to just defer (indefinitely).
- zeroonetwothree 2y ago
  If you say no they get mad and escalate or cause trouble.
gatkinso 2y ago
How about a "no" to having product managers?
- gorfian_robot 2y ago
  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?!!!!!!!
  - mystified5016 2y ago
    Project managers that behave this way is what's wrong with people.
  - skibz 2y ago
    Somehow, I knew I'd run into an Office Space reference in this thread. (Context: https://www.youtube.com/watch?v=hNuu9CpdjIo&t=56s https://www.youtube.com/watch?v=hNuu9CpdjIo&t=56s)
- saulpw 2y ago
  Great, so, what are you going to build? Whatever the engineers want to play with?
  - PapaPalpatine 2y ago
    No. The engineers can talk to the customers and figure out what they want. Cut out the redundant middleman.
    - brigandish 2y ago
      Which engineer talks to the customer? That person shall henceforth be called the Product Manager.
      - ckeck 2y ago
pm_details 2y ago
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 2y ago
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 2y ago
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 2y ago
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 2y ago
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.
kerblang 2y ago
People insist devs aren't stakeholders but I've heard all of these more times than I can count...
karaterobot 2y ago
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.
- davidgerard 2y ago
  Are you in the US? In UK companies, everything from that bot is somewhere between "no" and "no, fuck off". The more qualifiers you add, the ruder you're intending to be.
  - deleted 2y ago
    [deleted]
  - sureIy 2y ago
    I thought the British were overly polite.
    - davidgerard 2y ago
      Mostly as a combat sport.
- NortySpock 2y ago
  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 <that> 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 <personName>." 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.
barryvan 2y ago
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...
- writtenAnswer 2y ago
  I mean, what do you expect from AI generated responses LOL. It is literally from some BS article from some dude who has never been a successful Product Manager. I think its a funny website to browse and say "haha", but nothing more.
  - barryvan 2y ago
    Ah -- I missed that it was AI-generated! That being the case, you're not wrong.
    - 7thpower 2y ago
      You’re not at work, don’t be so agreeable! Tell them it’s a great article and the author would have time to write their own if they weren’t so busy having to explain things to those damned engineers.
rqtwteye 2y ago
I hope this is a parody. All of these are passive-aggressive approach to telling somebody to fuck off.
Uptrenda 2y ago
These all just sound like a way to say no without owning up to it. People can tell when you're bullshitting and will feel resentment. From my perspective: it feels like you're not being listened to. I would instantly think less of anyone who used language like this (and have.) Just say you can't do something and explain why.
mberning 2y ago
The best product manager arguments are around value. The majority of the time nobody can justify the value of implementing their ideas, economic or otherwise.
- gorfian_robot 2y ago
  The majority of the time nobody can justify the value of damn near anything they do at work.
jewayne 2y ago
Just because something is objectively a great idea, doesn't mean it's a great idea FOR YOUR ORGANIZATION. In fact, I've definitely been a part of an organization whose biggest problem was the inability to say no to objectively great ideas.
Terr_ 2y ago
Closely related, documenting examples of problems or situations the product will not try to help with is also extremely powerful. You'd think "it does X, Y, Z, and nothing else" would be clear-enough, but in practice a blanket prohibition is too vague to have force, it's an invitation for scope creep. So saying "it will not handle W" is useful, even if it seems redundant at first glance.
iamleppert 2y ago
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.
Kalanos 2y ago
In your opinion, is this the very best use of our time right now? Why is it better than every other alternative?
sasaf5 2y ago
Yes, until all managers become "idea anti-bodies" and the winner is who can push all work to other teams. The company coasts along while its cash cows live.
exodust 2y ago
> "Interesting idea, let's explore that next quarter" Nothing wrong there, it's not "no". Sometimes we put ideas on ice until there's time, or other factors align. If your role is long-term, you have the underrated power of long-term planning. Often in past I saw the desire to tear down and hastily build something amazing in a few weeks, rather than chip away long-term where "amazing" gradually fades into view. This one time, I was asked to make a countdown timer for new website launch, back when I worked with PM's who thought users gave a shit about website launches.
harrall 2y ago
I used to run some open source projects and I got good at telling people how I’d “consider” their idea.
tzury 2y ago
Well - instead of this random pick of a reason, why not use AI to build a tiny AI app that has the roadmap as context, and provides educated answer? Assuming a PM cannot comprehend entire roadmap, vision and details in their head, simply have the answer based on merits. This is the intercom post from 2013 on the same topic - https://www.intercom.com/blog/product-strategy-means-saying-no/ https://www.intercom.com/blog/product-strategy-means-saying-... Anyway, copied the "reasons" here in case you want to use it locally. e.g. ## bash: shuf -n 1 why-not.txt __ const sampleData = [ { "text": "Let's add that to our discovery backlog" }, { "text": "What problem are we trying to solve?" }, { "text": "That's an interesting perspective for our long-term roadmap" }, { "text": "Let’s park that idea for now" }, { "text": "That’s worth considering once we have more resources" }, { "text": "We should validate that with users first" }, { "text": "Can we revisit this after the next sprint?" }, { "text": "It’s a great thought, but let’s prioritize our current goals" }, { "text": "I’d like to hear more thoughts on this from the team" }, { "text": "Let’s circle back after we’ve tackled the core priorities" }, { "text": "We need to ensure alignment before moving forward" }, { "text": "That might be more relevant in the next planning cycle" }, { "text": "We should let this marinate a bit longer" }, { "text": "Let’s pencil it in for further discussion later" }, { "text": "Let’s table this for now" }, { "text": "That’s a good thought, but let’s revisit it later" }, { "text": "Let’s keep this in mind for future consideration" }, { "text": "We’ll need to assess this in the context of our current objectives" }, { "text": "Let’s put this on the back burner for now" }, { "text": "Interesting idea, let's explore that next quarter" }, { "text": "We should prioritize getting feedback from stakeholders first" }, { "text": "This might be a phase two initiative" }, { "text": "That could fit in a future roadmap iteration" }, { "text": "We’ll need to revisit this once we’ve hit our milestones" }, { "text": "Let’s gather more data before moving forward" }, { "text": "I think this could be valuable down the line, let’s revisit then" }, { "text": "Let’s schedule a follow-up on this when the time is right" }, { "text": "This could be part of a larger initiative, but let’s hold off for now" }, { "text": "Let’s focus on the immediate deliverables first" }, { "text": "We’ll circle back once we have more clarity" }, { "text": "We already finalized our OKRs for H1 but if you throw it in the backlog maybe we can get it prioritized in H2 planning"}, ]
swiftcoder 2y ago
I feel a little bad that I have used basically all of these, and my job title is still engineer.
pietroppeter 2y ago
Gold
sitkack 2y ago
Being a PM is about politics, not actually building products and helping users. I am not sure what this site adds other than the ability for the uncreative to find snarky ways of telling people to fck off. /s some, some PMs try and build product, most are large corps are figuring out how to segment their niche and extract max rev from the tech ladder Nearly the entirety of this discussion outlines political and organizational dysfunction.
christblais 2y ago
This reminds me of https://christianblais.github.io/estimates/ https://christianblais.github.io/estimates/ which does the same thing in addition to time estimates.
gamerdonkey 2y ago
I expect anyone within earshot who cares about me to put me down if I ever used any of these phrases in a serious context.
paantastic 2y ago
[dead]

423 points by mikhaill 2y ago

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 2y ago
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 2y ago
  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 2y ago
    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 2y ago

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 2y ago
The delivery in "Yes, Prime Minister" is very good. Here's the clip: https://www.youtube.com/watch?v=HSD1d-6P6qI https://www.youtube.com/watch?v=HSD1d-6P6qI
gooseus 2y ago
This is also the story of my political discourse for the last four years, and will almost certainly continue for the next four.
roenxi 2y ago
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.
- tsunamifury 2y ago
  You haven’t worked in tech long enough have you. PMs priority more often than not is based on their perf and their ego. Rarely have I met one that can define actual priorities outside of this.
JohnMakin 2y ago
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.

extr 2y ago

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 2y ago
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 2y ago

"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."

ungreased0675 2y ago
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.
Cthulhu_ 2y ago
This is what we do at my current job, they follow "safe" (scaled agile framework - don't look it up if the scrum inforgraphic already gives you shivers), but it boils down to two weeks of tidying, innovation and learning (in practice it's just more regular work) and two days of intensive planning, where from top the main priorities for the quarter are outlined and all the teams figure out what they are going to do and more importantly what dependencies they have on each other so every team can plan that.
- psunavy03 2y ago
  The most abused concept in SAFe, because people fail to use it as intended (get a snapshot of the next quarter and be ready to pivot if things change) and use it to "lock down the plan," have teams refuse any new requests, and have management judge your "predictability score." It's a great idea in theory until you see how much two full days of timeboxed planning every quarter beats down dev morale in practice. It's great for teams that literally don't know what they're doing and don't know their dependencies, because it forces them to confront their mediocrity. But you have to move beyond it eventually.

mr3martinis 2y ago

This is great, can you make it into a slack app?

AcerbicZero 2y ago
That’s a good thought, but let’s revisit it later

asoneth 2y ago

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 2y ago
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.
- p1necone 2y ago
  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.

stalfosknight 2y ago

What's wrong with just saying "no"?

blmarket 2y ago
with "no", there might be additional reason why. But this office jargon allows you to just defer (indefinitely).
zeroonetwothree 2y ago
If you say no they get mad and escalate or cause trouble.

gatkinso 2y ago

How about a "no" to having product managers?

gorfian_robot 2y ago
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?!!!!!!!
- mystified5016 2y ago
  Project managers that behave this way is what's wrong with people.
- skibz 2y ago
  Somehow, I knew I'd run into an Office Space reference in this thread. (Context: https://www.youtube.com/watch?v=hNuu9CpdjIo&t=56s https://www.youtube.com/watch?v=hNuu9CpdjIo&t=56s)
saulpw 2y ago
Great, so, what are you going to build? Whatever the engineers want to play with?
- PapaPalpatine 2y ago
  No. The engineers can talk to the customers and figure out what they want. Cut out the redundant middleman.
  - brigandish 2y ago
    Which engineer talks to the customer? That person shall henceforth be called the Product Manager.
    - ckeck 2y ago

pm_details 2y ago

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 2y ago

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 2y ago

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 2y ago

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 2y ago

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.

kerblang 2y ago

People insist devs aren't stakeholders but I've heard all of these more times than I can count...

karaterobot 2y ago

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.

davidgerard 2y ago
Are you in the US? In UK companies, everything from that bot is somewhere between "no" and "no, fuck off". The more qualifiers you add, the ruder you're intending to be.
- deleted 2y ago
  [deleted]
- sureIy 2y ago
  I thought the British were overly polite.
  - davidgerard 2y ago
    Mostly as a combat sport.
NortySpock 2y ago
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 <that> 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 <personName>." 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.

barryvan 2y ago

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...

writtenAnswer 2y ago
I mean, what do you expect from AI generated responses LOL. It is literally from some BS article from some dude who has never been a successful Product Manager. I think its a funny website to browse and say "haha", but nothing more.
- barryvan 2y ago
  Ah -- I missed that it was AI-generated! That being the case, you're not wrong.
  - 7thpower 2y ago
    You’re not at work, don’t be so agreeable! Tell them it’s a great article and the author would have time to write their own if they weren’t so busy having to explain things to those damned engineers.

rqtwteye 2y ago

I hope this is a parody. All of these are passive-aggressive approach to telling somebody to fuck off.

Uptrenda 2y ago

These all just sound like a way to say no without owning up to it. People can tell when you're bullshitting and will feel resentment. From my perspective: it feels like you're not being listened to. I would instantly think less of anyone who used language like this (and have.) Just say you can't do something and explain why.

mberning 2y ago

The best product manager arguments are around value. The majority of the time nobody can justify the value of implementing their ideas, economic or otherwise.

gorfian_robot 2y ago
The majority of the time nobody can justify the value of damn near anything they do at work.

jewayne 2y ago

Just because something is objectively a great idea, doesn't mean it's a great idea FOR YOUR ORGANIZATION. In fact, I've definitely been a part of an organization whose biggest problem was the inability to say no to objectively great ideas.

Terr_ 2y ago

Closely related, documenting examples of problems or situations the product will not try to help with is also extremely powerful. You'd think "it does X, Y, Z, and nothing else" would be clear-enough, but in practice a blanket prohibition is too vague to have force, it's an invitation for scope creep. So saying "it will not handle W" is useful, even if it seems redundant at first glance.

iamleppert 2y ago

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.

Kalanos 2y ago

In your opinion, is this the very best use of our time right now? Why is it better than every other alternative?

sasaf5 2y ago

Yes, until all managers become "idea anti-bodies" and the winner is who can push all work to other teams. The company coasts along while its cash cows live.

exodust 2y ago

> "Interesting idea, let's explore that next quarter" Nothing wrong there, it's not "no". Sometimes we put ideas on ice until there's time, or other factors align. If your role is long-term, you have the underrated power of long-term planning. Often in past I saw the desire to tear down and hastily build something amazing in a few weeks, rather than chip away long-term where "amazing" gradually fades into view. This one time, I was asked to make a countdown timer for new website launch, back when I worked with PM's who thought users gave a shit about website launches.

harrall 2y ago

I used to run some open source projects and I got good at telling people how I’d “consider” their idea.

tzury 2y ago

Well - instead of this random pick of a reason, why not use AI to build a tiny AI app that has the roadmap as context, and provides educated answer? Assuming a PM cannot comprehend entire roadmap, vision and details in their head, simply have the answer based on merits. This is the intercom post from 2013 on the same topic - https://www.intercom.com/blog/product-strategy-means-saying-no/ https://www.intercom.com/blog/product-strategy-means-saying-... Anyway, copied the "reasons" here in case you want to use it locally. e.g. ## bash: shuf -n 1 why-not.txt __ const sampleData = [ { "text": "Let's add that to our discovery backlog" }, { "text": "What problem are we trying to solve?" }, { "text": "That's an interesting perspective for our long-term roadmap" }, { "text": "Let’s park that idea for now" }, { "text": "That’s worth considering once we have more resources" }, { "text": "We should validate that with users first" }, { "text": "Can we revisit this after the next sprint?" }, { "text": "It’s a great thought, but let’s prioritize our current goals" }, { "text": "I’d like to hear more thoughts on this from the team" }, { "text": "Let’s circle back after we’ve tackled the core priorities" }, { "text": "We need to ensure alignment before moving forward" }, { "text": "That might be more relevant in the next planning cycle" }, { "text": "We should let this marinate a bit longer" }, { "text": "Let’s pencil it in for further discussion later" }, { "text": "Let’s table this for now" }, { "text": "That’s a good thought, but let’s revisit it later" }, { "text": "Let’s keep this in mind for future consideration" }, { "text": "We’ll need to assess this in the context of our current objectives" }, { "text": "Let’s put this on the back burner for now" }, { "text": "Interesting idea, let's explore that next quarter" }, { "text": "We should prioritize getting feedback from stakeholders first" }, { "text": "This might be a phase two initiative" }, { "text": "That could fit in a future roadmap iteration" }, { "text": "We’ll need to revisit this once we’ve hit our milestones" }, { "text": "Let’s gather more data before moving forward" }, { "text": "I think this could be valuable down the line, let’s revisit then" }, { "text": "Let’s schedule a follow-up on this when the time is right" }, { "text": "This could be part of a larger initiative, but let’s hold off for now" }, { "text": "Let’s focus on the immediate deliverables first" }, { "text": "We’ll circle back once we have more clarity" }, { "text": "We already finalized our OKRs for H1 but if you throw it in the backlog maybe we can get it prioritized in H2 planning"}, ]

swiftcoder 2y ago

I feel a little bad that I have used basically all of these, and my job title is still engineer.

pietroppeter 2y ago

Gold

sitkack 2y ago

Being a PM is about politics, not actually building products and helping users. I am not sure what this site adds other than the ability for the uncreative to find snarky ways of telling people to fck off. /s some, some PMs try and build product, most are large corps are figuring out how to segment their niche and extract max rev from the tech ladder Nearly the entirety of this discussion outlines political and organizational dysfunction.

christblais 2y ago

This reminds me of https://christianblais.github.io/estimates/ https://christianblais.github.io/estimates/ which does the same thing in addition to time estimates.

gamerdonkey 2y ago

I expect anyone within earshot who cares about me to put me down if I ever used any of these phrases in a serious context.

paantastic 2y ago

[dead]