Master the Art of the Product Manager 'No'

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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

How about a "no" to having product managers?

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

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.

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

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.

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.

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

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.

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

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"},
                  
                ]

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

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

Gold

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

What's wrong with just saying "no"?