Live data from Hacker News

Master the Art of the Product Manager 'No'

letsnotdothat.com

11–20 of 173 posts

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

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

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

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

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

#17

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.

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

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

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

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

#19
post #6

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.

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.
Post reply on HN