Roman, I’ve worked this way from the PM side and I wouldn’t want to go back. I want engineers to understand the user, the problem and why it matters, then own the how. They’re closest to the dependencies and structure in the code, so their judgment on what’s simple, costly, risky or worth doing can materially change the product decision. That back-and-forth usually made the product better than either side deciding alone. Really enjoyed this one.
There is nothing new in the advice. These have been best practices but very rarely seen in the wild. Now that the bottleneck has moved, they just became so obvious that they are difficult to ignore.
100% agree. Roles are blurring. Bringing developers in early to understand context and make decisions makes for a more efficient process/product.
This isn't about removing PM roles, as covered here: "the developer takes more ownership, and the PM has bandwidth for more strategic work."
Roman, I’ve worked this way from the PM side and I wouldn’t want to go back. I want engineers to understand the user, the problem and why it matters, then own the how. They’re closest to the dependencies and structure in the code, so their judgment on what’s simple, costly, risky or worth doing can materially change the product decision. That back-and-forth usually made the product better than either side deciding alone. Really enjoyed this one.
Thank you, David!
Consistently implementing this way of working has made work much more productive and, to be honest, much more fun as well.
I am not going back either.
The more fun part matters too. Good teams should actually enjoy solving hard problems together. Appreciate the conversation, Roman.
I’m curious, in your experience, how much of this is truly new or how much was already there?
I like the direction the advice is pointing to.
There is nothing new in the advice. These have been best practices but very rarely seen in the wild. Now that the bottleneck has moved, they just became so obvious that they are difficult to ignore.