> Putting devs in charge of inserting features "willy nilly" would likely result in a much more consistent experience than what we usually get, because they'd be willing to declare something "finished" eventually.
I have seen both, but at my most recent role, this was entirely the opposite of the case. We built integrations between different systems (ETL-like). Before the company adopted any "product principles", our integrations were haphazard and sporadic. Engineers would only build what was needed for current customer pain or in response to support saying "this entity doesn't sync".
So what, you say? Why build things you don't need? Because then the next customer says "I need X" and you say "Well, crap, that's going to be a lot of work because of how we wrote W", and either it's a lot of work, or they do some shoehorning and overload tables (my favorite was "'Location' in ERP A and 'Cost Code' in ERP B share much of the same columns, so we can use it for both and just change the label based on which ERP is in use." Then along came ERP C, which supported 'Location' AND 'Cost Code', and threw a spanner in the works.)
I am not saying product managers are a panacea. And I will acknowledge my 'bias' here - I am a PM, after spending a decade in the devops/SRE space.
But deeply embedding PMs and Eng is the key to success, I believe. My conversations with Eng Leads and EMs are happening 'all day every day'. I don't flit in, drop a bunch of stories in the backlog for Eng to refine, and then vanish to my meetings.
My job is to paint a broader picture of not just where we are now and what's next, but the grander and longer term vision.
This way, when designing or architecting things, there can be an awareness of that, and hopefully less "painting yourself into a corner". And with that comes a conducive atmosphere where Engineers do come up with Great Ideas, AND have a lower friction pathway to getting it in, because they know we can always discuss it.
I have seen both, but at my most recent role, this was entirely the opposite of the case. We built integrations between different systems (ETL-like). Before the company adopted any "product principles", our integrations were haphazard and sporadic. Engineers would only build what was needed for current customer pain or in response to support saying "this entity doesn't sync".
So what, you say? Why build things you don't need? Because then the next customer says "I need X" and you say "Well, crap, that's going to be a lot of work because of how we wrote W", and either it's a lot of work, or they do some shoehorning and overload tables (my favorite was "'Location' in ERP A and 'Cost Code' in ERP B share much of the same columns, so we can use it for both and just change the label based on which ERP is in use." Then along came ERP C, which supported 'Location' AND 'Cost Code', and threw a spanner in the works.)
I am not saying product managers are a panacea. And I will acknowledge my 'bias' here - I am a PM, after spending a decade in the devops/SRE space.
But deeply embedding PMs and Eng is the key to success, I believe. My conversations with Eng Leads and EMs are happening 'all day every day'. I don't flit in, drop a bunch of stories in the backlog for Eng to refine, and then vanish to my meetings.
My job is to paint a broader picture of not just where we are now and what's next, but the grander and longer term vision.
This way, when designing or architecting things, there can be an awareness of that, and hopefully less "painting yourself into a corner". And with that comes a conducive atmosphere where Engineers do come up with Great Ideas, AND have a lower friction pathway to getting it in, because they know we can always discuss it.