6 ms·

Fortunately, the author wrote a great many other articles that go far further. It seems to me like the article is fine for what it is, it's just calling out a p

by sfink 7y ago

Fortunately, the author wrote a great many other articles that go far further. It seems to me like the article is fine for what it is, it's just calling out a problematic pattern that commonly exists. It doesn't pretend to prescribe that to fix this pattern you need to do the opposite of every one of his bullet points. He instead writes lots of other articles dealing with the nuances of how to do better. But it also sounds that you're worried about engineers constantly challenging product manager's decisions? I don't think that's the implied end state. Engineers don't see all the input to PM's decisions, and yes it would be more comfortable for the PMs if the engineers just trusted them to get it right all the time. But we (I'm an engineer) aren't dumb. We know nobody gets it right all the time, and we don't expect you to. But if we never learn which things worked out and which didn't, and some of the why, then what you're asking for is faith, not trust. You don't need to include engineering in the decision making (at least, not more than you need for feasibility and cost estimates.) You do need to include engineering in the feedback loop, because we're not dumb monkeys whose only value is in realizing your vision. We know more about what's possible, and how to overcome some types of challenges with relatively little effort compared to the cannon that you'd need to (ask us to) build.

PragmaticPulp 7y ago
> But it also sounds that you're worried about engineers constantly challenging product manager's decisions? No, that's the exact opposite of what I said. In fact, I explicitly ended my post with a call to action for engineers to communicate concerns, suggestions, and questions to their product managers. > It doesn't pretend to prescribe that to fix this pattern you need to do the opposite of every one of his bullet points. That's my point: The article seeds this unrealistic idea of an over-idealized product management process that explicitly includes the reader at every step of the way. It manufactures an anxiety in the reader that a feature factory is a vaguely bad thing and if you recognize any of these 12 vague points, you're working within the bad thing. Again, my problem isn't with the core suggestions to improve PM process that might be elaborated in the author's other posts. My problem is with the trend of people reading this article, finding some point to identify with somewhere, and erroneously concluding that their employer is doing it wrong and that's a bad thing. My point was that if you want to be involved in the decision making process, provide feedback, or understand the reasoning behind the decisions you should be proactive about communicating. Instead, I see too many people reading this article and passively becoming disgruntled with their employers, without taking any steps to be more involved. Or the more they are involved, the more the complain about too many meetings, interruptions, and process overhead consuming their time that they'd rather use for quiet focus to get their work done. You can't have your cake and eat it too.
- hitekker 7y ago
  > without taking steps to become more involved It’s must be pretty comfortable to assume that the engineers here have never tried giving feedback in their workplace.

by sfink 7y ago

PragmaticPulp 7y ago

> But it also sounds that you're worried about engineers constantly challenging product manager's decisions? No, that's the exact opposite of what I said. In fact, I explicitly ended my post with a call to action for engineers to communicate concerns, suggestions, and questions to their product managers. > It doesn't pretend to prescribe that to fix this pattern you need to do the opposite of every one of his bullet points. That's my point: The article seeds this unrealistic idea of an over-idealized product management process that explicitly includes the reader at every step of the way. It manufactures an anxiety in the reader that a feature factory is a vaguely bad thing and if you recognize any of these 12 vague points, you're working within the bad thing. Again, my problem isn't with the core suggestions to improve PM process that might be elaborated in the author's other posts. My problem is with the trend of people reading this article, finding some point to identify with somewhere, and erroneously concluding that their employer is doing it wrong and that's a bad thing. My point was that if you want to be involved in the decision making process, provide feedback, or understand the reasoning behind the decisions you should be proactive about communicating. Instead, I see too many people reading this article and passively becoming disgruntled with their employers, without taking any steps to be more involved. Or the more they are involved, the more the complain about too many meetings, interruptions, and process overhead consuming their time that they'd rather use for quiet focus to get their work done. You can't have your cake and eat it too.

hitekker 7y ago
> without taking steps to become more involved It’s must be pretty comfortable to assume that the engineers here have never tried giving feedback in their workplace.