the reasons PM stuff is ‘hard’ in my, admittedly limited, experience often seems to come down to
- saying No, and sticking to it when it matters — what you’ve mentioned.
- knowing how the product gets built — knowing *the why behind the no*.
PMs don’t usually have the technical understanding to do the second one. so the first one falls flat because why would someone stick to their guns when they do not understand why they need to say No, and keep saying No.
there are cases where talking to customer highlights a mistaken understanding in the *why we’re saying No*. those moments are gold because they’re challenging crucial assumptions. i love those moments. they’re basically higher level debugging.
but, again, without the technical understanding a PM can’t notice those moments.
they end up just filling up a massive backlog of everything because they don’t know how to filter wants vs. needs and stuff.
—
also i agree with a lot of what you’ve said in this chain of discussion.
get it right first time, then keep it right is so on point these days. especially for smaller teams. 90% of teams are not the next uber and don’t need to worry about massive growth spurts. most users don’t want the frontend changing every single day. they want stability.
worry about getting it right first. be like uber/google if you need to, when you need to.
dijksterhuis|1 year ago
- saying No, and sticking to it when it matters — what you’ve mentioned.
- knowing how the product gets built — knowing *the why behind the no*.
PMs don’t usually have the technical understanding to do the second one. so the first one falls flat because why would someone stick to their guns when they do not understand why they need to say No, and keep saying No.
there are cases where talking to customer highlights a mistaken understanding in the *why we’re saying No*. those moments are gold because they’re challenging crucial assumptions. i love those moments. they’re basically higher level debugging.
but, again, without the technical understanding a PM can’t notice those moments.
they end up just filling up a massive backlog of everything because they don’t know how to filter wants vs. needs and stuff.
— also i agree with a lot of what you’ve said in this chain of discussion.
get it right first time, then keep it right is so on point these days. especially for smaller teams. 90% of teams are not the next uber and don’t need to worry about massive growth spurts. most users don’t want the frontend changing every single day. they want stability.
worry about getting it right first. be like uber/google if you need to, when you need to.